Hey all, Is there a web-site for Undertow? Any documentation or examples? I'm hoping to start migrating Resteasy's OAuth work so that it works with Undertow. I don't know whether or not it will require undertow security API changes or not. I'll post some initial requirements/how-we-do-it-now stuff below. 1. Support for multiple simultaneous auth protocols for one web-app. Any servlet auth + oauth + bearer-token. 2. Ability to introspect principal and role mapping from underlying "domain". We create a smart token from this information. With JBossWeb, we hacked this information from the Principal passed back from the security layer. 3. Ability to add additional action URLs to the web-app without additional user configuration. With JBossWeb, we handled all these URLs within a valve. 4. Ability to create both principal and role mappings on the fly from an incoming request's bearer token. 5. Ability to obtain any client certificates so that they can be verified. Verification only. For this I want to be able to verify the client that is acting on behalf of a user. So the calling client's certificates may not be the same identity of the actual user. 6. Ability to store state in-between requests. This isn't a session as it will be two different clients that need to share data. in OAuth, there's the User Agent that establishes an access code for the web-app. The web-app makes a separate HTTP request to verify the access code and turn it into a token. 7. Ability to log out any requested user. Our current implementation has an admin interface that can log out a user on *every* app they are logged into. That's all I can think of now. So, Undertow needs to provide these capabilities within their security API, *OR*, it requires a Valve architecture that can override any current built-in auth infrastructure, but at the same time, have access to the "domain" and be able to authenticate and introspect principal and role mappings.

> 2. Ability to introspect principal and role mapping from underlying > "domain". We create a smart token from this information. With > JBossWeb, we hacked this information from the Principal passed back from > the security layer. Currently we integrate with JAAS to get Undertow into WildFly but this will be switched to PicketLink IDM.

However this is a second article I am putting together to clarify the situation regarding identity management. The central authentication mechanisms by Undertow use a simplified IdentityManager interface that exposes just the methods required by these mechansisms - there is nothing to stop additional enhanced mechanisms from casting the IdentityManager to an extended version that does provide the capabilities needed by the mechanism.

Overall Undertow does not impose a requirement on even using the supplied IdentityManager - but I think really this is coming into the WildFly integration side of things. > 3. Ability to add additional action URLs to the web-app without > additional user configuration. With JBossWeb, we handled all these URLs > within a valve. Would you consider this core to the WildFly integration or do you want it to be an isolated 'drop in' mechanism? It is sounding to me as though some of this would be better handled in the Undertow subsystem so that a couple of steps of required initialisation could be handled by just enabling one authentication mechanism.

> 4. Ability to create both principal and role mappings on the fly from an > incoming request's bearer token. The authentication mechanism architecture should allow for this. > 5. Ability to obtain any client certificates so that they can be > verified. Verification only. For this I want to be able to verify the > client that is acting on behalf of a user. So the calling client's > certificates may not be the same identity of the actual user. That information should be accessible - at the moment the current implementation calls each method to attempt authentication until either one succeeds or the list of mechanisms is exhausted or in a rare case if one mechanism asks for the request to be bounced back to the calling client. One thing that would need to be considered further would be if you wanted multiple mechanisms to each successfully authenticate a small part of the incoming request i.e. one check a cert used to establish the connection, the next verify a header in the incoming request etc...

> 6. Ability to store state in-between requests. This isn't a session as > it will be two different clients that need to share data. in OAuth, > there's the User Agent that establishes an access code for the web-app. > The web-app makes a separate HTTP request to verify the access code > and turn it into a token. Again this is really an AS integration issue - for mechanisms like FORM auth we do have some shared state that ends up being based on the HTTP session but the architecture doesn't mandate anything like that.

> 7. Ability to log out any requested user. Our current implementation > has an admin interface that can log out a user on *every* app they are > logged into. This sounds like a management capability that would be added to the WildFly integration. Probably quite closely related to how #6 would be implemented.

> That's all I can think of now. So, Undertow needs to provide these > capabilities within their security API, *OR*, it requires a Valve > architecture that can override any current built-in auth infrastructure, > but at the same time, have access to the "domain" and be able to > authenticate and introspect principal and role mappings. Overall I think we need to check on point #5 but apart from that I think the bulk of your requirements would really fit within the WildFly integration.

> > Is the WIldfly integration something I'm going to have to wait on? Or > is there something usable right now? Darran can you give a brief status for everyone about security integration plans?

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.

>> >>>> 4. Ability to create both principal and role mappings on the fly from an >>>> incoming request's bearer token. >>> The authentication mechanism architecture should allow for this. >>> >>>> 5. Ability to obtain any client certificates so that they can be >>>> verified. Verification only. For this I want to be able to verify the >>>> client that is acting on behalf of a user. So the calling client's >>>> certificates may not be the same identity of the actual user. >>> That information should be accessible - at the moment the current >>> implementation calls each method to attempt authentication until either >>> one succeeds or the list of mechanisms is exhausted or in a rare case if >>> one mechanism asks for the request to be bounced back to the calling >>> client. One thing that would need to be considered further would be if >>> you wanted multiple mechanisms to each successfully authenticate a small >>> part of the incoming request i.e. one check a cert used to establish the >>> connection, the next verify a header in the incoming request etc... >>>

>> I'd like to be able to have a cert's signature verified by the web-app's >> "domain" or web-app's Resteasy OAuth config. For JBossWeb this is a >> global setting. > So is this done today using a per-app valve? > AS7 + JBossWeb can't do per-app client-cert verification. YOu have to provide a truststore at the global configuration of the ssl connector. It would be nice to be able to set the two-way SSL config at the global level to be "WANT" and at the app level to "NEED" it. >> >> >> >>>> 6. Ability to store state in-between requests. This isn't a session as >>>> it will be two different clients that need to share data. in OAuth, >>>> there's the User Agent that establishes an access code for the web-app. >>>> The web-app makes a separate HTTP request to verify the access code >>>> and turn it into a token. >>> Again this is really an AS integration issue - for mechanisms like FORM >>> auth we do have some shared state that ends up being based on the HTTP >>> session but the architecture doesn't mandate anything like that. >>> >> 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.

>> >> >>>> 7. Ability to log out any requested user. Our current implementation >>>> has an admin interface that can log out a user on *every* app they are >>>> logged into. >>> This sounds like a management capability that would be added to the >>> WildFly integration. Probably quite closely related to how #6 would be >>> implemented. >>> >> Its one of those additional URL endpoints I as talking about. Just a >> simple authenticated REST (HTTP) invocation. > Hmm it sounds like we just need an SPI, and that you could allow apps access to that SPI (verifying privileged actions etc) > Yeah, open on how to implement this going forward, but since Wildfly wouldn't be SSO aware, it would have to be driven by the security layer.

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.

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

On Apr 29, 2013, at 2:44 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > > On 4/29/2013 12:04 PM, Darran Lofthouse wrote: >>> 2. Ability to introspect principal and role mapping from underlying >>> "domain". We create a smart token from this information. With >>> JBossWeb, we hacked this information from the Principal passed back from >>> the security layer. >> Currently we integrate with JAAS to get Undertow into WildFly but this >> will be switched to PicketLink IDM. >> > So, should I wait before I port my oauth features? Did anyone ever answer this? Is Picketlink IDM timing itself to be included in WildFly 8?

>> However this is a second article I am putting together to clarify the >> situation regarding identity management. The central authentication >> mechanisms by Undertow use a simplified IdentityManager interface that >> exposes just the methods required by these mechansisms - there is >> nothing to stop additional enhanced mechanisms from casting the >> IdentityManager to an extended version that does provide the >> capabilities needed by the mechanism. >> > I dont see why you couldn't add the ability to obtain role mappings. > Either you're leveraging Picketlink, and this information is available, > or, you're writing something specific for Undertow and the role mappings > would also be available. Doesn't seem like too far a stretch for me > that if you support isUserInRole(), that you couldn't have Set<String> > getRoles(). On the surface I have to agree with you. Are we are aware of any IDM solution that doesn't have access to this information?

>> Overall Undertow does not impose a requirement on even using the >> supplied IdentityManager - but I think really this is coming into the >> WildFly integration side of things. >> >>> 3. Ability to add additional action URLs to the web-app without >>> additional user configuration. With JBossWeb, we handled all these URLs >>> within a valve. >> Would you consider this core to the WildFly integration or do you want >> it to be an isolated 'drop in' mechanism? It is sounding to me as >> though some of this would be better handled in the Undertow subsystem so >> that a couple of steps of required initialisation could be handled by >> just enabling one authentication mechanism. >> > I'm open to anything. What would be the best approach? My plan is to > keep this feature very specific to AS7 and Wildfly and not really > support it in other environments. I just don't have the time to > maintain integration with other containers. One of the requirements you added to the Undertow doc was that Undertow enables easy testing of web code. I'm guessing you need a solution that is part of Undertow and doesn't require launching a WildFly server?

> >>> 4. Ability to create both principal and role mappings on the fly from an >>> incoming request's bearer token. >> The authentication mechanism architecture should allow for this. >> >>> 5. Ability to obtain any client certificates so that they can be >>> verified. Verification only. For this I want to be able to verify the >>> client that is acting on behalf of a user. So the calling client's >>> certificates may not be the same identity of the actual user. >> That information should be accessible - at the moment the current >> implementation calls each method to attempt authentication until either >> one succeeds or the list of mechanisms is exhausted or in a rare case if >> one mechanism asks for the request to be bounced back to the calling >> client. One thing that would need to be considered further would be if >> you wanted multiple mechanisms to each successfully authenticate a small >> part of the incoming request i.e. one check a cert used to establish the >> connection, the next verify a header in the incoming request etc... >> > I'd like to be able to have a cert's signature verified by the web-app's > "domain" or web-app's Resteasy OAuth config. For JBossWeb this is a > global setting. So is this done today using a per-app valve? > > > >>> 6. Ability to store state in-between requests. This isn't a session as >>> it will be two different clients that need to share data. in OAuth, >>> there's the User Agent that establishes an access code for the web-app. >>> The web-app makes a separate HTTP request to verify the access code >>> and turn it into a token. >> Again this is really an AS integration issue - for mechanisms like FORM >> auth we do have some shared state that ends up being based on the HTTP >> session but the architecture doesn't mandate anything like that. >> > 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. > > >>> 7. Ability to log out any requested user. Our current implementation >>> has an admin interface that can log out a user on *every* app they are >>> logged into. >> This sounds like a management capability that would be added to the >> WildFly integration. Probably quite closely related to how #6 would be >> implemented. >> > Its one of those additional URL endpoints I as talking about. Just a > simple authenticated REST (HTTP) invocation. Hmm it sounds like we just need an SPI, and that you could allow apps access to that SPI (verifying privileged actions etc) >>> That's all I can think of now. So, Undertow needs to provide these >>> capabilities within their security API, *OR*, it requires a Valve >>> architecture that can override any current built-in auth infrastructure, >>> but at the same time, have access to the "domain" and be able to >>> authenticate and introspect principal and role mappings. >> Overall I think we need to check on point #5 but apart from that I think >> the bulk of your requirements would really fit within the WildFly >> integration. >> > Is the WIldfly integration something I'm going to have to wait on? Or > is there something usable right now? Darran can you give a brief status for everyone about security integration plans?