Landing page on saml login

[sbernhard (Bernhard Suttner)]

On previous versions, a landing page was shown on which the “login” button appeared. Clicking this buttons showed the saml login page.
Personally, I really liked this behavior. With the current version 2.4.2 this isn’t possible any more as the saml login page is shown immediately.

Is it configurable?

[sam (Sam Saffron)]

I am not following, you mean we showed a modal that had a single button “Login with SAML” ?

[sbernhard (Bernhard Suttner)]

No.
In a previous version (I believe it was 2.3.6), it was like this:

After clicking on “Anmelden”, the SAML login window appeared.

If I enable “local logins”, the landing page with the login button appears again, but I do not want to have local login and therefore I need to disable it.

[sbernhard (Bernhard Suttner)]

Can someone help me? maybe @eviltrout ?

[eviltrout (Robin Ward)]

I certainly didn’t change this on purpose. If you could help us track down when it changed that would be helpful as we could look into the context.

It’s possible it changed for security reasons.

[Falco]

This was a long requested improvement to make omniauth behave like real SSO, when the number of omniauth login methods is only one.

SSO vs Oauth2 difference?

This is now implemented: If there is only one external authenticator enabled and local logins are disabled and the site requires login, then users will be directed straight to the external authentication page. This exactly matches the implementation of our Discourse-native SSO. I can’t think of a reason why anyone wouldn’t want this, so this is now the default behaviour. cc @consideRatio @Joralf

[sbernhard (Bernhard Suttner)]

How can I help?

one hint: if you enable “local login”, the “Landing page together with the login button” is shown.

[david (David Taylor)]

If you really want the confirmation page, you can link the user to /login (rather than the homepage). That will not trigger the login automatically.

But note this is not really supported, it is just a quirk of the implementation and may change at any time.

[Falco]

New behavior is better and consistent with SSO login. If a message is needed before login it can be implemented in the Identity Provider.

[sbernhard (Bernhard Suttner)]

ah, good to know.
I know of 2 reasons:

• show a very nice landing page with some basic information instead of that “boring” login window
• “security” (I know, its not really a big blocker). Cheap hacking scripts on the main URL (without the landing page) would fail hopefully as its required to press the login button first.

Is it possible to configure this behavior?

[sam (Sam Saffron)]

@sbernhard

Is it possible to configure this behavior?

You are going to need to hire a dev here to build a plugin to change this. As it stands this is the first complaint I have heard about the new system in months.

[sbernhard (Bernhard Suttner)]

I’m a dev (see my changes in discourse_saml)

Would you accept a PR which adds a configuration option (default: new behavior)?

[david (David Taylor)]

@sbernhard

“security” (I know, its not really a big blocker). Cheap hacking scripts on the main URL (without the landing page) would fail hopefully as its required to press the login button first.

The automatic redirect should not introduce any security vulnerabilities. If you are aware of an exploit, please let us know via our disclosure program: discourse/docs/SECURITY.md at main · discourse/discourse · GitHub

@sbernhard

Would you accept a PR which adds a configuration option (default: new behavior)?

I don’t think we want to add more noise to the settings until we have some more users requesting this change.

You could override this in a plugin by patching this method:

app/controllers/application_controller.rb

So I think you would want to simplify the function right down to

def redirect_to_login
  dont_cache_page
  cookies[:destination_url] = destination_url
  redirect_to path("/login")
end

[sbernhard (Bernhard Suttner)]

Thank you. Very appreciated!
BTW: You are doing a great job with Discourse.