[security-dev] PicketLink 3 - IDM API - Credential Management

[Jason Porter]

Here's a PDF [1] of a session I attended at RWX this past week. Start
looking at page 25 onward for some ideas on how we can better store
passwords with something other than just a salted hash, it may also give us
a good advantage with other competitors. If you can't get to the PDF, let
me know and I'll attach it.

[1]
http://therichwebexperience.com/s/slides/current/speaker/Les_Hazlewood/intro_to_application_security/Intro_to_Application_Security.pdf


On Mon, Dec 3, 2012 at 2:37 AM, Darran Lofthouse <darran.lofthouse at jboss.com
> wrote:

> On 12/03/2012 09:23 AM, Darran Lofthouse wrote:
> > On 12/02/2012 11:09 PM, Shane Bryzak wrote:
> >> On 12/01/2012 09:55 PM, Darran Lofthouse wrote:
> >>> * Multiple Credentials *
> >>>
> >>> The validateCredential method potentially allows many different types
> of
> >>> Credential to be used - however the updateCredential method seems to
> >>> apply a 1:1 mapping of User and Credential.
> >>>
> >>> I can see situations where a user would have multiple Credentials, an
> >>> immediate example being both a Password and a X509Certificate.
> >>
> >> This is an implementation detail - all IdentityStore implementations
> >> should support the storing of multiple credential types.  Out of the box
> >> we support PasswordCredential, DigestCredential and
> >> X509CertificateCredential and two separate calls to updateCredential()
> >> with different credential types should persist both credentials.
> >
> > I would suggest if reviewing the Credential APIs one thing that we would
> > need to be sure of it that we can operate on the individual Credentials
> > - we may need to be choosing which one to update or remove.
> >
> > Also for Certificates we may want the ability to have a new Certificate
> > set before an old one expires possibly with or without an overlap.
>
> Also if looking at Certificates as I mentioned on another thread if the
> APIs from the IDM allow us to wrap it with an X509TrustManager
> implementation that would potentially provide us with the capability to
> tie in the SSL negotiation as connections are established with the
> identity store.
>
> In current AS releases this can be a bit disjointed getting the two tied
> together.
>
> > _______________________________________________
> > security-dev mailing list
> > security-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/security-dev
> >
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>



-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121203/4d1ad2c9/attachment.html