[undertow-dev] resteasy oauth undertow security requirements
Jason Greene
jason.greene at redhat.com
Mon May 13 10:14:14 EDT 2013
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
More information about the undertow-dev
mailing list