[MGNLSSO-272] SSO as core functionality Created: 25/Apr/23 Updated: 22/Jun/23 Resolved: 22/Jun/23 |
|
| Status: | Closed |
| Project: | Single Sign On |
| Component/s: | None |
| Affects Version/s: | 3.1.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Richard Gange | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | stays-in-jira-server | ||
| 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 maintenance | ||||
| Team: | |||||
| Description |
|
Authentication is a fundamental part of any system. SSO should be included in the Core Module of Magnolia as a subset of the security package: info.magnolia.cms.security. Absorb the SSO module into Magnolia Core Module. Remove any chance of a race condition based on module loading order since core is the foundation of the system. Open up SSO login to the community. |
| Comments |
| Comment by Mikaël Geljić [ 26/May/23 ] |
The race condition here was a bug in SSO implementation, and was unrelated with the module loading order (order is deterministic based on module dependencies). It was Kubernetes probes trying to initialize Pac4j concurrently, which wasn't meant to be supported, and we realized we had thread-unsafe operations being part of that logic.
More of a product question—I believe SSO is the ultimate example of an "enterprise" feature though. Basic plans let community users enjoy the product with basic user/group-management, with invite-based flows, while SSO lets them integrate the product with the rest of their IT ecosystem, and have a role-based setup more suitable to employee turnover. That said, SSO installation shouldn't be as invasive as it is today (onto the Core login filters/config). We should do that refactoring—which I believe is considered for the story of default+SSO logins at the same time. Moving SSO support to core would only force us to do it. |