000016103 - AxM agents 4.8 and 4.9: problem with ISSO Cookies

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000016103
Applies ToAccess Manager Agent 4.9
Access Manager Agent 4.8 HF 4.8.0.33 for IIS6 and Acess Manager Agent 4.8.0.36 for Sun Web Server 7
ISSO (Inter-site Single Sign On)
IssueAXM agents 4.8 and 4.9: problem with ISSO Cookies
Two different cookie domains are configured on the same agent for Inter-Site Single Sign-On (ISSO). In this configuration, domainA, acts as an ISSO master, and domainB its slave domain. When a user tries to access a resource in domainA after successfully authenticating in DomainB, the user is incorrectly re-prompted to authenticate in domainA.
Cause Internet Explorer 7 blocks the third party cookies with no privacy policy.
ResolutionThe RSA ISSO functionality in the agent, instead of providing an option to allow Third party cookies, incorrectly overrides the behavior.  RSA has corrected this behavior in the 4.8 agent in hotfix 4.8.0.33, and in the 4.9 agent. Contact Customer support and request the latest 4.8 and 4.9 agent.
Latest post fix ISSO flow with 3rd party cookie issue resolved:

User logs on slave domain first, and then accesses a page on master domain.

    * Open a new browser session
    * Browser requests: GET http://www.slavedomain.com/protectedx509/test.html
   
* Slave domain responds:  HTTP 302 (Moved Temporarily) redirect to location

http://www.masterdomain.com/cleartrust_issopix?MOACT=MOFETCHCOOKIE&MOORD=http://www.slavedomain.com&MOORU=%2Fprotectedx509%2Ftest.html&MOSIG=<signature>

          o Since it?s a slave domain and no CT SSO cookie is present (user is no logged on), Slave domain needs to check with Master domain if user is already logged on.
          o The above redirect URL is constructed by Slave domain to get Master domain to send back the CT SSO cookie if user is already authenticated.  Details on how the above URL is constructed:

-         ?http://www.masterdomain.com? is picked up from the parameter ?cleartrust.agent.isso.master_url? in Slave domain?s webagent.conf

-         ?/cleartrust_issopix? would trigger ISSO WAX to take an action on Master domain

-         ?MOACT=MOFETCHCOOKIE?, added by the ISSO WAX, reflects a request from Slave domain to Master domain to fetch a SSO cookie (if user is already authenticated to Master domain, i.e., a CT SSO cookie exists for the Master domain)

-         ?MOORD=http://www.slavedomain.com? reflects the original domain (picked up from cleartrust.agent.isso.self_url of the Slave domain webagent.conf.

-         ?MOORU=%2Fprotectedx509%2Ftest.html? represents the original URI

-         ?MOSIG=<signature>? represents authentication signature of some data to authenticate the Slave domain to the Master domain

    * Browser requests: GET http://www.masterdomain.com/cleartrust_issopix?MOACT=MOFETCHCOOKIE&MOORD=http://www.slavedomain.com&MOORU=%2Fprotectedx509%2Ftest.html&MOSIG=<signature>
    * Master domain responds:  HTTP 303 (See Other) redirect to Location http://www.slavedomain.com/cleartrust_issopix?MOACT=MODAUTH&MOORU=%2Fprotectedx509%2Ftest.html.

         
o ?/cleartrust_issopix? would trigger ISSO WAX to take an action on Slave domain
          o ?MOACT=MODAUTH? reflects Master domain?s response that the user needs to be authenticated
          o ?MOORU=%2Fprotectedx509%2Ftest.html? is the original requested URI

    * Browser requests:  GET http://www.slavedomain.com/cleartrust_issopix?MOACT=MODAUTH&MOORU=%2Fprotectedx509%2Ftest.html

         
o No CT SSO cookies in the header, yet.

    * Slave domain responds:  HTTP 302 (Moved Temporarily) redirect to CT logon page Location /cleartrust/ct_logon.asp?CTAuthMode=BASIC&language=en

          o CT URI retention cookie ACTSESSION is set at this time.

    * Browser requests:  GET http://www.slavedomain.com/cleartrust/ct_logon.asp?CTAuthMode=BASIC&language=en (followed by GET images included in the logon page)
    * Slave domain responds:  Serves the logon page (and related images) with HTTP 200
    * Browser requests:  POST http://www.slavedomain.com/cleartrust/ct_logon.asp with data ?auth_mode=basic&orig_url=&user=testuser01&password=1234&x=22&y=10?
    * Slave domain responds:  HTTP 302 redirect to Location /cleartrust/ct_home.asp?language=en&ctsn=<token>&masterURL=http%3A%2F%2Fwww.masterdomain.com&ct_orig_uri=%2Fprotectedx509%2Ftest

          o The redirect is also accompanied with a CT SSO cookie (CTSESSION).  The above redirect URL is constructed by Slave domain to pass SSO cookie to Master domain so the user is logged on to the Master domain as well.  Details on how the above URL is constructed:

-         ?/cleartrust/ct_home.asp?, the home page configured in Slave domain?s webagent.conf

-         ?ctsn=<token>?, added by the ISSO WAX, is the SSO cookie being passed from Slave to Master domain.

-         ?masterURL=http%3A%2F%2Fwww.masterdomain.com? reflects the URL provided for cleartrust.agent.isso.master_url in Slave domain?s webagent.conf

-         ?ct_orig_uri=%2Fprotectedx509%2Ftest? is the original requested URI

    * Browser requests:  GET http://www.slavedomain.com/cleartrust/ct_home.asp?language=en&ctsn=<token>&masterURL=http%3A%2F%2Fwww.masterdomain.com&ct_orig_uri=%2Fprotectedx509%2Ftest.html

    * Slave domain responds:  Serves the requested page with HTTP 200

          - The page, ct_home.asp (aka "CT home page"), includes a reference to a specific page on Master domain, which will pass SSO cookie and
             log the user on master domain.  The home page also has a META HTTP-EQUIV ?Refresh? command to redirect to the original requested URI.

           -Browser requests: 
                  GET http:// www.masterdomain.com/cleartrust/images/ct_isso.html?MOCKE=<token>&ct_orig_uri=http://slave_domain/page.html

           - Master domain will process and set the CTSESSION cookie for the master domain, and would redirect either to slave page specified in
             ct_orig_url or to master domain's ct_access_denied page.

As exemplified above, the behavior is such that a redirect occurs to master domain's ct_access_denied page based on the value in trusted domain list. If trusted_domain_list is empty,. or has the value  of slave domain, the session will redirect to the slave. If trusted domain list is populated, but does not have the slave domain in the list, the session will be redirected to master domain?s access denied page.

    * Slave domain serves the requested page with HTTP 200
    * Browser requests:  GET http://www.masterdomain.com/protected/test.html

 Thusly, CTSESSION cookie that was previously set for master domain is included in the request header.
NotesAlso refer to Solution a39666
Legacy Article IDa54612

Attachments

    Outcomes