Skip to content

Outcome for Preliminary phase

Jump to bottom
Jose edited this page Dec 26, 2018 · 8 revisions

what we can embrace from okta

?

allow customers to self-service registration of their external IDP for authentication to Gluu's customer facing apps (support/oxd/etc.).

It means certain users of, say, support portal would be capable of adding IDPs by their own.

It's a sort of administrative role

These people need to be able to onboard a new IDP via UI means exclusively (as our current low level tweaks don't apply)

Review/assess existing open issues

Done

Identify pros/cons of our current implementation.

  1. Attributes mapping

    Cons

    • Requires edition at different places (even up to 3): json config file, js (source code files!), and cust script properties
    • Every new attribute to support has to be added manually
    • IDPs cannot share a mapping (ie no mapping reuse)
    • Consequence of the above: error prone, time consuming

    Goals

    • automate mappings generation to minimize user intervention
    • mapping profiles assignable to external providers (that way pre-established mappings can be reused)

  2. External Providers onboarding & configuration

    Cons

    Goals

    • Provide UIs for configuring IDPs (potentially store all IDPs info in LDAP - except for metadata?)

  3. Flows

    Cons

    • IDP-initiated inbound flow is still beta. It ignores relay state, it simply redirects to a unique url at the end

  4. Misc

    Cons

    • Configuration is scattered through several files and LDAP
    • Node code not very well organized (not outstanding JS development skill :D)
    • Lots of node code repeated
    • Passport can be enabled at 2 different places: Configuration > Manage Authentication > 'Passport authentication method' or Configuration > Org_configuration

Contribute with ideas on how to solve the puzzle

We do in rocket

Identify node.js strategies

OIDC already integrated in 3.1.4

Clone this wiki locally