[wildfly-dev] PicketLink pulling in JPA (Was: Changes to the PicketLink Module)

[Bill Burke]

On 8/5/2013 10:32 PM, Scott Marlow wrote:
> On 08/05/2013 09:43 PM, Fernando Ribeiro wrote:
>>
>> On Mon, Aug 5, 2013 at 6:53 PM, Jason Greene <jason.greene at redhat.com
>> <mailto:jason.greene at redhat.com>> wrote:
>>
>>      If we look at this use case, its simply persisting and loading a
>>      token. To me it's overkill to pull in JPA for that. I could see some
>>      use cases with very complex relational designs that maybe motivates
>>      you, but even then it really should be balanced with what the
>>      overall architecture is going to look like.
>>
>>
>> JPA may be so at this point, but not the database, which is a must-have
>> in clustered PicketLink deployments.
>
> What does a clustered PicketLink deployment look like?  Does PL rely on
> the platform clustering services to notify nodes of changes to tokens in
> the database (e.g. update/delete/add)?
>
>   From [3] that you mentioned at the start of this thread, it sounds like
> there is no clustering but instead some type of database polling to
> check if a token is revoked.  When does the revoke check occur?  Do you
> have any scalability issues here?
>
> Do revoked Ids get removed from the database?
>

This is another reason I don't like hub/spoke architecture.

For Resteasy OAuth implementation (and the new SSO project I'm working 
on), we digitally sign the token.  The token contains all the 
information the app needs to authenticate and authorize.  The signature 
of the token is validated against the Realm's public key.  This way, 
there's no need to ping a token service every request and no need to 
keep tokens hanging around and thus no need to cluster the admin server 
beyond load balancing.

If you add two-way ssl (client certs), it becomes even more secure.  You 
can verify the certificate chain of the cert to validate the caller is 
somebody that is trusted.  Or even match the identity in the client cert 
with the token.  Identity and permissions are transferred in a secure 
yet highly scalable manner.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com