On 14/05/13 20:56, Anil Saldhana wrote:
Undertow has handlers which are like a chain of interceptors. It
have a SecurityHandler
to which you can define authentication mehanisms. Standard servlet auth
are available to you. If you would like to change behavior of
authentication, you write your own authentication mechanism.
+1 The use of the authentication mechanisms also gives us the ability to
support multiple mechanisms concurrently. (Obviously subject to the
limitations of the mechanisms themselves e.g. we could not support two
versions of FORM auth concurrently)
On an incoming request where authentication is required each mechanism
is given the opportunity to inspect the incoming request to perform
authentication if it is possible. e.g. Client Cert will check if there
is a SSLContext it can use, BASIC auth would check if the header with
the username and password has been received.
If no mechanism is capable of handling the request and authentication is
required all mechanisms are asked to add their challenge to the response
- this is how we can combine say SPNEGO with Digest or FORM auth.
Finally there is also a middle ground where a mechanism is attempting
authentication but identifies an additional round trip is required - in
that case the mechanism can indicate the processing should move straight
to the sending challenges phase.
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)
> 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:
>> 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).
>> On 05/14/2013 06:55 AM, Bill Burke wrote:
>>> Take a look at Feature, DynamicFeature, and Configurable for JAX-RS 2.0
>>> 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.
undertow-dev mailing list
Darran Lofthouse - Principal Software Engineer
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)