[MGNLSSO-86] Add Support for Authorisation of Web Pages Created: 29/Oct/21 Updated: 26/Jan/24 |
|
| Status: | Open |
| Project: | Single Sign On |
| Component/s: | None |
| Affects Version/s: | 2.0 |
| Fix Version/s: | None |
| Type: | Story | Priority: | High |
| Reporter: | Chris Jennings | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 2 |
| 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 |
|
The SSO Module has a configurable "path" property but it cannot be used to restrict access to a public website. This was achievable previously using the PUR module and security model but not using SSO. I would like to log in as a user on a corporate IAM server and be given access to pages on URLs that depend on my authorisation. |
| Comments |
| Comment by Marvin Kerkhoff [ 21/Mar/22 ] |
|
Hi Chris, obviously that could be done. The Login mechanism is in my opinion not different to a usual user except that public users are stored in a different realm. Anyway, i managed it through adding a custom OidcSettings Java Class which made it possible for me to change the variables i needed for authentication on the public environment. All you need to do is adding this custom class path into a class property directly under authenticationService: in the yaml. |
| Comment by Mikaël Geljić [ 25/Jan/24 ] |
|
Let's elect this one as our "Protect any URL" story mrajkovic nguyen.phung. This is a long-awaited expansion of the use cases served by the SSO module, and has already been worked around, e.g. by configuring SSO to a protected page only on public instances, instead of admincentral, or by using the SSO-connector incubator module. From a technical standpoint, there is little reason for the SSO filter to kick-in exclusively on a single path. 1. After the OIDC authorization code flow has happened, users should be redirected to their originally requested URL. 2. Magnolia's UriSecurityFilter + internal JCR groups with URI ACLs + group mappings from the IDP's "public" realm to the relevant magnolia groups should do the rest. The outcome is a more transparent and versatile SSO module, effectively treating Admincentral access as a normal request security flow, rather than as an exception. On another note, let's not mix PUR in this story, as we do not plan to cover self-service registration from Magnolia. |