[undertow-dev] resteasy oauth undertow security requirements

[Stuart Douglas]

Opps, the link broke when I pushed it upstream:

https://github.com/undertow-io/undertow/commit/60de0ba9cd3d9487bf857df5c8be53b9855cff68

Stuart

Bill Burke wrote:
> FYI, that link doesn't work.
>
> On 5/15/2013 8:24 AM, Bill Burke wrote:
>> 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.
>>>>
>