[undertow-dev] resteasy oauth undertow security requirements

Bill Burke bburke at redhat.com
Wed May 15 08:24:59 EDT 2013


You should bring this to Wildfly in general.  Being able to define 
features per deployment would be cool.

On 5/14/2013 5:51 PM, Stuart Douglas wrote:
> So I had a bit of a think about the factory concept, and realised that
> we can actually just use something a lot more generic:
>
> https://github.com/stuartwdouglas/undertow/compare/undertow-io:master...master#L0R22
>
>
> Basically we just provide an extension interface that allows you to
> modify the deployment before it is deployed. This basically gives you
> access to everything in the deployment including:
>
> - Authentication mechanisms
> - Registering additional handlers
> - All the servlet stuff (servlets/filters etc), including adding a
> pre-configured instance instead of just specifying the class name
>
> I'm thinking this should be the standard way of configuring Undertow
> specific functionality.
>
> Stuart
>
> Bill Burke wrote:
>>
>>
>> On 5/14/2013 12:22 AM, Stuart Douglas wrote:
>>>
>>>
>>> Bill Burke wrote:
>>>>
>>>> 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.
>>>
>>> Is this just the ability to store arbitrary attributes under a user
>>> account, and the getRoles() method? If this is all you require I think
>>> we can just add them into the Undertow IDM interface.
>>>
>>
>> That works.
>>
>>>>>> 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.
>>>
>>> You could do the same thing in Undertow, but it just depends if you
>>> would ever want to examine/manage this state in your admin console, in
>>> which case it would probably need something more.
>>>
>>
>> I think your Factory concept (let's call it a UndertowFeature?) would
>> work well here. An Undertow only Feature would just set up the oath
>> stuff only. A Wildfly one, would register (or look up) the appropriate
>> caches with the management layer.
>>

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


More information about the undertow-dev mailing list