Environment
Novell Access Manager 3.1 Linux Access Gateway
Novell Access Manager 3.1 Linux Novell Identity Server
Novell Access Manager 3.1 Windows Novell Identity Server
Novell Access Manager 3.1 Linux Novell Identity Server
Novell Access Manager 3.1 Windows Novell Identity Server
Situation
the following is a list of common questions and answers regarding the Access Manager cookies visible with transactions to user agents.
Q1) How many cookies does Access Manager have and names are they assigned?
ANSWER->
- At the Access Gateway HTTP proxy, we have the session cookie IPCZQX03a36c6c0a. The cookie value uniquely represents the user that has authenticated to the proxy for the proxy domain.
Set-Cookie: IPCZQX03a36c6c0a=00000000c0a81ede156fc9f38f3ac37a8221c525; path=/; domain=.dub.novell.com
- At the Access Gateway HTTP proxy, we also have the "persistence cookie", which is set when you define multiple web server IP addresses. It provides a way of guaranteeing that the same back end Web server always received the requests sent on by the proxy server for a user session, and that the requests are not bounced between the remote web servers defined in the list.
Set-Cookie: ZNPCQ003-35383900=ae791e2f; path=/; domain=innerweb.novell.com
- At the Access Gateway embedded service provider (ESP), we have the session cookie JSESSIONID. This is the standard tomcat session cookie
Set-Cookie: JSESSIONID=9B994C5B6B4184F5D9B2C8FBB36BB202; Path=/nesp
There are additional session cookies set when multiple Access Gateway ESPs devices are clustered together (check out KB 7004089 for more details)
Set-Cookie: UrnNovellNidpClusterMemberId=~03~0Bslo~0A~0B~14mop~0C~0B; Path=/nesp
Set-Cookie: urn:novell:nidp:cluster:member:id=~03~0Bslo~0A~0B~14mop~0C~0B; Path=/nesp
- At the Identity Server (IDP) we have the same session cookie (JSESSIONID) and cluster cookies as those documented in the ESP section of the LAG above. The only difference is the path the cookie applies to.
Set-Cookie: JSESSIONID=751ABD91D4AB3822B57EB383DA4BFFB4; Path=/nidp; Secure
Set-Cookie: UrnNovellNidpClusterMemberId=~03~0Bslo~0A~0B~14mop~0C~09; Path=/nidp
Set-Cookie: urn:novell:nidp:cluster:member:id=~03~0Bslo~0A~0B~14mop~0C~09; Path=/nidp
----------
Q2) What is the size of each cookie *value*?
- For example, JSESSIONID=9B994C5B6B4184F5D9B2C8FBB36BB202
(the size of the "JSESSIONID" value is 32 bytes)
ANSWER->
32 byte for the JSESSIONID cookie to the IDP/ESP servers
28 byte for ESP/IDP cluster cookie
40 byte for Proxy session cookie
8 bytes for the web server persistence cookie
----------
Q3) Why do we have both "UrnNovellNidpClusterMemberId" and "urn:novell:nidp:cluster:member:id" cookies? The value looks the same but cookie name format is different.
ANSWER->
Cookies should NOT have a ":" character in the cookie name based on RFC compliance. Access Manager 3.0 incorrectly included the colon ':' character initially. We removed this in recent builds (hence two the same) but left the old one in for backward compatibility (in cases we have a cluster of different versions).
----------
Q4) What is "UrnNovellNidpClusterMemberId" used for?
ANSWER->
This cookie is used by an IDP/ESP server to proxy requests to IDP/ESP server that owns the user session ie. the IDP/ESP server that the load balancer initially sent the request to and that the user subsequently authenticated to.
Q1) How many cookies does Access Manager have and names are they assigned?
ANSWER->
- At the Access Gateway HTTP proxy, we have the session cookie IPCZQX03a36c6c0a. The cookie value uniquely represents the user that has authenticated to the proxy for the proxy domain.
Set-Cookie: IPCZQX03a36c6c0a=00000000c0a81ede156fc9f38f3ac37a8221c525; path=/; domain=.dub.novell.com
- At the Access Gateway HTTP proxy, we also have the "persistence cookie", which is set when you define multiple web server IP addresses. It provides a way of guaranteeing that the same back end Web server always received the requests sent on by the proxy server for a user session, and that the requests are not bounced between the remote web servers defined in the list.
Set-Cookie: ZNPCQ003-35383900=ae791e2f; path=/; domain=innerweb.novell.com
- At the Access Gateway embedded service provider (ESP), we have the session cookie JSESSIONID. This is the standard tomcat session cookie
Set-Cookie: JSESSIONID=9B994C5B6B4184F5D9B2C8FBB36BB202; Path=/nesp
There are additional session cookies set when multiple Access Gateway ESPs devices are clustered together (check out KB 7004089 for more details)
Set-Cookie: UrnNovellNidpClusterMemberId=~03~0Bslo~0A~0B~14mop~0C~0B; Path=/nesp
Set-Cookie: urn:novell:nidp:cluster:member:id=~03~0Bslo~0A~0B~14mop~0C~0B; Path=/nesp
- At the Identity Server (IDP) we have the same session cookie (JSESSIONID) and cluster cookies as those documented in the ESP section of the LAG above. The only difference is the path the cookie applies to.
Set-Cookie: JSESSIONID=751ABD91D4AB3822B57EB383DA4BFFB4; Path=/nidp; Secure
Set-Cookie: UrnNovellNidpClusterMemberId=~03~0Bslo~0A~0B~14mop~0C~09; Path=/nidp
Set-Cookie: urn:novell:nidp:cluster:member:id=~03~0Bslo~0A~0B~14mop~0C~09; Path=/nidp
----------
Q2) What is the size of each cookie *value*?
- For example, JSESSIONID=9B994C5B6B4184F5D9B2C8FBB36BB202
(the size of the "JSESSIONID" value is 32 bytes)
ANSWER->
32 byte for the JSESSIONID cookie to the IDP/ESP servers
28 byte for ESP/IDP cluster cookie
40 byte for Proxy session cookie
8 bytes for the web server persistence cookie
----------
Q3) Why do we have both "UrnNovellNidpClusterMemberId" and "urn:novell:nidp:cluster:member:id" cookies? The value looks the same but cookie name format is different.
ANSWER->
Cookies should NOT have a ":" character in the cookie name based on RFC compliance. Access Manager 3.0 incorrectly included the colon ':' character initially. We removed this in recent builds (hence two the same) but left the old one in for backward compatibility (in cases we have a cluster of different versions).
----------
Q4) What is "UrnNovellNidpClusterMemberId" used for?
ANSWER->
This cookie is used by an IDP/ESP server to proxy requests to IDP/ESP server that owns the user session ie. the IDP/ESP server that the load balancer initially sent the request to and that the user subsequently authenticated to.