glassfish
  1. glassfish
  2. GLASSFISH-81

CLI forces every HTTP request to reauthenticate

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 9.1pe
    • Fix Version/s: 9.0pe
    • Component/s: admin
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Sun

    • Issuezilla Id:
      81

      Description

      I've made the observation that when 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.

        Activity

        Hide
        km105526 added a comment -

        ...

        Show
        km105526 added a comment - ...
        Hide
        Tom Mueller added a comment -

        With the asadmin implementation in v3, there is typically only two requests to
        __asadmin for each each remote command, one to retrieve the help and do
        authentication, and one to actually submit the command. Thus, the Authorization:
        header is only sent typically twice per command. It is not clear that this is
        worth fixing.

        Marking as WONTFIX for the trunk.

        Show
        Tom Mueller added a comment - With the asadmin implementation in v3, there is typically only two requests to __asadmin for each each remote command, one to retrieve the help and do authentication, and one to actually submit the command. Thus, the Authorization: header is only sent typically twice per command. It is not clear that this is worth fixing. Marking as WONTFIX for the trunk.

          People

          • Assignee:
            Tom Mueller
            Reporter:
            jluehe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: