[undertow-dev] resteasy oauth undertow security requirements

[Bill Burke]

BTW, here's a description and documentation of our SSO/OAuth plugin for AS7

http://docs.jboss.org/resteasy/docs/3.0-beta-4/userguide/html/oauth2.html


On 4/29/2013 10:40 AM, Bill Burke wrote:
> Hey all,
>
> Is there a web-site for Undertow?  Any documentation or examples?
>
> I'm hoping to start migrating Resteasy's OAuth work so that it works
> with Undertow.  I don't know whether or not it will require undertow
> security API changes or not.  I'll post some initial
> requirements/how-we-do-it-now stuff below.
>
> 1. Support for multiple simultaneous auth protocols for one web-app. Any
> servlet auth + oauth + bearer-token.
> 2. Ability to introspect principal and role mapping from underlying
> "domain".  We create a smart token from this information.  With
> JBossWeb, we hacked this information from the Principal passed back from
> the security layer.
> 3. Ability to add additional action URLs to the web-app without
> additional user configuration.  With JBossWeb, we handled all these URLs
> within a valve.
> 4. Ability to create both principal and role mappings on the fly from an
> incoming request's bearer token.
> 5. Ability to obtain any client certificates so that they can be
> verified.  Verification only.  For this I want to be able to verify the
> client that is acting on behalf of a user.  So the calling client's
> certificates may not be the same identity of the actual user.
> 6. Ability to store state in-between requests.  This isn't a session as
> it will be two different clients that need to share data.  in OAuth,
> there's the User Agent that establishes an access code for the web-app.
>    The web-app makes a separate HTTP request to verify the access code
> and turn it into a token.
> 7. Ability to log out any requested user.  Our current implementation
> has an admin interface that can log out a user on *every* app they are
> logged into.
>
> That's all I can think of now.  So, Undertow needs to provide these
> capabilities within their security API, *OR*, it requires a Valve
> architecture that can override any current built-in auth infrastructure,
> but at the same time, have access to the "domain" and be able to
> authenticate and introspect principal and role mappings.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com