[security-dev] PicketLink Capabilities - Authentication

Pedro Igor Silva psilva at redhat.com
Thu Nov 29 11:03:55 EST 2012



----- Original Message -----
> From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> To: security-dev at lists.jboss.org
> Sent: Thursday, November 29, 2012 9:13:04 AM
> Subject: [security-dev] PicketLink Capabilities - Authentication
> 
> Hello all,
> 
> Just looking at how I could make use of PicketLink withing AS7 and
> have
> a couple of questions.
> 
> For Digest based authentication mechanisms I see there is some
> initial
> support but I have a couple more requirements I will raise
> separately.

 That would be nice.

> 
> The next area I am looking into is SSL and Client Cert style
> authentication - a couple of things I am interested in here is - is
> there a capability to take a certificate, validate it and then return
> the identity of the user from that certificate?  i.e. I am not
> looking
> to load the user first and then validate the certificate.

  Today we have no such capability. We load the user using the information from the certificate (eg.: the principal) and then validate the cert. But we can write something considering what you want. Maybe using the picketbox-keystore project (see bellow).

  You can also configure the mechanism to trust the cert if the principal is stored in IDM (no cert checking). The use case for that is when you're using HTTPs and the server already validated the certificate.

> 
> Secondly in this area could it be conceivable to implement a
> X509TrustStore that is backed by PicketLink?  If we could obtain all
> validate certificates or the certificate of a CA we could create
> somethign in advance but I am interested in if we could have
> something
> more dynamic.

  I think picketlink-keystore can help with that. Maybe Anil can give more details about this project. It uses a database-based Java Keystore.

> 
> Following on from this I have one more case that I am not sure if it
> would fit within an IDM or if we would handle it outside first and
> only
> access the IDM once we have verified the user and that is
> GSSAPI/SPNEGO
> style authentication.  In this case we receive one or more tokens
> from a
> user and send one or more challenges back to the user - at the end of
> this authentication process we know the identity of the user.

  I started to write a GSSAPI/Kerberos (reusing somethings from JBoss Nego) authentication mechanism. Basically, it expects a token to validate it against a KDC. The IDM kicks in when the user is authenticated and we need to get his information from the store such as roles, groups, attributes, etc.

> 
> Also interested in knowing if anyone else has other authentication
> scenarios identified where all we may have is the 'Credential' and
> the
> user is not identified until after this has been verified.
> 
> Regards,
> Darran Lofthouse.
> 
> 
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
> 


More information about the security-dev mailing list