[undertow-dev] resteasy oauth undertow security requirements

[Bill Burke]

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

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