[MGNLSSO-189] Custom SSO authorization generators Created: 01/Nov/22  Updated: 18/Apr/23  Resolved: 02/Mar/23

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

Type: New Feature Priority: Neutral
Reporter: Matt Rajkovic Assignee: Nguyen Phung Chi
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: 5d 7.5h Time Spent: 5d 7.5h
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: Java Source File AzureAdRolesGroupsAuthorizationGenerator.java    
Issue Links:
Relates
relates to MGNLSSO-61 Leverage Azure-specific APIs for a be... Open
relation
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLSSO-190 Implementation Sub-task Completed Nguyen Phung Chi  
MGNLSSO-191 Review Sub-task Completed Evzen Fochr  
MGNLSSO-192 Pre-Integration QA Sub-task Completed Evzen Fochr  
MGNLSSO-193 QA Sub-task Completed Nguyen Phung Chi  
Template:
Acceptance criteria:
Empty
Documentation update required:
Yes
Date of First Response:
Epic Link: SSO support for custom IdPs
Sprint: AdminX 30
Story Points: 8
Team: AdminX
Work Started:

 Description   

Goal

SSO 3.0.0 lacks a feature/interface to define a class to resolve groups.

Example: for Azure, we receive group IDs instead of group names. We need to resolve these group IDs to names, but that currently is not possible -  We would need group resolution there to resolve a group name with group ID from Azure. 

Thoughts for discovery

  • One possible option is to include Custom authorization generator leveraging SPI (Service provider interface) - this needs further discovery.
  • Another option might be providing out-of-the-box generators which might be configurable, so that less custom code to resolve groups is needed
    • Azure offers 3 ways on implementing mapping group IDs to group names, it might be possible to check if there are common patterns which might be implemented

Notes

Discovery output

  • As discussed with mgeljic, we agreed to go with the Custom authorization generator leveraging SPI (Service provider interface). This approach will open the possibility for customization.
  • With that, we have to introduce a Service provider interface to allow customers implement their own authorization generator in a custom module (jar file)
  • Specify a new predefined key, for example "customAuthorization" in the "oidc.authorizationGenerators" config property, then it will lookup for the custom authorization generator from the SPI, something like this in the yaml configuration:
clients:
  oidc.id: ...
  oidc.secret: ...
  oidc.scope: ...
  oidc.discoveryUri: http://localhost:8180/realms/mgnl/.well-known/openid-configuration
  oidc.preferredJwsAlgorithm: RS256
  oidc.authorizationGenerators: customAuthorization

Notes: Re: the second option "providing out-of-the-box generators which might be configurable", this may not cover all cases from the customers requirement, especially Azure AD provided different ways to configure the groups/authorization. So, we can't know which is the most common configuration pattern to create the OOTB generators for the IDPs (Azure, Okta, Keycloak)


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