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

[Bill Burke]

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.


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