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

[Stuart Douglas]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at 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 at redhat.com>
> >> To: undertow-dev at 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.

Good point. With regard to the thread local bindings I will be moving them out of the JAAS IDM shortly. 

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

You can, you just have to mimic the behaviour of the JAAS IDM to some extent, in terms of setting up the Picketbox security context. Not ideal but it will certainly work. 

Stuart

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