What is a CookieProvider and how does it work
search cancel

What is a CookieProvider and how does it work

book

Article ID: 247264

calendar_today

Updated On:

Products

SITEMINDER

Issue/Introduction

This article is to provide detailed information on how the cookieprovider works.

Environment

Release : 12.8.x

Component : Web Agent

Resolution

Before going into cookieprovider we need to understand the basic single cookiedomain use case with SiteMinder.

 

In a simple use case where only 1 cookie domain exist, lets say ".idp.lab"

 

A Protected application URL: https://www.idp.lab/protected/

Login URL: https://login.idp.lab/siteminderagent/forms/login.fcc

Logout URL: https://www.idp.lab/logout/

WARNING: Any URI that is set as logoffuri is automatically set as unprotected.

 

Flow of login:

  1. User visit https://www.idp.lab/protected/
  2. Get redirected to https://login.idp.lab/siteminderagent/forms/login.fcc&TARGET=https://www.idp.lab/protected/
  3. Submit valid credential and SMSESSION cookie gets set with domain=.idp.lab in the browser
  4. Redirect to TARGET https://www.idp.lab/protected/ with SMSESSION cookie
  5. User session is validated via SMSESSION

 

Flow of logout:

  1. User visits logoffuri https://www.idp.lab/logout/
  2. Agent detects the URI matches LogoffURI and terminates the session by setting SMSESSION=LOGGEDOFF

 

Flow or normal activity:

  1. There is no unexpected redirects to cookieprovider.

 

 

In a more complex use case, there may be multiple cookie domains.

For example, ".idp.lab" and ".sp.lab"

 

By design, web browsers will only submit cookies with matching cookie domain. A cookie with domain=.idp.lab will NOT be submitted to .sp.lab domain.

As a result, user will be challenged when navigating from .idp.lab to .sp.lab

 

Use case flow:

  1. User visit https://www.idp.lab/protected/
  2. Get redirected to https://login.idp.lab/siteminderagent/forms/login.fcc&TARGET=https://www.idp.lab/protected/
  3. Submit valid credential and SMSESSION cookie gets set with domain=.idp.lab in the browser
  4. Redirect to TARGET https://www.idp.lab/protected/ with SMSESSION cookie
  5. User session is validated via SMSESSION
  6. User navigates to a protected application in .sp.lab cookiedomain, https://www.sp.lab/members/
  7. SMSESSION cookie is not submitted and will be redirected to the authentication scheme URL that is protecting this /members/ realm. (for example, https://login.sp.lab/siteminderagent/forms/login.fcc&TARGET=https://www.sp.lab/members/)

 

Cookieprovider is a feature that allows SiteMinder Single Sign-On to extend to cross domain.

 

Prerequisites:

  1. Both .idp.lab and .sp.lab are configured in the same SiteMinder environment
    1. Same Policy Store Encryption Key(same KeyStore Encryption Key)
    2. Same Agent Keys
    3. Same User Store (same UserStore name and same userDN/userName)

 

Between the 2 cookie domains, one cookiedomain must be designated to act as a cookieprovider.

WARNING: You should not configure multiple cookiedomains to act as cookieprovider.

 

 

Setting up cookieprovider:

Let's say ".idp.lab" is to be the cookieprovider.

  1. All ACO that is setup for .idp.lab do not require any configuration changes.
  2. All ACO that is setup for .sp.lab require setting "CookieProvider=https://login.idp.lab/siteminderagent/smmakecookie.ccc"

NOTE: Any WebAgent enabled webserver can act as cookieprovider by default. https://www.idp.lab/siteminderagent/smmakecookie.ccc also works fine, it does not have to be the login.idp.lab server.

 

In this use case, both .idp.lab and .sp.lab ACO has logoffuri set to /logout/

Authentication Scheme protecting https://www.idp.lab/protected/ is redirecting to .idp.lab cookie domain.

Authentication Scheme protecting https://www.sp.lab/members/ is redirecting to .sp.lab cookie domain.

 

 

With cookieprovider in place, there are following use cases:

 

  1. Login via .idp.lab cookie domain
  2. Login via .idp.lab cookie domain and sso to .sp.lab
  3. Login via .idp.lab cookie domain and sso to .sp.lab and logout from .sp.lab
  4. Login via .idp.lab cookie domain and sso to .sp.lab and logout from .idp.lab
  5. Login via .sp.lab cookie domain
  6. Login via .sp.lab cookie domain and sso to .idp.lab
  7. Login via .sp.lab cookie domain and sso to .idp.lab and logout from .idp.lab
  8. Login via .sp.lab cookie domain and sso to .idp.lab and logout from .sp.lab
  9. Login via .idp.lab or .sp.lab and stay active at .sp.lab
  10. ".sp.lab" protected realms are configured with Authentication Scheme hosted on ".idp.lab" cookie domain.
  11. ".sp.lab" protected realms are configured with Authentication Scheme hosted on ".idp.lab" cookie domain and logout from .idp.lab
  12. ".sp.lab" protected realms are configured with Authentication Scheme hosted on ".idp.lab" cookie domain and logout from .sp.lab

 

 

#1. Login via .idp.lab cookie domain:

  1. Access https://www.idp.lab/protected/
  2. Redirect to https://login.idp.lab/siteminderagent/forms/login.fcc&TARGET=https://www.idp.lab/protected/
  3. Submit valid credential and SMSESSION cookie gets set with domain=.idp.lab in the browser
  4. Redirect to TARGET https://www.idp.lab/protected/ with SMSESSION cookie
  5. User session is validated via SMSESSION

 

#2. Login via .idp.lab cookie domain and sso to .sp.lab

  1. Same as #1.
  2. Access https://www.sp.lab/members/
  3. Get redirected to CookieProvider to check if there is a valid SMSESSION cookie https://login.idp.lab/siteminderagent/smmakecookie.ccc?SMSESSION=QUERY&TARGET=https://www.sp.lab/members/
  4. Browser submits SMSESSION cookie that was set for .idp.lab as the cookie domain matches.
  5. CookieProvider agent sets SMSESSION cookie in the URL and redirect to TARGET. https://www.sp.lab/members/?SMSESSION=AABBCCDD
  6. .sp.lab Agent consumes the SMSESSION cookie in the URL and sets SMSESSION cookie at the browser with "domain=.sp.lab", now there are SMSESSION in both cookie domains.
  7. As this is the first time SMSESSION cookie was set for this specific agent, it redirects to CookieProvider to update the SMSESSION cookie there.
  8. CookieProvider Agent updates SMSESSION cookie at the .idp.lab and redirects back to TARGET=https://www.sp.lab/members/

 

#3. Login via .idp.lab cookie domain and sso to .sp.lab and logout from .sp.lab:

  1. Same as #2 flow.
  2. Access https://www.sp.lab/logout/ and .sp.lab Agent sets SMSESSION=LOGGEDOFF then redirects to CookieProvider to terminate the session. https://login.idp.lab/siteminderagent/smmakecookie.ccc?SMSESSION=LOGOFF&TARGET=https://www.sp.lab/logout/
  3. CookieProvider Agent removes .idp.lab SMSESSION cookie and redirects to TARGET=https://www.sp.lab/logout/
  4. .sp.lab agent again sets SMSESSION=LOGGEDOFF and ends.

 

#4. Login via .idp.lab cookie domain and sso to .sp.lab and logout from .idp.lab:

  1. Same as #2 flow.
  2. Access https://www.idp.lab/logout/ and sets SMSESSION=LOGGEDOFF and ends.

WARNING: Please refer to SessionDriftPeriod section at the bottom of this article.

 

#5. Login via .sp.lab cookie domain:

  1. Access https://www.sp.lab/members/
  2. Redirect to CookieProvider to QUERY if there is a valid SMSESSION cookie. Browser did not have .idp.lab SMSESSION cookie.
  3. CookieProvider redirects to TARGET=https://www.sp.lab/members/?SMSESSION=NO telling the agent that there was no SMSESSION cookie and need to be challenged.
  4. Redirect to https://www.sp.lab/siteminderagent/forms/login.fcc&TARGET=https://www.sp.lab/members/
  5. Submit valid credential and SMSESSION cookie gets set with domain=.sp.lab in the browser
  6. Redirect to TARGET https://www.sp.lab/members/ with SMSESSION cookie
  7. User session is validated via SMSESSION

 

#6. Login via .sp.lab cookie domain and sso to .idp.lab:

  1. Same as #5
  2. Access https://www.idp.lab/protected/ and browser submits SMSESSION cookie. (Browser already obtained SMSESSION cookie for both cookie domains)
  3. User session is validated via SMSESSION

 

#7. Login via .sp.lab cookie domain and sso to .idp.lab and logout from .idp.lab:

  1. Same as #6.
  2. Access https://www.idp.lab/logout/ and .idp.lab SMSESSION is set to LOGGEDOFF and ends.

WARNING: Please refer to SessionDriftPeriod section at the bottom of this article.

 

#8. Login via .sp.lab cookie domain and sso to .idp.lab and logout from .sp.lab:

  1. Same as #6.
  2. Access sp.lab/logout/ and .sp.lab SMSESSION is set to LOGGEDOFF.
  3. Redirect to CookieProvider to terminate the session. https://login.idp.lab/siteminderagent/smmakecookie.ccc?SMSESSION=LOGOUT&TARGET=https://www.sp.lab/logout/
  4. CookieProvider removes .idp.lab SMSESSION cookie and redirects to TARGET https://www.sp.lab/logout/
  5. .sp.lab SMSESSION is again set to LOGGEDOFF(just because the URI matches logoffuri) again and ends.

 

#9. Login via .idp.lab or .sp.lab and stay active at .sp.lab:

  1. Same as #5.
  2. User is actively accessing the application and once the ACO Parameter SessionUpdatePeriod (Default is 60 seconds) has reached then the browser will be redirected to the CookieProvider to update the .idp.lab SMSESSION at the CookieProvider and return.

 

#10. ".sp.lab" protected realms are configured with Authentication Scheme hosted on ".idp.lab" cookie domain.

  1. Access https://www.sp.lab/members/ and get redirected to CookieProvider to QUERY if browser has .idp.lab SMSESSION cookie.
  2. No SMSESSION cookie was submitted to CookieProvider redirects to TARGET=https://www.sp.lab/members/?SMSESSION=NO
  3. www.sp.lab agent redirects to .idp.lab Login Page https://www.idp.lab/siteminderagent/forms/login.fcc?TARGET=https://www.sp.lab/members/
  4. User submits valid credential and gets .idp.lab SMSESSION cookie and redirect to TARGET=https://www.sp.lab/members/
  5. Browser does not have .sp.lab SMSESSION so it redirects to CookieProvider to QUERY if the browser has .idp.lab SMSESSION cookie.
  6. .idp.lab SMSESSION exist so CookieProvider redirects to TARGET=https://www.sp.lab/members/?SMSESSION=AABBCCDD
  7. www.sp.lab agent consumes SMSESSION cookie in the URL and sets .sp.lab SMSESSION cookie.
  8. As this is the firs time this SMSESSION was submitted to this www.sp.lab, it redirects to CookieProvider to update .idp.lab SMSESSION cookie.
  9. CookieProvider updates .idp.lab SMSESSION cookie and redirects to TARGET=https://www.sp.lab/members/

 

#11. ".sp.lab" protected realms are configured with Authentication Scheme hosted on ".idp.lab" cookie domain and logout from .idp.lab

  1. Same as #10.
  2. Access https://www.idp.lab/logout/ and .idp.lab SMSESSION cookie get set to LOGGEDOFF and ends.

WARNING: Please refer to SessionDriftPeriod section at the bottom of this article.

 

#12. ".sp.lab" protected realms are configured with Authentication Scheme hosted on ".idp.lab" cookie domain and logout from .sp.lab

  1. Same as #10.
  2. Access https://www.sp.lab/logout/ and .sp.lab SMSESSION cookie get set to LOGGEDOFF and redirects to CookieProvider to remove .idp.lab SMSESSION cookie.
  3. CookieProvider deletes .idp.lab SMSESSION cookie and redirects to TARGET=https://www.sp.lab/logout/
  4. .sp.lab agent sets SMSESSION=LOGGEDOFF (again simply because the request came into logoffuri) and ends.

#SessionDriftPeriod

When a user access SiteMinder protected resources, the user session gets cached so the agent communication to policy server can be reduced.

However, in case of #4 and #7, although user has logged out at the CookieProvider, www.sp.lab agent will not be aware of this until SessionUpdatePeriod is reached.

Until the SessionUpdatePeriod expires, www.sp.lab will continue to grant access to the protected resource from its session cache.

This time period where the agent continues to service request from session cache until it reaches the SessionUpdatePeriod is called SessionDriftPeriod.

 

#Options to reduce SessionDriftPeriod

  1. Reduce the SessionUpdatePeriod. Minimum value is 1. Setting it to 0 disables SessionUpdatePeriod.
  2. Disable SessionCache. This will impact performance as Agent communication to Policy Server will significantly increase.
  3. Use logout.fcc to logout and redirect to TARGET=https://www.sp.lab/logout/ (configured in the logout.fcc)
  4. Use Session Store. (The Persistent Realms involved will require short SessionValidationPeriod)

 



Powered by Wolken Software