Re: [undertow-dev] figuring out how to integration resteasy oauth

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stuart Douglas" <sdouglas(a)redhat.com&gt; Cc: undertow-dev(a)lists.jboss.org Sent: Thursday, 15 August, 2013 2:11:12 PM Subject: Re: [undertow-dev] figuring out how to integration resteasy oauth On 8/15/2013 5:37 AM, Stuart Douglas wrote: > > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: undertow-dev(a)lists.jboss.org >> Sent: Thursday, 15 August, 2013 2:24:49 AM >> Subject: Re: [undertow-dev] figuring out how to integration resteasy oauth >> >> I have an added problem here of having to provide configuration for >> this. (i.e. keys). >> >> On 8/14/2013 8:23 PM, Bill Burke wrote: >>> I'm looking at Undertow handlers and Auth mechanisms and trying to >>> figure out how to port resteasy oauth. I need to be able to do the >>> following >>> >>> 1. check a cookie to see if user is already logged in. >>> 2. If not redirect to auth server >>> 3. get a redirect back from auth server >>> 4. make an HTTP request to server based on information from the request >>> 5. Obtain a token from this request >>> 6. Parse and validate the token to obtain user identity and role mappings >>> 7. Propagate the identity and role mappings so other layers can do their >>> thing (like role checks) >>> >>> I can do most of this within a AuthenticationMechanism. sendChallenge() >>> would be used to send the redirect to the auth server. I think a custom >>> IdentityManager is needed. This would accept a custom Credential. The >>> Credential would have the identity and role mappings within it and the >>> IdentityManager would allocate an Account based on this information. > > I don't think you actually need a custom identity manager, your mechanism > can just create a new Account > and pass it to the SecurityContext.authenticationComplete() method. > CachedAuthenticatedSessionMechanism does a: Account account = securityContext.getIdentityManager().verify(authSession.getAccount()); So, I couldn't have a null IdentityManager, I'd at least have to have a dummy IdentityManager. Plus, the thread local binding of the subject/principal/role mappings is done within the Wildfly JaaS adapter.

>>> >>> So, thats for Undertow....but I don't see any way to wire this all up >>> for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see >>> no way of wiring up AuthenticationMechanisms. I see no other undertow >>> specific config except for undertow-handlers.conf. > > What you can do here is provide a io.undertow.servlet.ServletExtension > implementation (with a META-INF/services entry). > This allows you to modify the deployment before boot time, so you can check > for the presence of a custom configuration file (e.g. jboss-oauth.xml or > whatever), > and if it is present modify the deployment accordingly, adding your > authentication mechanism, and possibly any additional handlers etc that > you need. > Very nice. > At some point soon we will probably provide some way of configuring > additional mechanisms declaratively in jboss-web.xml as well, but that > basically limits you to just > installing a mechanism and configuring via key value properties. > I like the extension model better. > The trickier problem is the JAAS Identity Manager. This was always intended > to be temporary, but I really doubt that PL IDM will be replacing JAAS so > I think we might be stuck with it. > Because this was intended to be temporary there is some additional > functionality in the IDM that does not really belong there (namely it > modifies the picketbox security context, and pushes the principal vs role > map thread local). I will have a look at this today and try and clean this > up a bit. > Can't I just call setIdentityManager within my ServletExtension? I know the JaaS IdentityManager is already kind of hacked because verify()'s behavior is overloaded to propagate the Subject, but its simpler than providing another SPI.

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