Re: [undertow-dev] resteasy oauth undertow security requirements

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