I have been configuring a SAMLP Identity provider connection by following this documentation, which has been mostly successful:
However, when I initiate the login through my identity provider app (Okta), I see:
-
The SAML token is generated and posted to my Application Callback Url / Assertion Consumer Service Url (which looks like this: https://mydomain.auth0.com/login/callback?connection=MyConnectionName)
-
The Callback Url / ACS Url responds to the post with a 302 and redirects to itself, plus a couple of new parameters: https://mydomain.auth0.com/login/callback?connection=MyConnectionName &code=SOME_CODE &state=MY_ENCODED_DEFAULT_RELAY_STATE_URL
-
The Callback Url / ACS Url with the new params responds with a 400, and shows me the generic error page: “Oops! Something went wrong” with technical details that read:
invalid_request: You may have pressed
the back button, refreshed during
login, opened too many login dialogs,
or there is some issue with cookies,
since we couldn’t find your session.
Try logging in again from the
application and if the problem
persists please contact the
administrator.
In spite of the error page, the login itself is successful- as I can see because I can then hit my lock-widget-protected web-app, which shows in the “previously you logged in with” state and allows the user to proceed with a single click. The Auth0 logs also indicate a successful login:
- Occurred: a few seconds ago at
2017-08-22 21:17:53.925 UTC - Type: Success Login
- Description: (empty)
- Connection: MyConnectionName
- Application: MyApplicationName (APP_CLIENT_ID)
- User: (empty)
Raw:
{
"date": "2017-08-22T21:17:53.925Z",
"type": "s",
"connection": "MyConnectionName",
"connection_id": "con_A_CONNECTION_ID",
"client_id": "APP_CLIENT_ID",
"client_name": "MyApplicationName",
"ip": "MY_IP",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
"details": {
"original_profile": "{\"sessionIndex\":\"idSOME_ID_DIGITS\",\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier\":\"user@email.com\",\"nameIdAttributes\":{\"value\":\"user@email.com\",\"Format\":\"urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress\"},\"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod\":\"urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport\",\"issuer\":\"http://www.okta.com/SOME_OKTA_HASH\"}",
"prompts": ],
"initiatedAt": 1503436673720,
"completedAt": 1503436673923,
"elapsedTime": 203,
"stats": {
"loginsCount": 19
}
},
"user_id": "samlp|MyConnectionName|user@email.com",
"user_name": "",
"strategy": "samlp",
"strategy_type": "enterprise",
"log_id": "SOME_LOG_ID"
}
My goals are the following:
-
Get past the error with the Callback
Url / ACS Url upon redirect -
Redirect to MY_ENCODED_DEFAULT_RELAY_STATE_URL
after successful login (I think that
setting a default relay state url is
the way to achieve this)
How can I gain more information to continue troubleshooting this flow? I feel as though I’ve hit a dead end in terms of the generic error page (in spite of a SAML-driven session apparently being created), and no clues to chase in the Auth0 logs. I’ve experimented with many config permutations and I’m out of ideas. Thanks for your help!
Part 2:
After following the suggestion to change the Response Protocol configured in the connection IdP-Initiated SSO settings to SAML:
This seems to look closer to working solution, because I am now observing a sequence of successful POSTs to the ACS url, however there is no redirect to the RelayState URL. Instead, the sequence arrives at an infinite loop of POSTs to the ACS url with encoded SAML indicating an error state. Here is the observed sequence:
- Successful POST to ACS url with SAML form data (decoded, it shows Okta as the issuer), has RelayState
- Another successful POST to ACS url, (decoded SAML shows data from logged in user as attributes), also has RelayState
- (This is where I was hoping that the Auth0 application as the Service Provider would redirect to the RelayState url, but this does not happen)
- An infinite sequence begins with more POSTs (response code 200) with decoded SAML in the form data for the request showing a statusMessage that indicates “invalid thumbprint”.
@jmangelo you also wrote that “The fact that the redirect targets https://[tenant].auth0.com/login/callback?connection=[saml_connection] suggests that there is some incorrect configuration, because this redirect should be targeting an URL within the control of the client application itself.” - Is there some other place where I should be configuring the redirect from Auth0 as a Service Provider to my final destination end-user-webapp besides including a RelayState in the POST that’s initiated by the IdP? Should the Application Callback Url as configured in the SAML2 Web App Addon for my client application not be set to the ACS url? Thanks again.
Part 3: Solution!
After more experimentation, I’ve finally got a working solution. It turns out that the correct configuration for me using IdP-initiated SSO in this case was the following:
- Using OpenId Connect as the Response Protocol
- Moving my end-user-webapp url to the top of the list in my allowed callback urls for my Auth0 Service Provider application. I suspect that adding a redirect url in the query params field would have also sufficed. Perhaps RelayState had nothing to do with it.
Anyway, I hope this post can be helpful to others.