Issues with AccountChooser Redirect with Google as IdP

[christiemathews]

Issues with AccountChooser Redirect with Google as IdP

Description

Fusionauth 1.19.8

Browser automatically advances through SAML IDP login with a different account than the entered email. As long as the entered email has the correct domain of the integrated IDP, the browser automatically uses whatever credentials it has saved for that IDP.

This can be prevented by using the AccountChooser redirect in the SAML request: https://accounts.google.com/AccountChooser?continue=https://accounts.google.com/o/saml2/idp?idpid=XXXXXXXXX

The only problem now is that the SAMLRequest parameter that is appended isn't part of the continue parameter so a SAML request isn't passed to the IDP endpoint.

[robotdan]

Thanks for the issue @christiemathews . Can you provide some additional details on how to recreate the issue exactly?

For example, please mention if FusionAuth is the IdP, or the SP, assuming from the comments that Google is the IdP and FusionAuth is the SP? But please clarify.

And then document the order of steps to configure, and login and where you see the symptoms so that we are able to recreate.

Thanks!

[christiemathews]

SP: FusionAuth 1.19.8 IdP: Google

1. Add a new SAML app to GSuite.

2. Use idpId & certificate to add an identity provider to FusionAuth.

3. Request used to integrate Google IdP with FusionAuth

   {
   "method": "POST",
   "url": "/api/identity-provider/#{idpId}",
   "body": {
     "identityProvider": {
       "domains": ["myapp.com"],
       "applicationConfiguration": {...},
       "lambdaConfiguration": {...},
       "emailClaim": "email",
       "idpEndpoint": "https://accounts.google.com/o/saml2/idp?idpid=XXXXX",
       "keyId": #{certificateId},
       "type": "SAMLv2",
       "useNameIdForEmail": false
     }
   }
   }

4. FusionAuth login: fusionauth.myapp.com/oauth2/authorize?client_id=XXXX&redirect_uri=XXXXX Since domains are specified, this just asks for an email address.

5. On entering email address with correct domain("user1@myapp.com"), FusionAuth redirects to Google SSO screen. Login successful - User can now use myapp.

6. Log out of myapp.

7. Attempt login again - this time use a different email address("user2@myapp.com").

8. Browser will skip past SSO screen (automatically using user1@myapp.com credentials). FusionAuth now logs into myapp with user1 rather than user2.

We attempted to resolve this by changing the idpEndpoint to https://accounts.google.com/AccountChooser?continue=https://accounts.google.com/o/saml2/idp?idpid=XXXXXXXXX. This doesn't work because the SAMLRequest Parameters appended to this endpoint are lost after the AccountChooser redirect.

[voidmain]

I believe this is working as expected because you didn’t log out of Google. Since Google is the IdP and uses long lived sessions (days or weeks or months), it makes sense that you are automatically logged back in as the first user. This is standard SSO behavior.

Can you confirm that you aren’t logging out of Google as part of your process? And can you also confirm that after logging out of myapp that you can still access Google services like Calendar or Gmail with the first user?

[christiemathews]

@voidmain, that’s a fair point, perhaps using google apps an IDP isn’t an incredibly applicable test for SSO. However, in this case, it seems the frustration could be avoided by using the AccountChooser endpoint that google provides. Would it be feasible to interpolate the SAMLRequest parameter using something like the variable notation used in kickstart? This would allow us to do the following for this case: https://accounts.google.com/AccountChooser?continue=https://accounts.google.com/o/saml2/idp?idpid=XXXXXXXXX%26SAMLRequest=#{SAML_REQUEST}

[voidmain]

That could work but will require the SAML identity provider code in FusionAuth to be updated to support token replacement. I wonder if there is a way to tell Google to pass parameters to the continue location. That would make this work using the current handling in FusionAuth.