I'll be doing a release next week. I still have to write documentation,

but the features and examples are complete.

https://github.com/resteasy/Resteasy/tree/master/jaxrs/examples/oauth2-as7-example

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.

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@lists.jboss.org <mailto:security-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/security-dev

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com