[undertow-dev] resteasy oauth undertow security requirements

[Stuart Douglas]

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