[MGNLSSO-61] Leverage Azure-specific APIs for a better experience? Created: 01/Jun/21 Updated: 20/Jan/23 |
|
| Status: | Open |
| Project: | Single Sign On |
| Component/s: | None |
| Affects Version/s: | 1.1.1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Maxime Michel | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Template: |
|
||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||
| Date of First Response: | |||||||||||||
| Epic Link: | SSO support for custom IdPs | ||||||||||||
| Team: | |||||||||||||
| Description |
|
When hooking up Magnolia to Azure, we found out that a typical groupMapping configuration that looks like this:
groupMappings:
/magnolia-sre:
groups:
- travel-demo-publishers
roles:
- superuser
Ends up looking like this because Azure delivers group IDs rather than names:
groupMappings:
ea0b1d9f-c8fc-4b99-9f76-8a92abbbb496: # travel-demo-editors
roles:
- superuser
That makes the configuration less readable and it has been suggested that we make Azure-specific calls to endpoints such as:
In order to make the configuration process slightly easier. This comes at the cost of added complexity and deviation from the module's conventions. I am not favorable to implementing it, but I wanted to log it regardless, in case it does became necessary at a later point. |
| Comments |
| Comment by Boris Faniuk [ 06/Jul/21 ] |
|
Hello, Maxim! |
| Comment by Boris Faniuk [ 06/Jul/21 ] |
|
This solves the problem with missing group ids: |