tejua / gtm-oauth2

Automatically exported from code.google.com/p/gtm-oauth2
0 stars 0 forks source link

Authentication does not work with some SAML based SSO IdPs #15

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Login to an account with a sheffield.ac.uk (we use SAML SSO with Google). 
2. Get redirected to our internal CAS service (correct)
3. Get logged into our portal (incorrect... this generally happens because the 
URL query string is missing that tells CAS to redirect you back to our SAML IdP 
before getting passed to Google)

What is the expected output? What do you see instead?

OAuth Token never gets generated as Google never receives a valid SAML response 
from our IdP. 

What version of the product are you using? On what operating system?

Example application compiled from latest SVN.

Please provide any additional information below.

I've been discussing this problem with the developers of BusyCal. It seems that 
gtm-oauth2 is not playing nicely with our IdP. We get to the google sign in 
page, which on receipt of a sheffield.ac.uk domain redirects you to our SAML 
IdP, which in turn redirects you to our internal CAS servers (our internal 
authentication). By this point, the query string seems to have been removed, 
which causes our CAS server to log you into the default service (our internal 
portal) and the request never gets back to the Google SP. 

Original issue reported on code.google.com by a.j.bere...@sheffield.ac.uk on 17 May 2013 at 10:45

GoogleCodeExporter commented 9 years ago
Try setting a breakpoint at requestRedirectedToRequest: in GTMOAuth2SignIn to 
identify what's happening.

Can this be resolved by setting a custom redirectURI property in the auth 
object?

Original comment by grobb...@google.com on 21 May 2013 at 10:55

GoogleCodeExporter commented 9 years ago
After some investigation, I've discovered that this is due to the way GTMOauth2 
is overriding cookie handling. 

A workaround in the Sample application is to tick the "persist" tickbox which 
gets called in addCookiesToRequest. I'm not sure of a fix for it, but there's 
definitely something wacky going on in there - possibly in cookiesForURL. 

Original comment by a.j.bere...@sheffield.ac.uk on 5 Jul 2013 at 2:50

GoogleCodeExporter commented 9 years ago
can confirm this is failing for our SAML SSO too.

Any chance of getting this fixed ? 

Original comment by max.ande...@gmail.com on 29 Apr 2015 at 10:09