[undertow-dev] AuthenticationMechanismFactory

Fri Dec 13 09:58:15 EST 2013

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
> 