Receiving Correct Response but No Authentication

[masonry47]

Hey @dsmrt!

We are having a new issue. In short, all seems to be working correctly but the user does not actually get logged in. We are using a SAML Response tool and see everything come back as we would expect it to. The login url successfully gets us to the IDP, we are able to successfully authenticate there and then are returned to our site but are not logged in. We have turned on dev mode to see if there is anything relevant in the logs and there doesn't seem to be. Really the only thing unique in this setup compared to another one we have done is the IDP is handling the relay URL. And our relay parameter is being ignored. Could that have anything to do with the issue.

Thanks as always for you amazing support!

[dsmrt]

:wave: @masonry47,

Thanks for the kind words. SAML has it's own unique issues and can be confusing so I try and make up for it with quick responses.

So, if I understand this correctly, it looks like everything is working but the user is not logged in once the auth process is finished?

1. Can you see saml logs going through the login process once the IdP returns the user to the Craft site? Once the user's returned to the site (sent back to /sso/login/<uid>), logs should show some activity here. Any errors?
2. Via logging or in the SAML Response tool, look at the host / domain / url and make sure they are pointing the same place. For example, if the return url is "https://www.example.com/sso/login" but the user ultimately lands on "https://example.com/sso/login", the cookies might not transfer over correctly, and the user won't be logged in. Watch out for "https" vs "http" here too.

Check these and let me know how this goes.

[masonry47]

Thanks!

on #1, assuming. you mean web.log, though a little tough for me to read what is happening in there, there is no errors for sure. Should we see some of the user attributes in the log? Because we do not.

On #2 are you saying this URL

Should match where the user is redirected to exaclty?

[dsmrt]

1) Here's a good way to tail and grep the contents of the web.log, as events are coming through.

tail -f storage/logs/web.log | grep -A 10 '\[saml-'

2) That "Destination" should match the Assertion Consumer Service (ACS) location so there seems to be a configuration issue there (which is likely the problem). The IdP should be sending the user back to a url similar to http://example.com/sso/login/<uid>. There is probably a URL in the IdP configuration that needs to be updated. Hopefully they call this Assertion Consumer Service, but it depends on the IdP. What IdP are you using? Also, see my screenshot below to know where to find the ACS in your Craft install.

[masonry47]

Thanks! When running the Tail command we just get this on the login event (just replaced urls -- idp.url.com is the IDP and https://sub.site.com is the craft site ). Meaning after clicking "Login Via IDP" being taken to the IDP login, logging in and then returning to the Craft site (but failing to to login to Craft). So this doesn't seem like it is telling us much. The IDP is an instance of Drupal with a plugin installed. We successfully connected with a staging version of it, so thinking it must be a config issue (see your second point) on the IDP side??

[dsmrt]

That’s just the authnreqest which is builds the request and sends it through the browser to the IdP. I don’t see logging for the Response which is inline with no. 2 of my previous comment.

That "Destination" should match the Assertion Consumer Service (ACS) location so there seems to be a configuration issue there (which is likely the problem). The IdP should be sending the user back to a url similar to http://example.com/sso/login/. There is probably a URL in the IdP configuration that needs to be updated. Hopefully they call this Assertion Consumer Service, but it depends on the IdP. What IdP are you using? Also, see my screenshot below to know where to find the ACS in your Craft install.

The IdP is incorrectly configured to return the use to the home page and not the /sso/login endpoint (which processes the saml stuff). Fix the ACS url on the IdP side.

[masonry47]

got it. makes sense! We will check on that config and thanks as always.