Layer7 API Management

Expand all | Collapse all

CA SSO session cookie updates reverts custom zone to SM ?

Jump to Best Answer
  • 1.  CA SSO session cookie updates reverts custom zone to SM ?

    Posted 01-25-2018 02:10 PM

    Ok, so the way the SiteMinder SSO Zones are implemented seems really weird.

     

    From what it looks like the only time a zone is set by the API GW is during the "authenticate" call and otherwise it overwrites to SM. But if a user already has a session cookie and you perform a cookie update to maintain the idle timeout values...it overwrites the zone to default SM.

     

    How exactly can I maintain session state of a user session cookie if I can only define a SSO zone on the Authenticate and while passing in a credential like username+pass or certificate...???

     

    Example:

    • Require HTTP Cookie (name=MYZONESESSION)
    • Request: Authenticate Against CA Single Sign-on
      • Use Last Credentials selected
      • Use SSO Token from Context Variable: cookie.MYZONESESSION
    • Request: Authorize via CA Single Sign-on
    • Request: Update Cookie(s) if name equals MYZONESESSION
      • Name=MYZONESESSION
      • Value=${siteminder.smcontext.ssotoken}

     

    Behavior:

    • User accesses a Web Agent in MYZONE and logs in
    • User is happy and goes to API GW Application
    • API GW verifies session
    • API GW rewrites cookie with updated value in SM zone now
    • User goes over to MYZONE Web Agent
    • User is requested to log in again because of zone mismatch
      •  MYZONESESSION cookie - mismatched SSOZone 'SM'.]

     

    Am I missing something really simple/obvious here?? 



  • 2.  Re: CA SSO session cookie updates reverts custom zone to SM ?
    Best Answer

    Posted 01-26-2018 03:31 PM

    Ok, guess it's a bug possibly fixed in 9.2 CR7 but bug is still present on base 9.3 so gotta wait for CR 1 for that (doesn't look like it's out yet).



  • 3.  Re: CA SSO session cookie updates reverts custom zone to SM ?

    Posted 01-30-2018 05:25 AM

    You are correct. It is expected to be fixed for CA API Gateway 9.3 with the upcoming CR release.