/saml_login requires anonymous user, but this path is a redirect destination for users logged in through SAML

Following up from #2916042: Set simplesamlphp_auth.saml_login route requirement for only unauthenticated users: the assumption was that /saml_login is only used as the login page. However, this path is also used for users returning from the IdP.

The login path in 8.x-3.x HEAD is currently:

1. /saml_login
2. IdP (user enters credentials)
3. /simplesaml/module.php/saml/sp/saml2-acs.php/[authsource]
4. /saml_login (user is authenticated in Drupal at this point)
5. /user/login
6. /user

The login path after patch in #3:

1. /saml_login
2. IdP (user enters credentials)
3. /simplesaml/module.php/saml/sp/saml2-acs.php/[authsource]
4. /saml_login (user is authenticated in Drupal at this point)
5. /user

We've had similar issues with this.

In our case users come from an external platform and should always be logged in. For this reason the external platform uses /saml_login as the landing page. However, this will cause an error pages who had a previous session active.

It looks like #3 would solve the problem.

One addition I'd like to see is for the redirect for authenticated users to respect the destination parameter. That way an external site can link directly to a certain page for authenticated users. This currently works for /user/login as well.

As an example https://www.drupal.org/user/login?destination=/project/simplesamlphp_aut... brings both anonymous and authenticated users to this issue :)

Updated Patch.

Another interesting edge case:

We're using the require_login module which directs anonymous users to /saml_login. When clicking a link from a Word document to a page on the website, users who are already logged in will be redirected to /saml_login with a 403. This is due to this "feature" in Microsoft Office: You are redirected to a logon page or an error page, or you are prompted for authentication information when you click a hyperlink to a SSO Web site in an Office document.

We solved it with the registry key from the knowledge base article, but this kind of patch could certainly work too. I'm not quite sure system.admin_content is an appropriate default.

I have just uploaded a patch to a related issue which could solve the this one too, please test: https://www.drupal.org/project/simplesamlphp_auth/issues/3127628#comment...

If it does not solve it, please share your feedback here instead of in the other issue thread.

This patch works great.

This patch works great but in my case, I don't want all anonymous users to go to their user page after SAML login and all already authenticated users to go to the admin/content page. I updated the patch and added configuration for anonymous users redirect and authenticated users redirect.

@albertski I installed your patch and tested it. It doesn't look like the 'anonymous' redirect config affects anything at all.

+    if ($this->account->isAnonymous()) {
+      $redirect = $this->config->get('anonymous_saml_login_redirect') ? $this->config->get('anonymous_saml_login_redirect') : '/user';
+    }

I think the reason might be that at the time this code is being executed, the user has already been logged in and therefore is not anonymous.

Otherwise the patch does seem to fix at least something. Further testing is commencing in production soon.

I have reviewed the patch in #3 and it worked great.

Without the patch:

1. /saml_login redirected me to my IdP to login
2. I logged in
3. Redirected to /user
4. Manually navigated to /saml_login after logging in
5. Received a 403 forbidden

With the patch:

1. /saml_login redirected me to my IdP to login
2. I logged in
3. Redirected to /user
4. Manually navigated to /saml_login after logging in
5. Redirected to my /user

We've had a number of patch #3 confirmations, so I'm marking this as RTBC.

As an aside, I tested the patch in #10 and the anonymous user redirect never fired, so it does not seem that the extra work there is in a working state at this time.

The patch works great in my case. +1 RTBC

I am using simpleSAMLphp Authentication 4.0.0 on 10.3.8 and the patch in #10 appears to apply cleanly and functions as I expect. [update] I did not test the anonymous firing so I yield to what others say.
+1 RTBC