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.
Is there a way to turn off SSO per application? If no, then JMX http
connector will need enhancements to understand cookies. We should also
look at introducing a configuration to disable SSO for an application.
I would recommend creation of two enhancement requests.
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
>
>
>