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

I'll send it over when I get home Sent from my iPhone On Feb 9, 2013, at 7:44, Pete Muir <pmuir(a)redhat.com&gt; wrote: > RWX have removed access to this presentation. Does anyone have it cached? > > On 3 Dec 2012, at 13:07, Jason Porter wrote: > >> 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/in... >> >> >> On Mon, Dec 3, 2012 at 2:37 AM, Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev >> _______________________________________________ >> security-dev mailing list >> security-dev(a)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 >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev >