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

Bill Burke bburke at redhat.com
Mon Jan 21 12:16:34 EST 2013

I'll be doing a release next week.  I still have to write documentation, 
but the features and examples are complete.


On 1/21/2013 12:11 PM, Bruno Oliveira wrote:
> Hi Bill, did you had the chance to move forward?
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
> On Monday, January 7, 2013 at 9:14 PM, Bill Burke wrote:
>> 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.
>> 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 <http://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.
>> * 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
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org <mailto:security-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/security-dev

Bill Burke
JBoss, a division of Red Hat

More information about the security-dev mailing list