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

Bruno Oliveira bruno at abstractj.org
Mon Jan 21 12:11:15 EST 2013


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.
> 
> 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 (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.
> 
> 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
> _______________________________________________
> 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
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130121/86f880b8/attachment.html 


More information about the security-dev mailing list