[MGNLSSO-84] Ability to use default Magnolia login as well as SSO login Created: 20/Oct/21  Updated: 17/Jan/24

Status: Selected
Project: Single Sign On
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Type: New Feature Priority: Neutral
Reporter: Luke Trueman Assignee: Nguyen Phung Chi
Resolution: Unresolved Votes: 11
Labels: SSO_and_Security_Initiative, dx-core-6.3
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: 0.5d Time Spent: 0.5d
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: PNG File image-2023-05-23-11-54-22-016.png    
Issue Links:
Problem/Incident
Relates
duplicate
is duplicated by MGNLSSO-266 Multi type login - SSO or Form Login Closed
is duplicated by MGNLSSO-106 Multiple login handlers Closed
is duplicated by MGNLSSO-284 SSO/JCR Login filter combined Closed
is duplicated by MGNLSSO-285 Multiple login modules Closed
is duplicated by MGNLSSO-297 Turn off SSO Closed
relation
is related to MGNLSSO-207 Validate that Pac4j can work with mul... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLSSO-108 DOC: Multiple login handlers Documentation Task To Do Julie Legendre  
Template:
Acceptance criteria:
Empty
Date of First Response:
Visible to:
Hong Li
Epic Link: SSO support for custom IdPs
Sprint: AdminX 37, AdminX 47
Team: AdminX
Work Started:

 Description   

Goal & problem statement

Plenty of customers report a problem that once they enable the SSO module on their Magnolia installations, they cannot login to their instance if the IdP provider used by SSO becomes temporarily unavailable. All users get completely locked out of the instance, so if there's an urgent need to access the AdminCentral for whatever reason, this is not possible until the IdP is available again.

Let's solve this problem.

Original request from luke.trueman:

Customers want to have a backup way to get access into the instance with jcr auth, they don't want to rely 100% on external identity provider. They also want to use SSO but not every user is in their SSO, e.g. an SEO agency may need access etc so having the Magnolia users available would be beneficial.

I know we offer a workaround using a mock docker server/node server, but this doesn't always cover the use case. 

Potential approach

lfischer suggests to solve this using multiple login handlers, which allow to use custom IdP provider AND local users at the same time, where local users are configured on the Magnolia instance and serve as a backup login possibility for situations when the IdP used for SSO is not available. 

He already prepared a repo containing support for multiple login handlers: https://git.magnolia-cms.com/users/lfischer/repos/magnolia-sso-extended/browse 

Documentation: https://git.magnolia-cms.com/users/lfischer/repos/magnolia-sso-extended/browse/_extended_docs 

The suggested approach would be to enable support of multiple login handlers (i.e. a custom IdP AND local users) if the customer decides to enable this for emergency situations. This feature could be made part of the core MGNLSSO module.

Discovery

We can follow the approach above to enable the default login and SSO login at the same time for SSO v2. In addition, we can introduce a configurable way to enable or disable the default login. 

For SSO v3, it might need to verify with the SaaS, but the same approach still can be applied.

UPDATE 23.11.2022: Additional idea by lfischer on how to solve this is available in the sso-extended docs: https://git.magnolia-cms.com/users/lfischer/repos/magnolia-sso-extended/browse/_extended_docs



 Comments   
Comment by Antonio Tuor [ 11/Apr/22 ]

We have an Enterprise client that needs this, they only have a set of users in the SSO, but a lot of users are only MGNL-Users.

Thought this should work, if we configure the path to a subpage only, but SSO login takes over the whole process.

Would be nice to be able to limitate the SSO-Login to a site and a path. And even then, a fallback to the mgnl-user should be possible.

Comment by Mercedes Iruela [ 18/Apr/22 ]

Hello Antonio,

Could you open a support ticket so that we can prioritise this issue with more detailed information?

Thanks.

Mercedes

Comment by Antonio Tuor [ 20/Apr/22 ]

Hi Mercedes,

I Opened an support-Task: SUPPORT-14728

Best regards,

Antonio

Comment by Matt Rajkovic [ 28/Apr/22 ]

lfischer , are you aware of any other customers requesting this feature? If so, add them to the ticket please!  

Comment by Antonio Tuor [ 28/Apr/22 ]

It should already be possible to configure it to be able to access magnolia with both, sso and magnolia login.
We had a different request, to only use sso on a specific login-button and else always use the magnolia login.

1. configure jaas to support both

magnolia {
   info.magnolia.jaas.sp.jcr.JCRAuthenticationModule requisite;
   info.magnolia.jaas.sp.jcr.JCRAuthorizationModule required;
};
sso-authentication {
  info.magnolia.sso.jaas.SsoAuthenticationModule requisite;
  info.magnolia.jaas.sp.jcr.JCRAuthorizationModule required;
}; 

2. configure the login filters to bypass the url of the other one (we defined .sso for sso login, so .magnolia/admincentral still used to default to the magnolia login:

  'jcr:primaryType': 'mgnl:content'
  'magnoliaLogin':
    'class': 'info.magnolia.cms.security.auth.login.LoginFilter'
    'jcr:primaryType': 'mgnl:content'
    'loginHandlers':
      'Basic':
        'class': 'info.magnolia.cms.security.auth.login.BasicLogin'
      'Form':
        'class': 'info.magnolia.cms.security.auth.login.FormLogin'
        'allowedMethods':
          'allowPost': 'POST'
    'bypasses':
      'BypassWhenSso':
        'class': 'info.magnolia.voting.voters.URIRegexVoter'
        'pattern': '\/.sso(.*)'
  'ssoLogin':
    'class': 'info.magnolia.sso.SsoLoginFilter'
    'jcr:primaryType': 'mgnl:content'
    'loginHandlers':
      'Basic':
        'class': 'info.magnolia.cms.security.auth.login.BasicLogin'
      'Form':
        'class': 'info.magnolia.cms.security.auth.login.FormLogin'
        'allowedMethods':
          'allowPost': 'POST'
    'bypasses':
      'BypassWhenNotSso':
        'class': 'info.magnolia.voting.voters.URIRegexVoter'
        'not': 'true'
        'pattern': '\/.sso(.*)' 
      # We will also add an AuthenticatedVoter next to the bypass 

3. Add a bypass for the securityCallback of the sso module and add the default for a specific url (same as the login filters). That will allow you to access the magnolia-login at a specific url, but else the sso-login is used by the securityCallback.

4. May check the logout filters, since the sso-logout only logouts from the sso-service but not from magnolia!

Maybe it would be a good solution, if the sso-module would directly add the possibility to login with both, e.g. the mask at `.magnolia/admincentral` should have a button for sso-login, and a form for the magnolia-login, so the user can decide which one to use.

Hope that helps all who has the need for both login methods.

Asked Magnolia to document this, but not sure when it will be done.

Comment by Matt Rajkovic [ 15/Nov/22 ]

This has been additionally requested by Crescendo: https://magnolia-cms.slack.com/archives/C02LXBD5P45/p1667934437544409

Comment by Matt Rajkovic [ 29/Nov/22 ]

Created a spin-off ticket https://jira.magnolia-cms.com/browse/MGNLSSO-207 to test an approach with pac4j as discussed in our SSO grooming on 29.11.2022 (filed as Preferred Option 2). 

Comment by Matt Rajkovic [ 23/May/23 ]

We might want to user test an approach similar to what is used in PaaS, see screenshot. How would customers want to have this implemented?

The technical implementation can be taken up separate from the design.

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