[undertow-dev] modeling the handler Factory interface

Anil Saldhana Anil.Saldhana at redhat.com
Tue May 14 15:56:51 EDT 2013


Undertow has handlers which are like a chain of interceptors. It does 
have a SecurityHandler
to which you can define authentication mehanisms. Standard servlet auth 
mechs (form,basic,digest,client-cert)
are available to you.  If you would like to change behavior of 
authentication, you write your own authentication mechanism.
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/security/api/AuthenticationMechanism.java

On 05/14/2013 02:42 PM, Bill Burke wrote:
> Not sure what "custom auth scheme" means yet, but my implementation
> includes the following:
>
> * a way to define an oauth provider
Custom Auth mech is sufficient.
> * a way to use oauth as an SSO mechanism (an oauth consumer)
Custom Auth mech on the consumer.
> * traditional oauth thirdparty auth
Custom Auth mech on the consumer. External third party stuff is config 
to auth mech.
> * bearer token auth
Custom Auth Mech.
> * bearer token grants
Not Undertow but a concern of your auth mechanism.  May use IDM/Meta.
> * a few management URIs for distributed log-out
You may need handlers here but I guess your auth mech can probably 
handle global log out also.
We handle GLO in our SAML IDP.  I am guessing your oauth workflows will 
be similar given that tokens come as headers rather than post data (xml)
https://github.com/picketlink2/federation/blob/master/picketlink-bindings/picketlink-tomcat-common/src/main/java/org/picketlink/identity/federation/bindings/tomcat/idp/AbstractIDPValve.java
https://github.com/picketlink2/federation/blob/master/picketlink-bindings/picketlink-tomcat5/src/main/java/org/picketlink/identity/federation/bindings/tomcat/idp/IDPWebBrowserSSOValve.java

>
> I'm also not exactly sure what a "handler" is supposed to be yet, but
> based on the above, there's a number of URI endpoints that need to be
> added and supported automatically.
>
> I'm currently bogged down trying to pass the jaxrs2 tck.  My next task
> is to try and port my oauth stuff, at least as a prototype, to help
> flush out the security APIs or at least to be an additional guinea pig.
>
>
>
> On 5/14/2013 3:29 PM, Anil Saldhana wrote:
>> Bill,
>>      have you tried plugging in a custom authentication scheme?  I am not
>> sure you need your own handler.  If you look at it, for OAuth bearer
>> token, you just need OAuthAuthenticationScheme that pulls in the bearer
>> token from the header. You can certainly use http redirect to a OAuth
>> provider (to get some token).
>>
>> Regards,
>> Anil
>>
>> On 05/14/2013 06:55 AM, Bill Burke wrote:
>>> Take a look at Feature, DynamicFeature, and Configurable for JAX-RS 2.0
>>>
>>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/jaxrs-api/src/main/java/javax/ws/rs/core/Feature.java
>>>
>>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/jaxrs-api/src/main/java/javax/ws/rs/core/Configurable.java
>>>
>>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/jaxrs-api/src/main/java/javax/ws/rs/container/DynamicFeature.java
>>>
>>>
>>> Feature is your factory concept.  Its passed a Configurable that allows
>>> you to look up config properties and register components.
>>> DynamicFeature allows you to bind per-endpoint.
>>>
>>> Might want to check out the filter model as well.  Resteasy made use of
>>> the JAX-RS filter model in a variety of use cases in both sync and async
>>> environments.  The model was also vetted by other vendors.  Might be
>>> something to check out to see if Undertow handler's missed anything.
>>> When I get a chance to port my OAuth stuff I'll have more suggestions
>>> for your handler API, maybe.
>>>
>>>


More information about the undertow-dev mailing list