Re: [undertow-dev] AuthenticationMechanismFactory

From: "Bill Burke" <bburke(a)redhat.com&gt; To: undertow-dev(a)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(a)redhat.com&gt; >> To: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >> Cc: undertow-dev(a)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(a)redhat.com&gt; >>>>> To: undertow-dev(a)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(a)redhat.com&gt; >>>>>>> To: undertow-dev(a)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... >>>>>>> >>>>>>> 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev