[DOCU-2618] Improve SSO docs to reflect common use cases Created: 02/Dec/22  Updated: 08/Dec/22  Resolved: 08/Dec/22

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Alex Mansell Assignee: Alex Mansell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Reporter Name: Mika

 Description   

Improvements to SSO docs:

Chat notes

  • Typically, customers won't implement both the OIDC and Bearer Token approaches, meaning the configuration should really only reflect one or the other for a use-case scenario.
  • The OIDC flow is for user login where there's an indirect flow to a login page. The Bearer Token is a programmatic flow which is more behind-the-scenes. See here for more details on that => https://www.rfc-editor.org/rfc/rfc6750.
  • It would also be useful to highlight the multiple clients of the same type (while in the OIDC use-case specifically).
  • Highlight the Authorization section a bit better and make sure that customers know defining the groups/roles doesn't implement them as that needs to be further defined from within the client section.
  • maybe move the mapping OIDC attributes to a section on the main page
  • defaultBaseUrl (config > server > defaultBaseUrl) – talk about this a bit more as it's within Magnolia and a newbie might miss out on the meaning of it.

 

Then I believe we should organize this doc page by use case, less by config:

OpenID Connect * mostly for editors to log into Magnolia, via indirect flow

Authorization

Direct programmatic access, via plain OAuth 2.0, also abusively known as JWT authentication (JWTs are also used in OIDC)

Using relative callback URLs (in theory more cross-environment, but defaultMagnoliaUrl must be still be set (inside the application/war file), so the benefit is slightly defeated)

Configuring multiple clients (incl. of the same type, with the .2 suffixes)


Generated at Mon Feb 12 01:28:43 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.