locked
ADFS 3.0 Google Apps Signout RRS feed

  • Question

  •  have implemented ADFS 3.0 for our Google domain, but I haven't been able to get sign out to work consistently. I have set the Endpoint logout URL and set the logout url in the google domain to https://login.mydomain.com/adfs/ls/?wa=wsignout1.0 but it seems that signout more often than not does not work. The users lands on my page saying they have signed out, but if they return to mail.mydomain.com they are still signed into Google.

    I'm not sure if this document applies to on-prem ADFS, but if you look at the limitations section it make it sound like wsignout1.0 won't work with Google

    https://msdn.microsoft.com/en-us/library/dn223670.aspx

    The other option that seems like it might work is to enable "Users are required to provide credentails each time at sign in." Under Authentication Police for <RP>, but for our environment this breaks integration through a SSO portal that we want to use.

    Anyway if anyone had any thoughts on this issue I'd like to hear them.

    Wednesday, September 28, 2016 2:57 PM

All replies

  • Hello Roger, 

    Can you check if this post  will be helpful 

    https://social.technet.microsoft.com/Forums/lync/en-US/b562c9a5-6d05-4a19-bd39-cb1bf9f77c4a/adfs-and-google-apps-sso-signout-url?forum=winserverDS


    Linus || Please mark posts as answers/helpful if it answers your question.

    Thursday, September 29, 2016 4:55 AM
  • Yes, I have tried that, but it looks like wsignout1.0 only works with WS-Fed configurations not SAML.

    What I have found is that the SamlSession cookie is not being expired/destroyed on logout so now my hope is to add some javascript to my onload.js that will expire the cookie, but I haven't figured out how to trigger the js only at logout.

    Thursday, September 29, 2016 3:34 PM
  • The SP should provide a sign-out endpoint.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, September 29, 2016 7:19 PM
  • Hi Pierre,

    Could you explain a bit more? I'm facing the same issue (not with Google, but another SaaS application using SAML) and I must say that what I'm reading here and there is quite confusing !

    A lot of blogs/forum posts are saying that just calling ?wa=wsignout1.0 is enough, which doesn't seem to be the case. Even if it was, I don't understand how it could logout from only a single app since you don't provide any detail in the logout URL.

    Some other are saying that you need to send a specific SAML logout query, but don't really explain how to build it.

    Also I believe that the session cookie created by ADFS needs to be destroyed in order to really logout, but I'm not sure if this should be handled by ADFS or by the SaaS app... I guess ADFS, but then back to my first point :/

    I called the SaaS provider too, and they don't seem to really know what to do neither..

    As I said, I'm quite confused (you can probably tell ^^), so any help would be greatly appreciated.

    Thanks!




    • Edited by CyrAz Saturday, October 1, 2016 12:11 PM
    Saturday, October 1, 2016 12:08 PM
  • The .../adfs/ls/?wa=wsignout1.0 is a endpoint that ADFS use to sign-out from WS-Federation trust parties. Not SAML trust parties. How come it works for WF-Federation trust without providing an endpoint? Just because on the specs of this protocol, the endpoint for login is the same as the endpoint for logout. So when you are hitting the URL mentioned above, the user-agent (your browser) is actually sending a logout request to the relaying party.

    When you authenticate against ADFS, ADFS gives you a SAMLSession cookie. This is not the cookie consumed by the application (so not sent to the SP), this is just a cookie reflecting that you have a session with the ADFS (which is the IDP in that case). When you access the SP, the SP is providing a bootstrap cookie to maintain a session with the user-agent (I guess it doesn't have to, but that's the common way). This cookie also needs to be destroyed during the process of logout, so at some point you need to hit an endpoint hosted in the namespace of the SP (only applications hosted in the same namespace as the cookie's namespace can modify/delete a cookie).

    SAML implements a Single Logout Protocol on which the logout request can come either from the SP or the IDP. When you create a SAML trust in ADFS, you can enter an endpoint for this logout protocol (by the way, generally it also means that the Token contains a name ID  - or an encrypted ID - to help the SP to know what session to destroy eventually, I guess). If you want to start it on the IDP, then the IDP needs to know where to redirect the request to (the Logout endpoint set on the trust). If it starts on the SP, then the SP is crafting something (a SAML Logout request as defined in the SAML Core specs I'd assume) and either:

    - post it (an actual HTTP POST request) to the IDP (which I believe is just the URL .../adfs/ls) in that case there is nothing else in the URL since the actual SAML request to logout in the the body of the POST message

    - redirect it to the IDP (which is also just the URL .../adfs/ls) but this time you can see stuff in te URL (usally ?SAMLRequest=lalala where lalala is constructed by the SP, you cannot make it up -the format is a deflated SAML).

    So if you are using an ADFS URL in your SAML trust property tab, you are asking ADFS to redirect to ADFS to destroy the session where in fact it should redirect to an endpoint hosted by the SP that will know what to do with the request (and probably initiate the destruction of the bootstrap cookies).

    Hope this helps...


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.



    Saturday, October 1, 2016 3:02 PM
  • You can actually see those 2 SAML endpoints on ADFS in the metadata:

    <SingleLogoutService Location="https://adfs.piaudonn.com/adfs/ls/" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
    
    <SingleLogoutService Location="https://adfs.piaudonn.com/adfs/ls/" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>

    These information will tell the SP where to post or redirect the useragent once they initiate a SP logout. These have to be used by the SP, not by the IDP. The SP should provide an equivalent for you to add in the trust property in the ADFS console.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.


    Saturday, October 1, 2016 3:13 PM
  • Oh and last thing, this is not specific to ADFS. Regardless of the IDP-STS you use, if you want to support Single Logout for SAML trust, the SP has to provide an endpoint.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Saturday, October 1, 2016 3:15 PM
  • Thanks Pierre!

    I think I'm mostly following you, but from what I understand you are explaining how the logout for the SaaS application should be handled.

    This is not my current issue : what I'm facing is that when I'm clicking "logout" on the SaaS app, I'm actually logged out from the app.

    But when I go back to the app logon URL, it opens a session without asking for my credentials. You can see that it's actually  loading a new session, it takes a while and shows a "loading" screen... it's not just reopening an already active session.

    I can also see that when I hit the app's logon URL, the app redirects me to ADFS but then I guess ADFS says "user already logged in" (in ADFS), so "no need to ask for credentials again, granting access to the relying party" and then it proceeds with loading the app.

    This is why I was asking about destroying the ADFS cookie in the first post...

    Hope I'm clear enough!

    Monday, October 3, 2016 9:06 AM
  • "This is not my current issue : what I'm facing is that when I'm clicking "logout" on the SaaS app, I'm actually logged out from the app.

    But when I go back to the app logon URL, it opens a session without asking for my credentials."

    That is the thing. The logout has to be handle by both the SP and the IDP. No matter who starts it, at some point both need to be aware of the logout.

    Anyhow, if you don't have a logout endpoint for the SP, you can't properly log out.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, October 3, 2016 12:35 PM
  • I did configure a logout endpoint for the SP, as described here : https://blog.msresource.net/2015/12/09/configuring-saml-sign-out-in-active-directory-federation-services-ad-fs/

    But then again, I'm back to "A lot of blogs/forum posts are saying that just calling ?wa=wsignout1.0 is enough, which doesn't seem to be the case"

    To be more specific, "what I'm facing is that when I'm clicking "logout" on the SaaS app, I'm actually logged out from the app." and redirected to http://auth.mydomain.com/adfs/ls/?wa=wsignout1.0 , which displays "You have successfully signed out".

    And then "when I go back to the app logon URL, it opens a session without asking for my credentials."

    So I guess I'm still missing something here...


    • Edited by CyrAz Monday, October 3, 2016 1:43 PM
    Monday, October 3, 2016 1:43 PM
  • As Pierre states /?wa=wsignout 1.0 is not sufficient. That may avoid any immediate browser errors, but in reality it's not logging you out at the IdP. From experience, when using SAML 2.0 RPs, if the SAML SP signs the logout request then AD FS is happy. Per the SAML Specs:

    4.4.3.1, "The <LogoutRequest> message MUST be signed if the HTTP POST or Redirect binding is used."

    If Google Apps is not doing that, that may explain any error you're getting on the AD FS side.


    http://blog.auth360.net

    Tuesday, October 4, 2016 1:01 AM
  • I found it odd that google wouldn't provide an Sign-out endpoint though... Have you tried their support and/or community?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, October 11, 2016 10:33 AM
  • I'm also having an issue getting ADFS 3.0 and GSuite to log out my users. Was there ever a clear answer to this question? If I'm reading this correctly, the Sign-out URL field in Google Admin settings should points to <your domain>/adfs/ls/ and the trust URL for the logout endpoint in my relaying trust properties should be set to aGoogle logout URL?
    Friday, July 14, 2017 6:58 PM
  • If you want to sign-out you of the app, your browser will need to delete the bootstrap cookies provided by the app. And only the App can do it, not ADFS. So the endpoint for logout has to be pointing to the App (and the app is supposed to provide this). If the app doesn't provide it, they it is entirely at the discretion of the App to manage the sign-out and you cannot trigger it from ADFS.

    Let's create a new thread to get fresh context and data if you'd like more details.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, July 17, 2017 6:36 PM
  • Cabel408,

    As Pierre mentions, according to the SAML 2.0 standard, it's incumbent on the SAML 2.0 SP to support this in Single Logout (SLO) scenarios via an endpoint, and use of a token signing cert to sign the logout request.

    It makes sense when you consider that Application A should not be able to demand sign-out from Application B. Accordingly, that app (SP) needs to credibly identify itself to the IdP (AD FS) courtesy of the signing certificate that was used when metadata was exchanged between SP/IdP, versus say Application B, C, Z etc..

    If the SAML SP/application Google Whatever (SAML-wise) does not conform to that requirement, then SLO won't be supported.


    http://blog.auth360.net


    • Edited by Mylo Wednesday, July 19, 2017 11:27 PM
    Wednesday, July 19, 2017 11:25 PM