[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:
causality
duplicate
duplicates MGNLSSO-35 Allow Magnolia to be used as pac4j mi... Closed
relation
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: AdminX

 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.

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