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

[Jason Porter]

I'll send it over when I get home

Sent from my iPhone

On Feb 9, 2013, at 7:44, Pete Muir <pmuir at redhat.com> 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/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
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>