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

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)