[undertow-dev] AuthenticationMechanismFactory

Stuart Douglas sdouglas at redhat.com
Fri Dec 13 15:32:59 EST 2013 

JASPI has special requirements. Basically that method is needed to integrate with WF JASPIC support, otherwise just don't use it.

Stuart

----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Friday, 13 December, 2013 4:51:51 PM
> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> 
> Stuart,
>    I suggest getting rid of setJASPIAuthenticationMechanism(xyz) on the
> deployment info. You are basically tying an API method to a mechanism
> such as JASPI.
> 
> Have an enum on the auth method (Authmethod.FORM, AuthMethod.DIGEST,
> AuthMethod.BASIC, AuthMethod.JASPI) (The web.xml login-method is just a
> string) and then use the addFirstAuthenticationMechanism() or
> setAuthenticationMechanism api to install this adhoc low demand jaspi
> mechanism. Users should be able to provide arbitrary string to the API
> method.
> 
> I am mainly viewing this from DeploymentInfo API aesthetics/usability
> perspective. To me, Undertow is a standalone web container (like Jetty)
> with an usable API (JUnit tests would be the litmus test).
> Extensions/WildFly etc come later.
> 
> Regards,
> Anil
> 
> On 12/13/2013 08: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
>

More information about the undertow-dev mailing list