I’ve been heavily prototyping a security solution for Resteasy code named Resteasy Skeleton Key. The solution has the following requirements:

  • Central auth server
  • Works with browsers.
  • Works with machine clients (code).
  • Single sign-on solution for simple web apps
  • Granting permission to third-parties to access your resources.
  • Maps well to the role-based security model of Java EE
  • Optional client certificate support for increased security
  • Supports SOA.  Distributed applications that have complex interactions between different services.
  • Cloud-ready authentication server/identity server.
  • Integrate tightly and seemlessly to JBoss AS7

 

The Implementation

You can take a look at my code as it progresses.  Here’s generally what I’m doing:

  • OAuth Bearer Token authentication for machine-based clients.
  • Bearer token will be our own extension to Json Web Token (JWT).
  • Bearer tokens will be distributed using  Json Web Signatures (JWS)
  • Bearer tokens are issued for a user and also define role allowed for each distributed resource a user might interact with.
  • OAuth 2.0 and our bearer token implementation will be used to provide browser single-sign-on.
  • Oauth 2.0 and our bearer tokens will be used to provide browser authenticated third-party access grants.  (What OAuth2 was actually designed to do).
  • Client certificates can be  required at any authentication point depending on how you configure things.  Browser to IDP, Browser to resource, client to resource.
  • Implementing an Authentication Server to support all this.

As of 11/21/2012, I have implemented a JAX-RS friendly JWS implementation.  I have speced out and implemented our bearer tokens.  I’ve written a LoginModule for AS7 that can perform OAuth2 Bearer token authentication using our bearer token format and JWS.  Token format allows you to require SSL with client-certificates.  If you have this enabled, it also supports the idea of a surrogate, that is, one principal performat a request on behalf of a specific user.  Finally, I’ve started to scope out and implement an Identity/Authentication server to support all this stuff.  This isn’t complete yet.  I’ll document this stuff in more detail as I get closer to a beta release.

 

Relationship to Picketlink

The plan is to take this prototype and eventually work with the Picketlink project somehow later on.  Either just to funnel requirements, use parts of picketlink, share code, or even have them fully take it over.  The prototype will be fully functional, but will not have many persistence options or a management UI.  There will be a REST management interface though.  Whether or not a UI is introduced will be dependent on what the relationship with Picketlink ends up being.