[security-dev] My OAuth2, Central Authz, and Distributed SSO work

Bill Burke bburke at redhat.com
Mon Jan 7 18:14:02 EST 2013


A week or two so before Christmas, I decided to refocus my OAuth work so 
that I could support *existing* JBoss web applications.  I'm about a 
week or two away from releasing something.  I just need to do some final 
minor feature work, test it a little bit more, and write some documentation.

*NOTE* All this works with existing JBoss web applications and security 
domain infrastructure.

FEATURE 1: TRADITIONAL OAUTH

You can take any existing web app and turn it into an OAuth2 provider. 
Currently, it must be using servlet FORM authentication and a jboss 
security domain.  ALl that is required additionally is adding a valve to 
jboss-web.xml, generating a realm key pain in a keystore, and putting a 
small json configuration file in your WAR's classpath.  Once you've done 
this, your existing web app can generate access tokens and 
*additionally* do bearer token auth.  Client apps, just need to follow 
the OAuth2 client protocol to obtain their access tokens.  And do 
client-side OAuth2 bearer token authentication to access the web app.

FEATURE 2: CENTRALIZED AUTHZ and Distributed SSO
* Turn any existing user/password/roles JBoss Security Domain into a 
remote, centralized, authentication and authorization server.  It is as 
simple as creating a small WAR that is FORM auth enabled, setting a 
particular jboss-web valve, and defining a simple json configuration file.
* Next, you can take any existing web app that uses FORM auth, and point 
it to this central server.  The plugin will do the correct browser 
redirects via OAuth2 protocol to the central server.  Identity and role 
mappings are transferred via the access token.
* This is authentication and authorization!  user auth and role mappings!
* It supports Distributed SSO.  Once you've logged into the central 
authentication server, you are logged into any application configured to 
accept authentication/authorization from the central server.
* It supports Distributed Log Out.  So, you can log out of all web 
applications
* Central server has a small admin interface that allows admins to 
logout a specific user (or all users) on all secured web applications. 
You can also set up bearer token policies like: don't accept tokens 
created before a certain date.
* Bearer tokens are generated for each browser login.
* Tokens are propagated and can be access in business logic via a 
request attribute, or in JAX-RS land, the @Context annotation.  You can 
then use this token to access other HTTP-based services on your network. 
  This allows your web application to talk securely with a network of 
web services.

This all works by defining a simple OAuth2 Bearer token format and using 
OAuth2 protocols to obtain and distribute these tokens.  My format is a 
small extension to JSON Web Token that has role-mapping information.  It 
is signed and verified using PKI.

I have plans to extend this to work with BASIC and CLIENT_CERT servlet 
authentication.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the security-dev mailing list