[undertow-dev] AuthenticationMechanismFactory

Stuart Douglas sdouglas at redhat.com
Fri Dec 13 16:02:06 EST 2013 

> 
> 
> On 12/13/2013 11:23 AM, Jason Greene wrote:
> > To Darran’s question though, do you ever see a valid use case for KeyCloak
> > combining with other authentication mechanisms?
> >
> 
> Keycloak can be combined with other auth mechanisms.
> 
> > If you do how should they do it? Keycloak SPI? Plain-ole Handlers?
> >
> 
> Through standard Undertow SPIs/config.
> 
> Specifying an web.xml <auth-method> of "KEYCLOAK" would add multiple
> AuthMechanisms and handlers.  I do this through the ServletExtension SPI.


Ok, I have added another utility method, isAuthenticationMechanismPresent(String name).

So now the code to do this is basically:

if(d.isAuthenticationMechanismPresent("KEYCLOAK")) {
  d.addAuthenticationMechanism("KEYCLOAK", keycloadFactory);
  //add handlers and stuff
}

The reason why this is better that just adding you auth mechanism is because Undertow now controls the order. In the old
way of doing things if the user had specified something like:

BASIC?silent=true,KEYCLOAK,SSO

There is simply no way for extensions to parse that string and install themselves in the correct order (and order is very important). For one thing all the extension have to parse it in the exact same way, but more importantly because there is no ordering between extensions, there is no reliable way for an extension to figure out where it has to insert itself in the mechanism list.

With the factory SPI, this is all taken care of for you, all you have to do is register it under the correct name, and undertow takes care of the rest.

Basically have a security SPI that is capable of handling multiple mechanisms buys you nothing if you have no way of reliably configuring said mechanisms.

Stuart



> 
> Besides AuthMechnanisms, I need need additional handlers to do preflight
> cors (runs before authentication) and handlers that run after
> authentication: CORS origin validation, remote session and adapter mgmt
> URIs, and other security related REST apis that the adapter provides.
> 
> 
> 
> > On Dec 13, 2013, at 9:07 AM, Bill Burke <bburke at redhat.com> wrote:
> >
> >> Don't care that much about the convenience as long as it doesn't hinter
> >> implementation.  Superfluous APIs just bug me.  Just seems that
> >> AuthMechFactory is only usable for very simple cases that don't require
> >> access to metadata beyond the property map you pass or require adding
> >> additional handlers and/or mechanisms.
> >>
> >> At this point though, I just want a stable API.
> >>
> >> On 12/13/2013 9:58 AM, Stuart Douglas wrote:
> >>> Ok, I have added some convenience methods.
> >>>
> >>> Now you can just do:
> >>>
> >>> d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new
> >>> OAuthAuthenticationMechanism());
> >>>
> >>> Behind the scenes it is still the same thing though. Basically the first
> >>> call clears out any configured auth methods, and the second registers a
> >>> factory that just returns the same instance, and then adds it to the
> >>> start of the authentication mechanisms list.
> >>>
> >>> Stuart
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: undertow-dev at lists.jboss.org
> >>>> Sent: Friday, 13 December, 2013 3:27:53 PM
> >>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> >>>>
> >>>> This point is bogus.  You can write ServletExtensions that are triggered
> >>>> only by metadata defined within a deployment.  I never understood why
> >>>> you needed this extra SPI.
> >>>>
> >>>> Also, at least in my Keycloak case, AuthMechFactory isn't enough for me
> >>>> and I have to write an extension anyways.  I need to add additional
> >>>> handlers that operate pre and post authentication.
> >>>> AuthenticationMechanismFactory is just an additional level of
> >>>> indirection I don't want or need.
> >>>>
> >>>> On 12/13/2013 2:41 AM, Stuart Douglas wrote:
> >>>>> For a good example of extensions should just be using the factory
> >>>>> mechanism, consider the case for extensions that are bundled with
> >>>>> Wildfly.
> >>>>>
> >>>>> If an extension simply tries to take over a deployments authentication
> >>>>> mechanism, then we could never bundle it in the server, as it would
> >>>>> take
> >>>>> over all deployments. Extensions that use the factory mechanism though
> >>>>> can
> >>>>> be bundled in the server and exposed to all deployments, and the user
> >>>>> selects the mechanism to use via a standard descriptor.
> >>>>>
> >>>>> Stuart
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Stuart Douglas" <sdouglas at redhat.com>
> >>>>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >>>>>> Cc: undertow-dev at lists.jboss.org
> >>>>>> Sent: Friday, 13 December, 2013 8:29:17 AM
> >>>>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> You should remove that setJaspiAuthenticationMechanism and use the
> >>>>>>> setAuthenticationMechanism(string,authmech) format. That is my
> >>>>>>> opinion.
> >>>>>>> :)
> >>>>>>>
> >>>>>>> In my use case, I have a single authentication mechanism which I want
> >>>>>>> to
> >>>>>>> use for the webapp
> >>>>>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
> >>>>>>>
> >>>>>>> That is it.
> >>>>>>>
> >>>>>>> I can use the Factory indirection that you have recently added but it
> >>>>>>> is
> >>>>>>> counter intuitive and overkill for my use case.
> >>>>>>>
> >>>>>>> Users of undertow API will ask the same question or get confused if
> >>>>>>> their simple use cases such as mine are not covered with a direct
> >>>>>>> API method. :)
> >>>>>>
> >>>>>> Why do you want to completely override the method, and ignore whatever
> >>>>>> method
> >>>>>> a user has configured? In general I would prefer that mechanisms used
> >>>>>> the
> >>>>>> factory mechanism, so they all behave in a consistent manner. What is
> >>>>>> your
> >>>>>> use case that makes this not an option?
> >>>>>>
> >>>>>> Stuart
> >>>>>>
> >>>>>>>
> >>>>>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
> >>>>>>>> There already is one:
> >>>>>>>>
> >>>>>>>> io.undertow.servlet.api.DeploymentInfo#setJaspiAuthenticationMechanism
> >>>>>>>>
> >>>>>>>> At the moment it is used for JASPI only, hence the name. I thought
> >>>>>>>> about
> >>>>>>>> giving it a more generic sounding name but in general I don't really
> >>>>>>>> want
> >>>>>>>> to encourage its use, unless it is actually needed.
> >>>>>>>>
> >>>>>>>> Why do you need this?
> >>>>>>>>
> >>>>>>>> Stuart
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >>>>>>>>> To: undertow-dev at lists.jboss.org
> >>>>>>>>> Sent: Friday, 13 December, 2013 12:23:22 AM
> >>>>>>>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> >>>>>>>>>
> >>>>>>>>> Stuart,
> >>>>>>>>>       would it be possible to have an overloaded method in the
> >>>>>>>>> DeploymentInfo (as before) to just add one authentication mechanism
> >>>>>>>>> without the factory?  You can have the other
> >>>>>>>>> addAuthenticationMechanism
> >>>>>>>>> method to do your factory you are describing here.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Anil
> >>>>>>>>>
> >>>>>>>>> On 12/12/2013 05:14 PM, Stuart Douglas wrote:
> >>>>>>>>>> There are a few major advantages.
> >>>>>>>>>>
> >>>>>>>>>> Now all an extension does is register the factory, and the user
> >>>>>>>>>> can
> >>>>>>>>>> enable
> >>>>>>>>>> it in web.xml (or jboss-web.xml) using whatever options they want,
> >>>>>>>>>> in
> >>>>>>>>>> whatever order they want. If an extension really wants to
> >>>>>>>>>> completely
> >>>>>>>>>> override the auth mechanism it can still do that, by simply
> >>>>>>>>>> clearing
> >>>>>>>>>> the
> >>>>>>>>>> auth mechanism list and adding the name of its mechanism instead.
> >>>>>>>>>>
> >>>>>>>>>> Basically before there was no real way for extensions to play
> >>>>>>>>>> nicely
> >>>>>>>>>> with
> >>>>>>>>>> each other. Undertow has the ability for multiple authentication
> >>>>>>>>>> mechanisms to work correctly together, but with the old way there
> >>>>>>>>>> was
> >>>>>>>>>> no
> >>>>>>>>>> reliable way to actually use this with custom authentication
> >>>>>>>>>> mechanisms,
> >>>>>>>>>> as there was no way to specify order.Custom mechanisms would also
> >>>>>>>>>> need
> >>>>>>>>>> to
> >>>>>>>>>> have a custom way of configuration, e.g. reading options from a
> >>>>>>>>>> separate
> >>>>>>>>>> file.
> >>>>>>>>>>
> >>>>>>>>>> Now custom mechanisms work exactly the same way as the standard
> >>>>>>>>>> mechanisms,
> >>>>>>>>>> it is easy to specify the order, it is easy to configure any
> >>>>>>>>>> properties
> >>>>>>>>>> that may be required, and no functionality has been lost, as an
> >>>>>>>>>> extension
> >>>>>>>>>> can still override auth mechanisms if that is the intent.
> >>>>>>>>>>
> >>>>>>>>>> The fact that not all methods may use the form data parser is
> >>>>>>>>>> irrelevant,
> >>>>>>>>>> some methods will and so it is provided.
> >>>>>>>>>>
> >>>>>>>>>> Stuart
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >>>>>>>>>>> To: undertow-dev at lists.jboss.org
> >>>>>>>>>>> Sent: Thursday, 12 December, 2013 11:10:48 PM
> >>>>>>>>>>> Subject: [undertow-dev] AuthenticationMechanismFactory
> >>>>>>>>>>>
> >>>>>>>>>>> Stuart,
> >>>>>>>>>>>        I am trying to understand the reasoning behind the new
> >>>>>>>>>>>        factory
> >>>>>>>>>>>        added
> >>>>>>>>>>> for authentication mechanisms
> >>>>>>>>>>> https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/security/api/AuthenticationMechanismFactory.java
> >>>>>>>>>>>
> >>>>>>>>>>> Why not just allow the direct install of authentication
> >>>>>>>>>>> mechanisms
> >>>>>>>>>>> like
> >>>>>>>>>>> we did before in the DeploymentInfo?
> >>>>>>>>>>>
> >>>>>>>>>>> I am unsure we need another level of indirection with this
> >>>>>>>>>>> factory
> >>>>>>>>>>> which
> >>>>>>>>>>> also has access to the FormDataParser.  Basically, the specifics
> >>>>>>>>>>> of
> >>>>>>>>>>> FORM
> >>>>>>>>>>> authentication have sneaked into this factory. Many of the
> >>>>>>>>>>> authentication mechanisms do not even involve forms.
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Anil
> >>>>>>>>> _______________________________________________
> >>>>>>>>> undertow-dev mailing list
> >>>>>>>>> undertow-dev at lists.jboss.org
> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> undertow-dev mailing list
> >>>>>>>> undertow-dev at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> undertow-dev mailing list
> >>>>>>> undertow-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> undertow-dev mailing list
> >>>>>> undertow-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>>
> >>>>> _______________________________________________
> >>>>> undertow-dev mailing list
> >>>>> undertow-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>
> >>>>
> >>>> --
> >>>> 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
> >>>>
> >>
> >> --
> >> 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
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>

More information about the undertow-dev mailing list