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

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

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

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.

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.