Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-13819

SAML brokering with POST binding is broken by new SameSite policies

    Details

    • Sprint:
      Keycloak Sprint 40
    • Story Points:
      5
    • Steps to Reproduce:
      Hide

      1. Download Chrome Canary https://www.google.com/chrome/canary/
      2. Enable SameSite feature:

      3. Run chrome with flags: chrome --enable-features=SameSiteDefaultChecksMethodRigorously --enable-features=ShortLaxAllowUnsafeThreshold
      To disable temporary POST+Lax intervention that makes everything work in current released chrome

      4. Try to login using IDP that requires SAML POST Binding. If Keycloak is used as IDP, then it is this option:

      Show
      1. Download Chrome Canary https://www.google.com/chrome/canary/ 2. Enable SameSite feature: 3. Run chrome with flags: chrome --enable-features=SameSiteDefaultChecksMethodRigorously --enable-features=ShortLaxAllowUnsafeThreshold To disable temporary POST+Lax intervention that makes everything work in current released chrome 4. Try to login using IDP that requires SAML POST Binding. If Keycloak is used as IDP, then it is this option:
    • Docs QE Status:
      NEW
    • QE Status:
      NEW
    • QE Test Coverage:
      +

      Description

      New SameSite policy in Chrome sets SameSite=Lax by default to cookies without SameSite attribute.

      1. Let's have a SAML IdP using POST binding.
      2. User initiates authentication using this IdP.
      3. User logs in to the IdP.
      4. IdP performs final POST "redirect" back to Keycloak. SameSite=Lax removes cookies from this request and therefore Keycloak losts its session (AUTH_SESSION_ID cookie).

      Solution: Set SameSite=None to AUTH_SESSION_ID cookie.


      Original report

      When using SAML POST-binding to identity provider, Keycloak issues SAML AuthnRequest in http-POST request
      After authentication, Identity provider answers with http-POST request containing SAML Response

      There is AUTH_SESSION_ID cookie

      If SameSite is not set (current behaviour in 9.0.3 and in master), then it will be treated as `SameSite=Lax`
      If Keycloak sets `SameSite=Strict` (As in acceptance criteria), then it is `SameSite=Strict`

      In both cases AUTH_SESSION_ID cookie will not be sent in POST request from idp site to keyloak site, as per rfc:

      If the cookie's "samesite-flag" is not "None", and the HTTP
                request is cross-site (as defined in Section 2.1 then exclude
                the cookie unless all of the following statements hold:
      
                1.  "samesite-flag" is "Lax"
                2.  The HTTP request's method is "safe".
                3.  The HTTP request's target browsing context is a top-level
                    browsing context.
      

      POST method is not considered as "safe" = everything that is not `SameSite=None` will be rejected when using saml post binding.

      What happens if cookie is not present:

      2020-04-15 ;07:26:47.413 [default I/O-2] DEBUG io.undertow.request : Matched prefix path /auth for path /auth/realms/master/broker/saml/login
      2020-04-15 ;07:26:47.414 [default task-3424] DEBUG org.keycloak.services.managers.AuthenticationSessionManager : Not found AUTH_SESSION_ID cookie
      2020-04-15 ;07:26:47.414 [default task-3424] TRACE org.keycloak.events : type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=master, clientId=null, userId=null, ipAddress=x.x.x.x, error=invalid_code, identity_provider=saml
      

      Defaulting to SameSite=Lax (if no SameSite is present) may stop work in the future when chromium starts to enforce Lax and remove workarounds.
      see: https://www.chromium.org/updates/same-site

      “Lax + POST” is an intervention for Lax-by-default cookies (cookies that don’t specify a `SameSite` attribute) which allows these cookies to be sent on top-level cross-site POST requests if they are at most 2 minutes old. “Normal” Lax cookies are not sent on cross-site POST requests (or any other cross-site requests with a non-idempotent HTTP method such as PUT). This intervention was put in place to mitigate breakage to some POST-based login flows.

        Gliffy Diagrams

          Attachments

          1. Welcome to Keycloak - Google Chrome 2020-04-16 20-26-50.mp4
            11.32 MB
          2. sp-100-8091.json
            60 kB
          3. screenshot-3.png
            screenshot-3.png
            130 kB
          4. screenshot-2.png
            screenshot-2.png
            140 kB
          5. screenshot-1.png
            screenshot-1.png
            81 kB
          6. image-2020-04-17-07-02-04-197.png
            image-2020-04-17-07-02-04-197.png
            111 kB
          7. image-2020-04-17-06-58-51-018.png
            image-2020-04-17-06-58-51-018.png
            73 kB
          8. idp-101-8092.json
            64 kB

            Issue Links

              Activity

                People

                • Assignee:
                  vmuzikar Václav Muzikář
                  Reporter:
                  andrei.bastun Andrei Bastun
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  10 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: