[undertow-dev] resteasy oauth undertow security requirements

[Bill Burke]

On 5/13/2013 10:14 AM, Jason Greene wrote:
>
> 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?
>

I've been talking to Picketlink a bit about our requirements.

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

IDK.  IMO, just throw an unsupported exception if the underlying IDM 
solution doesn't support it.

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

I'm limited what I can do with my implementation right now because there 
is no way to store additional metadata beyond user, password, and role 
mappings.  I can port what I have as-is to work under embedded 
mode/testing mode, but a more rich IDM API would be needed for advanced 
features.

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

AS7 + JBossWeb can't do per-app client-cert verification.  YOu have to 
provide a truststore at the global configuration of the ssl connector. 
It would be nice to be able to set the two-way SSL config at the global 
level to be "WANT" and at the app level to "NEED" it.


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

Yeah, open on how to implement this going forward, but since Wildfly 
wouldn't be SSO aware, it would have to be driven by the security layer.

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