Symantec Access Management

  • 1.  Anonymous Authentication Scheme in Cross Domain Single Sign On

    Posted Feb 17, 2015 02:26 AM

    Hi All,

    I have a query related to anonymous authentication scheme.

    We have an environment where two application are siteminder protected. App1 and App2 are in different domain space.

     

    App1 URL : it is protected with form based authentication.

     

    App2 URL : it is protected anonymous authentication scheme. It has cookie provider configured.

    CP cookie domain is same as of App1 cookie domain.

     

    Use case:

    Now there is a situation where user is logged in App1 and access an anonymously protected URL in App2. Since user is already logged in, so siteminder should pass headers for USER DN who is already logged in rather than considering it as anonymous user.

     

    Problem:

    Once logged in App1 and moving to anonymously protected URL, it is considering it as anonymous user i.e. App2 agent is not contacting cookie provider and creating local SMSESSION and then extracting User DN and generating headers for this user. Rather it is taking it as anonymous user.

     

    Query1:

    Is this an exptected behavious where moving in cross domain, smsession can't be utilized to evaluate headers for user already logged in for anonymous login?

     

    Query2:

    When we login in App1 and access a form based protected page of App2 and then accessing anonymously protected URL, it detects correct user DN and generated proper headers. Is it how siteminder should work ?

     

    Let me know if anyone has any views on it.

     

    Regards,

    Neeraj Tati



  • 2.  Re: Anonymous Authentication Scheme in Cross Domain Single Sign On
    Best Answer

    Posted Feb 18, 2015 03:39 PM

    Hello Neeraj NeerajChase

     

    Welcome to communities and good to see you here.

     

    • Infact a testing I did 2 years back points to the following.
      • We have 2 Cookie Domains e.g. a.com and b.com.
      • In the ACO of a.com cookie provider is set to b.com.
      • When User accesses a resource protected by Anon Auth Scheme in a.com.
      • No redirection happens to first check for existence of SMIdentity Cookie.
        • I understand that only when a realm requests creds [In case of AnonAuth no Cred is requested] does this redirect happen.
      • Moving on, a SMIdentity Cookie first get created for a.com and then a redirect is issued to b.com to set Master SMIdentity Cookie. No Validation happens on b.com for SMIdentity Cookie, just a set cookie is issued.
      • Even after SessionUpdatePeriod kicked in, no redirect to Cookie Provider was issued.
    • Below 3 bullet points then laid the foundation on SMIDENTITY Cookie and its usage in Multi-Domain Solution.
    • Anyone can access an anonymous resource, and impersonating an anonymous user is of little value.
    • The SMIDENTITY cookie is not a session cookie. Therefore one should not expect it to function at same levels of capacity as SMSession.
    • SMIDENTITY cookies offer no security control. Hence no validation happens on SMIDENTITY Cookie, like SMSession on CookieProvider redirects.

     

    These are some of the question that I asked when using AnonAuth + CookieProvider and here are the replies....

    1. Do we really support usage of Cookie Provider with Anon Authentication.
      • [REPLY] in a basic way, yes.  But it does not function exactly as the session use cases function.
    2. Is there really a need for Cookie Provider in case of Anon Auth.
      • [REPLY] No, not in the simplest form of anonymous.
    3. Anon Auth seems best used independently for each domain.
      • [REPLY] probably true as discussed above, though no formal statement is made to this effect.
    4. We do redirect to set a Master Identity Cookie, but to what cause and use. Instead could we not block the redirect (usuage of Cookie Provider under Anon Auth), unless it has significant advantage. This would save precious time, Webagent processing on Master WA and network bandwidth.
      • [REPLY] functions in simple configurations, but one should not expect to get the full set of session features form multi-domain SSO with an SMIDENTITY cookie.

     

     

    Hope all these points help you find your way. Bottemline, do not expect the WebAgent to function in the same way for Anonymous Authentication.

     

     

    Regards

     

    Hubert



  • 3.  Re: Anonymous Authentication Scheme in Cross Domain Single Sign On

    Posted Feb 20, 2015 10:55 PM

    Hello Hubert. Hope you are having a good time.

     

    Thanks for sharing your views on this. I just have one concern on the response you received when you asked questions.

     

    1. Do we really support usage of Cookie Provider with Anon Authentication.
      • [REPLY] in a basic way, yes.  But it does not function exactly as the session use cases function.

    I see that you also agree that redirect to cookie provider for settting up Master Identity Cookie is a waste of time. To me, it doesn't serve any purpose because it will not have logged in USER DN in SMIDENTITY cookie as no validation is happening for MCP SMSESSION.  Whey they say in a basic way yes, I am struggling to understand which use-case of cookie provider, it full fills.

     

    Based on the responses, I consider, AnonAuth+cookie provider combination is not supported.

     

    Let me know if you can think of any use-case.

     

    Regards,

    Neeraj



  • 4.  Re: Anonymous Authentication Scheme in Cross Domain Single Sign On

    Posted Feb 23, 2015 11:55 AM

    Neeraj

     

    I would not state explicitly "AnonAuth + CookieProvider" is not supported - it is not my decision to make. However based on findings and the way it works; it would be prudent to not use CP with AnonAuth as I do not see the benefit nor I can think of an usecase for AnonAuth with CookieProvider.

     

     

    Regards

     

    Hubert



  • 5.  Re: Anonymous Authentication Scheme in Cross Domain Single Sign On

    Posted Feb 27, 2015 10:31 PM

    Thanks for the help on this

     

    Regards,
    Neeraj