<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Ok I've thought about this now ;)  I
      think that the only use cases it is relevant for is those where
      the credentials are actually stored by the application.  In the
      SSO, OAuth etc use cases the authentication path doesn't touch
      identity management beyond the possible synchronization of User
      attributes.  For standard IDM based authentication (anything where
      the application manages credentials itself) I think it really is a
      responsibility of the IdentityStore.  Take LDAP for example -
      authentication is performed by binding to the directory (see the
      validatePassword() method in [1]), which requires a tight coupling
      with the IdentityStore configuration.  This requirement is also
      shared by JPAIdentityStore, which may be configured to store user
      credentials in the same table as the User record itself.<br>
      <br>
      I think that partitioning is a valid point (i.e. being able to mix
      and match identities as you suggested) however we can do that by
      providing something like the Features metadata feature from
      PicketLink 1.x (see [2]) which allows us to configure multiple
      IdentityStore implementations in a single application, each
      providing a certain subset of features.<br>
      <br>
      [1]
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <a
href="https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/ldap/internal/LDAPIdentityStore.java">https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/ldap/internal/LDAPIdentityStore.java</a><br>
      [2]
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <a
href="https://github.com/picketlink/picketlink-idm/blob/1.1.0/picketlink-idm-spi/src/main/java/org/picketlink/idm/spi/store/FeaturesMetaData.java">https://github.com/picketlink/picketlink-idm/blob/1.1.0/picketlink-idm-spi/src/main/java/org/picketlink/idm/spi/store/FeaturesMetaData.java</a><br>
      <br>
      Shane<br>
      <br>
      On 18/10/12 12:07, Jason Porter wrote:<br>
    </div>
    <blockquote
      cite="mid:82E11878-04AF-404D-A8CC-DA90B1B9E710@gmail.com"
      type="cite">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div>I was thinking it would be a composition idea. Probably
        require some config, but may be worth it. <br>
        <br>
        Sent from my iPhone</div>
      <div><br>
        On Oct 17, 2012, at 19:35, Shane Bryzak &lt;<a
          moz-do-not-send="true" href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>&gt;
        wrote:<br>
        <br>
      </div>
      <blockquote type="cite">
        <div>
          <meta content="text/html; charset=UTF-8"
            http-equiv="Content-Type">
          <div class="moz-cite-prefix">That's an interesting idea, I
            don't know if it would have limitations (my first reaction
            is to think that we require tight coupling with
            IdentityStore) however it certainly has some merit.  Let me
            think about it for a bit.<br>
            <br>
            <br>
            On 18/10/12 11:21, Jason Porter wrote:<br>
          </div>
          <blockquote
            cite="mid:A99EEDEA-533B-454C-9834-2BD4408D05FC@gmail.com"
            type="cite">
            <meta http-equiv="content-type" content="text/html;
              charset=UTF-8">
            <div>This sounds good, but I'm wondering if we should have
              this extracted completely from the IdentityStore and have
              it be its own interface. The main reason being it would
              make it easier to mix and match identities (users, rolls
              and groups) and authentication.</div>
            <div><br>
            </div>
            <div>You could have an sso solution, multi-factor, oauth,
              etc but still keep the rest of the data in your RDBMS,
              ldap, jcr etc. Yes I understand they'd simply have to
              create their own impl and many probably will, but if we
              ship with reasonable implementations they can more easily
              mix and match and keep things DRY.<br>
              <br>
              Sent from my iPhone</div>
            <div><br>
              On Oct 17, 2012, at 16:17, Shane Bryzak &lt;<a
                moz-do-not-send="true" href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>&gt;

              wrote:<br>
              <br>
            </div>
            <blockquote type="cite">
              <div>
                <meta http-equiv="content-type" content="text/html;
                  charset=UTF-8">
                Hi guys,<br>
                <br>
                I'd like to simplify the Identity Management API a bit
                where credentials are concerned.  At the moment we have
                the following methods defined by the IdentityManager
                interface:<br>
                <br>
                    // Password Management<br>
                    boolean validatePassword(User user, String
                password);<br>
                <br>
                    void updatePassword(User user, String password);<br>
                <br>
                    void setPasswordEncoder(PasswordEncoder encoder);<br>
                <br>
                    // Certificate Management<br>
                    boolean validateCertificate(User user,
                X509Certificate certificate);<br>
                <br>
                    boolean updateCertificate(User user, X509Certificate
                certificate);<br>
                <br>
                Furthermore, in IdentityStore we have these methods
                which are essentially identical:<br>
                <br>
                    boolean validatePassword(User user, String
                password);<br>
                <br>
                    void updatePassword(User user, String password);<br>
                <br>
                    // Certificate Management<br>
                    boolean validateCertificate(User user,
                X509Certificate certificate);<br>
                <br>
                    boolean updateCertificate(User user, X509Certificate
                certificate);<br>
                <br>
                <br>
                What I'd like to do is make this a little more abstract
                (and more future proof) by replacing these methods (in
                both interfaces) with the following two methods:<br>
                <br>
                    boolean validateCredential(User user, Credential
                credential);<br>
                <br>
                    void updateCredential(User user, Credential
                credential);<br>
                <br>
                Once the method invocation hits the IdentityStore
                implementation, we have a choice as to what we want to
                do here.  I think the best option is to go with a
                credential encoding API based on the work that Pedro has
                already done (see [1] and [2]).  My only suggestion
                would be to:<br>
                <br>
                a) make it a little more generic (we should use a
                factory object or something to provide the IdentityStore
                implementation with the correct encoder based on the
                type of credential) <br>
                b) provide the encoder implementation with an invocation
                context containing a reference back to the calling
                IdentityStore to allow access to its internal methods
                and/or other state, and<br>
                c) provide pluggable access to the encoding process, to
                allow the developer to provide custom behaviour for the
                encoding.<br>
                <br>
                Does anyone have any suggestions or thoughts on this?<br>
                <br>
                Shane<br>
                <br>
                <br>
                [1]
                <meta http-equiv="content-type" content="text/html;
                  charset=UTF-8">
                <a moz-do-not-send="true"
href="https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/password/PasswordEncoder.java">https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/password/PasswordEncoder.java</a><br>
                [2]
                <meta http-equiv="content-type" content="text/html;
                  charset=UTF-8">
                <a moz-do-not-send="true"
href="https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/password/internal/SHASaltedPasswordEncoder.java">https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/password/internal/SHASaltedPasswordEncoder.java</a>
              </div>
            </blockquote>
            <blockquote type="cite">
              <div><span>_______________________________________________</span><br>
                <span>security-dev mailing list</span><br>
                <span><a moz-do-not-send="true"
                    href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a></span><br>
                <span><a moz-do-not-send="true"
                    href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a></span><br>
              </div>
            </blockquote>
          </blockquote>
          <br>
          <br>
        </div>
      </blockquote>
    </blockquote>
    <br>
    <br>
  </body>
</html>