[undertow-dev] resteasy oauth undertow security requirements

[Darran Lofthouse]

On 29/04/13 15:40, 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.

Support for simultaneous auth protocols is already a part of the core of 
Undertow, the way this is achieved is by splitting up the stage 
performing the actual authentication of the request from the stage 
sending the challenges back to the client.

The difficulty with the valve approach was that a single valve would 
attempt authentication and immediately turn the request around meaning 
that additional valves would not have an opportunity to process the request.

The part we are really missing here is how this is configured within the 
WildFly subsystem.  I have already started one mail thread regarding 
this and am in the process of converting it to a docspace article for a 
second round of discussion.

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

Currently we integrate with JAAS to get Undertow into WildFly but this 
will be switched to PicketLink IDM.

However this is a second article I am putting together to clarify the 
situation regarding identity management.  The central authentication 
mechanisms by Undertow use a simplified IdentityManager interface that 
exposes just the methods required by these mechansisms - there is 
nothing to stop additional enhanced mechanisms from casting the 
IdentityManager to an extended version that does provide the 
capabilities needed by the mechanism.

Overall Undertow does not impose a requirement on even using the 
supplied IdentityManager - but I think really this is coming into the 
WildFly integration side of things.

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

Would you consider this core to the WildFly integration or do you want 
it to be an isolated 'drop in' mechanism?  It is sounding to me as 
though some of this would be better handled in the Undertow subsystem so 
that a couple of steps of required initialisation could be handled by 
just enabling one authentication mechanism.

> 4. Ability to create both principal and role mappings on the fly from an
> incoming request's bearer token.

The authentication mechanism architecture should allow for this.

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

That information should be accessible - at the moment the current 
implementation calls each method to attempt authentication until either 
one succeeds or the list of mechanisms is exhausted or in a rare case if 
one mechanism asks for the request to be bounced back to the calling 
client.  One thing that would need to be considered further would be if 
you wanted multiple mechanisms to each successfully authenticate a small 
part of the incoming request i.e. one check a cert used to establish the 
connection, the next verify a header in the incoming request etc...

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

Again this is really an AS integration issue - for mechanisms like FORM 
auth we do have some shared state that ends up being based on the HTTP 
session but the architecture doesn't mandate anything like that.

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

This sounds like a management capability that would be added to the 
WildFly integration.  Probably quite closely related to how #6 would be 
implemented.

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

Overall I think we need to check on point #5 but apart from that I think 
the bulk of your requirements would really fit within the WildFly 
integration.