As you remember, we tried disabling cross-context SSO for the "__asadmin"
virtual server in GF v1 in order to avoid the overhead generated by SSO
when it is not needed.
Disabling SSO would have been justified, because from the 2 webapps
deployed on "__asadmin", namely "adminapp" (CLI) and "admingui",
"adminapp" does not leverage SSO (it does not supply any cookies with
its requests, causing each request to be reauthenticated), and
cross-context SSO does not make any sense if only a single webapp (in
this case: "admingui") would participate in it.
Disabling SSO seemed like a sure bet, but after doing so, we ran into
this problem:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6401860
("Regression: download links doesn't function")
and had to back out disabling of SSO until we could further investigate
the failure.
I just took a closer look at the failure and found this:
A request for
http://<host>:<adminport>/
gets redirected to
http://<host>:<adminport>/asadmin/admingui/TopFrameset
where "/asadmin" is the declared context-root of the "admingui"
webapp, which protects its resources using FORM based authentication.
Consequently, FORM based authentication causes a session with path
"/asadmin" to be created, which stores the authenticated principal
("admin"). This session is associated with the "/asadmin" context.
Clicking on the "Download Client Stubs" link in the admin GUI causes
this request:
http://<host>:<adminport>/admingui/download/<some_appclient_jar_file>
which gets mapped to the "incarnation" of "admingui" as the
default-web-module of the "__asadmin" virtual server (which used
to be deployed as a separate web module at "").
Since this request's URI does not start with "/asadmin", the browser
does not include the cookie with path "/asadmin" with it (this is the
cookie carrying the id of the session with the authenticated principal),
forcing the request to be reauthenticated and causing the above failure.
Would it be possible for the admin GUI to not jump between "/asadmin"
and "", but use one or the other in the links it generates?
This way, it would be possible to disable cross-context SSO for
"__asadmin", and still make it possible for all "admingui" requests to share
the session with the authenticated principal.
Jan