[security-dev] PicketLink Capabilities - Authentication
bburke at redhat.com
Thu Nov 29 10:35:42 EST 2012
On 11/29/2012 6:13 AM, Darran Lofthouse wrote:
> 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.
> 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.
Its pretty simple to write. I'll be writing LoginModule to support this
very soon (HTTPS only). You just want cert validation right? Do you
need access to the cert? Or can you just get the principal String name?
> 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.
At least for HTTPS, I've found that JBossWeb does the validation of the
client-cert if you provide it a truststore.
> 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'm doing a bunch of work with OAuth and bearer tokens with the ability
to throw in client-certs as an extra auth mechanism.
I should have a prototype up by christmas.
> 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.
Yes, I have this problem as well. I want a bearer token that can travel
and be forwarded to multiple endpoints, be verified through PKI, have
all the role grants within the token, and have the identity of the
caller verfied through client-cert validation. This allows services to
be totally stateless with regards to security metadata/identity and to
receive permissions per-request. All they need is a truststore.
Granted this is HTTP only, but I've prototyped it already:
JBoss, a division of Red Hat
More information about the security-dev