[MGNLSSO-78] Rebase SSO cloud feature branch on top of SSO 2.0 Created: 26/Aug/21  Updated: 31/May/22  Resolved: 26/May/22

Status: Closed
Project: Single Sign On
Component/s: None
Affects Version/s: 3.0.0
Fix Version/s: 3.0.0

Type: Task Priority: Neutral
Reporter: Mikaël Geljić Assignee: Evzen Fochr
Resolution: Done Votes: 0
Labels: discovery, microprofile, ready-for-grooming
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLSSO-132 Enhance multiple clients configuratio... Closed
duplicate
is duplicated by MGNLSSO-91 Bump up master to 3.0, adapt all 1.2-... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLSSO-114 Merge release/2.0 and master Technical task Completed Evzen Fochr  
MGNLSSO-115 Update Saas configuration to align wi... Technical task Closed Evzen Fochr  
MGNLSSO-116 QA Technical task Completed Nguyen Phung Chi  
MGNLSSO-117 Rw changes after merge Technical task Completed Nguyen Phung Chi  
MGNLSSO-118 Update sso 3.0 documentation accordin... Documentation Task Completed Alex Mansell  
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Documentation update required:
Yes
Date of First Response:
Epic Link: Branch reconciliation - AdminX
Sprint: AdminX 10, AdminX 11
Story Points: 8
Team: AdminX

 Description   
  • dropped ?client_name in redirect URI
  • provides a FixedRoleAuthorizationGenerator to add static group/role mappings regardless of what IDP returns.

Additional input:

Question/rubber-ducking about MP config & SSO 1.3/2.0: config changes slightly with authorizationGenerators configured first while groupMappings move below one specific impl (configured via typical 2bean / class-property ways), see the README for an example. MP config doesn't use 2bean or type-mapping facilities, or does it?

Here's how I can imagine rebasing, without requiring arbitrary class instantiation:

  • We never need multiple authGenerator instances of the same type (both mappings and fixed-roles/groups can always be added to the same piece of config)
  • Generators would rather be registered in SPI ways and let themselves be configured via MP config, e.g.
magnolia.sso.authorizationGenerators.fixed.roles=superuser
magnolia.sso.authorizationGenerators.groups.mappings[0].roles=marketing
...
  • Therefore still suitable for java extensibility (must-have to merge back to the main branch), without having to allow arbitrary class mappings


 Comments   
Comment by Evzen Fochr [ 02/Mar/22 ]

moved to discovery stage, needs estimation for rest of work.

Comment by Evzen Fochr [ 19/May/22 ]

mgeljic do we need to adjust documentation after this merge? I guess yes. But do we have 3.0 sso docu at all?

Comment by Mikaël Geljić [ 19/May/22 ]

Yes we definitely need to prepare the docu update, and a place for doing that
Any recommendation from the docs team for incubating such an update until we decide to release SSO? —or slowly shifting master to 6.3 docs while branching release/6.2?

Generated at Mon Feb 12 10:50:54 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.