Hi Abhijit,
Abhijit Kumar wrote On 11/14/05 18:06,:
> asadmin uses JMX http connector, a simple http client that does not
> understand http cookies. Creating session does not help because the
> session cookie will not be understood. The other option is to use
> session but to make the client understand rewritten URL after sending "I
> do not accept cookies" header.
Yes.
> Is there a way to turn off SSO per application?
Currently, there isn't. SSO is configured at the virtual server
level. If enabled for a virtual server, all webapps deployed on that
virtual server will automatically participate in SSO.
However, we could define a webapp property ("ignore-sso") that would
allow a webapp to declare that it does not want to participate in SSO,
regardless of its virtual server's setting, but I'm not sure how useful
this would be in the general case. I think it would make more sense
to disable SSO for the __asadmin virtual server, because of the
2 webapps deployed on it, one ("adminapp") ignores any SSO ids in the
response, and SSO is useful only if the number of webapps that could
participate in it is greater than one.
> If no, then JMX http
> connector will need enhancements to understand cookies.
I think we should do this in any case, in order to avoid the penalty
of having to authenticate each and every asadmin request.
> We should also
> look at introducing a configuration to disable SSO for an application.
>
>
> I would recommend creation of two enhancement requests.
I already filed 6349895 earlier today.
Thanks,
Jan
> Jan Luehe wrote:
>
>
>>I made the observation that using the CLI (on PE), which
>>uses BASIC authentication, each and every HTTP request forces the
>>client to be reauthenticated on the server. For this to work, each
>>HTTP request from the CLI carries an "Authorization" header with some
>>prefabricated credentials, computed from the admin's name and
>>password, in order to avoid the "WWW-Authenticate" challenge from the
>>server.
>>
>>This overhead gets worse by the fact that SSO is turned on by default,
>>meaning that each time the client has been authenticated, an SSO entry
>>is created for the authenticated principal. I measured that for the
>>deployment of a single WAR file (via "asadmin deploy"), a total of
>>27 (!) SSO entries were created, each carrying the same authenticated
>>principal. Each SSO entry is stored in a map and keyed by its "ssoid",
>>a random number that is returned in the response (as the value of the
>>SSO cookie). This means that for each of the 27 identical SSO entries,
>>27 random numbers had to be generated - during a single "asadmin deploy"
>>command, and for no use.
>>
>>All SSO entries will eventually be purged (their max-inactive-interval
>>defaults to 5 minutes), but they should not be created in the first
>>place (or only one should be created and reused).
>>
>>We could avoid this overhead by having the server component that
>>processes the request create an HTTP session, which would cause the
>>web container to store the authenticated principal in that session and
>>avoid unnecessary reauthentications on subsequent requests. This would
>>require the CLI to include the session id in subsequent requests.
>>
>>If we don't want to create any sessions on the server, the CLI could
>>include the SSO id (received in the response) in subsequent requests,
>>which will also avoid unneccessary authentications on those requests.
>>
>>I'm not at all familiar with how the CLI currently processes the HTTP
>>responses from the server, and if it is capable of processing session or
>>SSO ids, but it's something we need to investigate (unless this is a
>>known issue). If this turns out to be impossible, we should at least
>>consider turning off SSO on the "__asadmin" virtual server.
>>
>>Please let me know what you think.
>>
>>
>>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
>