[MGNLSSO-66] Installing the SSO module leads to a broken filter chain Created: 05/Jul/21  Updated: 16/Jul/21  Resolved: 16/Jul/21

Status: Closed
Project: Single Sign On
Component/s: sso-connector
Affects Version/s: 1.1.1
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Richard Gange Assignee: Maxime Michel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File 500-error.png     Text File HTTP_Status_500–Internal_Server_Error.txt    
Issue Links:
causality
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[X]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

The SSO module cannot self-install. This is the reason why we had tutorials in the incubator to show users how to properly set it up without breaking the system:

If the module bootstraps/setup configuration then you don't have chance to login and setup properly. This is exactly how the incubator version worked but the new PD version is trying to bootstrap/setup. This cannot work.

Reproduce

  1. Install the SSO module into a fresh system.
  2. Perform the installation.
  3. Proceed to the license screen. Observe it's broken (missing CSS).
  4. Enter the license and see the error.

Actual
The SSO login filter is configured in the chain before it's actually ready to handle login. This cannot work.

Expected
It's the users responsibility to setup login. They can create a module which bootstrap their specific configuration.

Notes
The most important is a YAML decorator that is needed at project-level in order to specify target URLs, clientId, etc. This file must be located in an observed directory with the following path:

<MODULE_NAME>/decorations/magnolia-sso/config.yaml


 Comments   
Comment by Richard Gange [ 07/Jul/21 ]

Ideally the installation should stop if the proper config is not found. Or we need some message with the stack trace which tells the user what to do.

Comment by Boris Faniuk [ 07/Jul/21 ]

I would better disable SSO login in this case.
If we stop the installation then we have no chance to run the application locally or to configure it properly in production, e.g. add roles for group mapping.
The best behavior is that SSO login should be explicitly activated, before this just use the username/password scheme.

Comment by Richard Gange [ 07/Jul/21 ]

Hey Boris-

Thanks for you input. This always been a tricky thing to handle. This is why we had the tutorials before. In those tutorials you had to configure by hand the login filter when the config is ready.

If we stop the installation then we have no chance to run the application locally or to configure it properly in production, e.g. add roles for group mapping.

I think the idea is you have to have the decoration file in place during installation which is not really intuitive.

Comment by Maxime Michel [ 07/Jul/21 ]

I understand the concern and we are looking at enabling the traditional Admincentral form login considering how frequently this gets brought up. However:

  • disabling SSO when no configuration is present isn't easy as the LoginFilter class is a value stored in JCR. The SSO Connector works around this by copy-pasting and patching the stock LoginFilter, but considering the complexity and importance of this class (filter chain), this isn't something we were comfortable replicating.
  • I don't understand why you both have brought up Magnolia's installation in your comments. The fact that the configuration lives in a YAML decorator allows you to update the configuration on the fly at any given moment. See the latter part of this blog post for more details.
  • last but not least, we have run this in production for over a year in two internal projects, and never saw the need for a fallback login.
Comment by Richard Gange [ 07/Jul/21 ]

Maybe we could mention the blog post in the "Related topics" section
https://docs.magnolia-cms.com/product-docs/6.2/Modules/List-of-modules/SSO-module.html

Comment by Maxime Michel [ 07/Jul/21 ]

Good point, I will do that.

Comment by Boris Faniuk [ 07/Jul/21 ]

Hello, Maxime!
Let me describe why I think it's good to have some fallback.

I was testing the module at test instance, did all configuration, created decoration and then realized that some issues exist on our Azure side. So I had to ask our internal support team to fix Azure problem. While this was in progress, the site was unavailable.

Currently even if I remove the decoration, the new way of login is still there and just doesn't let anybody to login.
At least for migration stage, if something goes wrong and there's no way back, that would be stressful.

Also, we have to consider localhost development, where we don't want to have SSO at all.
With this module in dependencies we don't have any option to disable it.

Comment by Richard Gange [ 07/Jul/21 ]

Technically speaking you could have two login filters in the chain. Just have one enabled at a time. Any filter can have an enabled property.

I was testing the module at test instance, did all configuration, created decoration and then realized that some issues exist on our Azure side. So I had to ask our internal support team to fix Azure problem. While this was in progress, the site was unavailable.

So at this point while you can still log in. Toggle off SSO Login Filter, toggle on Fallback login filter.

Comment by Maxime Michel [ 12/Jul/21 ]

Thanks for the extra details, we are now looking at a solution.

Comment by Maxime Michel [ 16/Jul/21 ]

We have released a Docker image (or you can also run the Node project) and a documentation page on how to spin up a mock OIDC server: https://docs.magnolia-cms.com/product-docs/6.2/Modules/List-of-modules/SSO-module/Using-a-mock-OIDC-server.html

This allows to easily recover access to a Magnolia instance in the cases that have been brought up. Hope that helps!

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