<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <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>
  </body>
</html>