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

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