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

[Jason Porter]

Looks like they weren't on the USB drive either :( I emailed Les to see if
I could get a copy from him to review. I also noticed Stormpath (his
security consulting company) has a ruby interface:
https://github.com/stormpath I think this is something we should closely
look into for Torquebox, Immutant and Escalante.


On Sat, Feb 9, 2013 at 7:54 AM, Jason Porter <lightguard.jp at gmail.com>wrote:

> 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
> >
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130209/105263c0/attachment.html