Shiro
  1. Shiro
  2. SHIRO-20

Support HTTP Digest Authentication

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Just as we support HTTP Basic Authentication via the BasicHttpAuthenticationFilter, we should also support HTTP Digest Authentication out of the box as well:

      http://en.wikipedia.org/wiki/Digest_access_authentication

        Activity

        Hide
        Edwin Navarrete added a comment -

        Simplicity is perhaps one of the reasons to prefer Shiro over Spring, which is very handy specially to quickly implement SSO, but not supporting the second most common authentication mechanism over http, simply marres all the marvelous features it offers. In my case I intended to use it in an Xforms-standard compliant application to connect OpenRosa devices (which I discovered not longer use basic authentication). This feature should be top priority, and perhaps connecting with Membased is very desirable.

        Show
        Edwin Navarrete added a comment - Simplicity is perhaps one of the reasons to prefer Shiro over Spring, which is very handy specially to quickly implement SSO, but not supporting the second most common authentication mechanism over http, simply marres all the marvelous features it offers. In my case I intended to use it in an Xforms-standard compliant application to connect OpenRosa devices (which I discovered not longer use basic authentication). This feature should be top priority, and perhaps connecting with Membased is very desirable.
        Hide
        Sebastian Audet added a comment -

        Considering the backend - the solution to this issue may be a bit more involved.

        For systems such as LDAP where the password is unavailable and the hash cannot be safely re-hashed if it using an outdated algorithm, the only solution is to either update the LDAP system and forward all requests, or to intercept the request in plain-text once, store the securely hashed value in the LDAP system as a separate field, and then retrieve the LDAP value on subsequent tries.

        This approach can be generalized to support other systems supporting extra fields such as AD or Stormpath. It also externalizes the risk management to the external LDAP system, whose passwords and information can be updated or retrieved at will if LDAP access is achieved.

        Show
        Sebastian Audet added a comment - Considering the backend - the solution to this issue may be a bit more involved. For systems such as LDAP where the password is unavailable and the hash cannot be safely re-hashed if it using an outdated algorithm, the only solution is to either update the LDAP system and forward all requests, or to intercept the request in plain-text once, store the securely hashed value in the LDAP system as a separate field, and then retrieve the LDAP value on subsequent tries. This approach can be generalized to support other systems supporting extra fields such as AD or Stormpath. It also externalizes the risk management to the external LDAP system, whose passwords and information can be updated or retrieved at will if LDAP access is achieved.
        Hide
        Sebastian Audet added a comment -

        The primary issue with getting this done is finding the password. The reference implementation in Spring Security simply looks up the password for a given username, with an option for it being already hashed or not. Since it appears Shiro is always assuming that there is a password for any given username being sent, either the DigestFilter must be able to lookup the user's password, or the filter must be able to forward the request to an appropriate Realm.

        Show
        Sebastian Audet added a comment - The primary issue with getting this done is finding the password. The reference implementation in Spring Security simply looks up the password for a given username, with an option for it being already hashed or not. Since it appears Shiro is always assuming that there is a password for any given username being sent, either the DigestFilter must be able to lookup the user's password, or the filter must be able to forward the request to an appropriate Realm.

          People

          • Assignee:
            Unassigned
            Reporter:
            Les Hazlewood
          • Votes:
            9 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:

              Development