[undertow-dev] Authentication Mechanism Configuration

[Stuart Douglas]

----- Original Message -----
> From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Wednesday, 27 November, 2013 6:06:01 PM
> Subject: Re: [undertow-dev] Authentication Mechanism Configuration
> 
> Unless we can do it all in deployers some form of named factories does
> sound desirable.  Initially within Undertow we have a standard set of
> mechanisms with default config settings, within WildFly a factory can
> then be used to supply configured instances.  Longer term as PicketLink
> also provides mechanisms these can be given higher priority than the
> standard ones we provide.
> 
> I would say however I still think there is a case for a user supplying a
> web app defined with a single authentication mechanism and at deployment
> time there is a desire to add additional authentication mechansism.

That would still be possible with this approach, just register your factory and then add its name to the auth mechanisms list.

> 
> One feature within JBoss Web was that at deployment time if an
> authentication mechansism is already set on a web app the default
> mechanism handling was skipped - we may also want to consider this to
> allow deployers within WildFly to take over this handling.

Not sure exactly what you mean here, an extension can remove other mechanisms if it desires.

> 
> One topic that has come up a few times recently is the management of
> handler chains, I am seeing two different discussions - one on how
> create the chain in the first place and secondly how to possible
> manipulate it - I wonder if we should review this at the same time.
> 

Sure.

Stuart

> Regards,
> Darran Lofthouse.
> 
> 
> On 27/11/13 16:05, Stuart Douglas wrote:
> > This is an interesting idea, but it still does not really cover how
> > extensions would work together, and the extension would still have to
> > manually parse the auth-method string to read the properties. It also does
> > not quite fit with the idea of what a ServletExtension is, as they cover
> > more than just security.
> >
> > What I was thinking was maybe change the DeploymentInfo structure to
> > represent a parsed auth-method string, e.g.:
> >
> > List<AuthMethod> authMethods;
> >
> > class AuthMethod {
> >   String name;
> >   Map<String, String> properties;
> > }
> >
> > And then allow extensions to register named factories. Wildfly would then
> > be responsible for parsing the auth-method string, and extensions can
> > easily see if their auth method is listed, and register handlers
> > accordingly.
> >
> > Thoughts?
> >
> > Stuart
> >
> >> On 11/25/2013 3:26 PM, Stuart Douglas wrote:
> >>> I think the real issue is making extensions 'play nicely' with each
> >>> other.
> >>> Basically something like:
> >>>
> >>> <auth-method>oauth?config=1,SPNEGO:config=2</auth-method>
> >>>
> >>> Basically there is no way for a single extension to deal with that, as it
> >>> needs to know about both methods.
> >>>
> >>> You could do something like:
> >>>
> >>>
> >>> <auth-method>com.acme.OauthProvider?config=1,com.acme.SPNEGOProvider:config=2</auth-method>
> >>>
> >>> But listing the implementation class names is just not as nice. One
> >>> option
> >>> would be to allow ServletExtensions to explicitly register an
> >>> AuthenticationProviderFactory under a given name, and then this name will
> >>> be used to construct it from the <auth-method> (although then there is
> >>> the
> >>> possibility that two extensions will pick the same name, so probably pick
> >>> use a full qualified name for the auth method, like org.keycloak.oauth).
> >>>
> >>
> >> Could add an annotation(s) to the extension:
> >>
> >> @AuthMechanism(name="oauth")
> >> public class KeycloakOauth implements ServletExtension {}
> >>
> >> Add KeycloakOauth via META-INF/services.  Its only triggered if applied
> >> in a <auth-method>.
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
>