Re: [undertow-dev] AuthenticationMechanismFactory

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(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 >