I've just a basic question. What I understand is, that AM realizes Web SSO via cookies. Now my questions are:
1. Are there any ways to configure SSO without cookies?
2. If the answer to question 1 is yes, how does it work and what configuration of AM / Policy Agents is needed?
Thanks in advance & best regards
Michael Arnold
Yes, AM completely rely on a cookie (default name iPlanetDirectoryPro) to achieve Web SSO. This cookie is a token for your SSO Session. All Policy Agents also rely on this cookie. Whenever an HTTP request go through the Policy Agent, it will check out whether this cook ie can be found, if yes, then validate it against AM. Without cookie, AM SSO is useless. If your environment is IP only (No DNS infrastructure), don't use AM for Web SSO.
Since cookie has limitation on DNS domain, AM solve this problem by configuring a common domain in which sub-domain cookie can be pass back and forth. For example, if app A is www.abc.xyz.com, app B is www.def.xyz.com, then you can choose .xyz.com as the common domain, and let cookie being set on this domain. Both app A and B can see it, so the iPlanetDirectoryPro cookie can be shared.
Policy Agent is proprietary, not just its usage of specific cookie but also the way it communicate with AM. PA use a low level protocol called PLL (developered by Sun Portal team long ago), it is infact HTTP + XML, but not SOAP.
If you insist to have Web SSO without cookie, you may think about
1. Use SAML
2. Abandon Sun Policy Agent
3. More custom code on app side
4. or product from other vendors.
AM is now moving to SAML/Federation side and the product focus should never be Enterprise SSO. It is good for Internet (b2c) ISP with pure Java environment. Remember, AM doesn't provide COM/ActiveX/.NET/PHP API (not like other open project such as JavaSSO), only C and Java API is available, but C API is not full featured.
my 2 cent
