8:54 a.m.
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> 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>
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