Hi Ken,
Ken Paulsen wrote On 09/12/06 13:15,:
>
> Hi Jan,
>
> Yes, none of our links should behave this way, however, some still
> do. We should fix this.
Great!
>
> I'm curious... if we had done form-based authentication w/o the
> context root (/asadmin), would everything have worked?
Yes, to my knowledge.
After you've made the changes, you can try this for yourself by adding
this property to
the "__asadmin" virtual server in domain.xml:
<property name="sso-enabled" value="false"/>
Let me know how it goes!
Jan
>
> Ken
>
> Jan Luehe wrote:
>
>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>