[undertow-dev] resteasy oauth undertow security requirements

[Jason Greene]

On Apr 29, 2013, at 2:44 PM, Bill Burke <bburke at redhat.com> wrote:

> 
> 
> On 4/29/2013 12:04 PM, Darran Lofthouse wrote:
>>> 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.
>> 
> 
> So, should I wait before I port my oauth features?

Did anyone ever answer this? Is Picketlink IDM timing itself to be included in WildFly 8?

> 
>> 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.
>> 
> 
> I dont see why you couldn't add the ability to obtain role mappings. 
> Either you're leveraging Picketlink, and this information is available, 
> or, you're writing something specific for Undertow and the role mappings 
> would also be available.  Doesn't seem like too far a stretch for me 
> that if you support isUserInRole(), that you couldn't have Set<String> 
> getRoles().

On the surface I have to agree with you. Are we are aware of any IDM solution that doesn't have access to this information?

> 
>> 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.
>> 
> 
> I'm open to anything.  What would be the best approach?  My plan is to 
> keep this feature very specific to AS7 and Wildfly and not really 
> support it in other environments.  I just don't have the time to 
> maintain integration with other containers.

One of the requirements you added to the Undertow doc was that Undertow enables easy testing of web code. I'm guessing you need a solution that is part of Undertow and doesn't require launching a WildFly server?

> 
> 
>>> 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...
>> 
> 
> I'd like to be able to have a cert's signature verified by the web-app's 
> "domain" or web-app's Resteasy OAuth config.  For JBossWeb this is a 
> global setting.

So is this done today using a per-app valve?

> 
> 
> 
> 
>>> 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.
>> 
> 
> Well, this was pretty simple with a JBossWeb valve.  Because one valve 
> instance is instantiated per web app, I could just have a 
> concurrenthashmap store this information and spawn a very low priority 
> thread to reap unused entries.
> 
> 
>>> 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.
>> 
> 
> Its one of those additional URL endpoints I as talking about.  Just a 
> simple authenticated REST (HTTP) invocation.

Hmm it sounds like we just need an SPI, and that you could allow apps access to that SPI (verifying privileged actions etc)

> 
>>> 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.
>> 
> 
> Is the WIldfly integration something I'm going to have to wait on?  Or 
> is there something usable right now?

Darran can you give a brief status for everyone about security integration plans?

> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat