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

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

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

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

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

Hi Stuart, I view it from a pure DeploymentInfo API perspective. I am not thinking about extensions or servers. Right now, my runtime is a JUnit test operating on Undertow. https://gist.github.com/anilsaldhana/7945498

I don't argue about the need for your factory for installing custom authentication mechanism for a particular deployment. I am saying that is an overkill for cases where the authentication mechanism determination is done by the integrating project/layer - be it JUnit Tests or non-wildfly based servers. In that case, it would be ideal to have the additional method to install a particular authentication mechanism for the deployment. Regards, Anil On 12/13/2013 01: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 >>>>>>> >>>>>>>

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.

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. +1 I've been following this discussion and have written authentication systems for JBoss, Tomcat, Weblogic, IIS, Apache, etc and having to constrain to one of a few pre-defined methods is beyond frustrating.

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

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

> > 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. IMO auth extensions are useful in the standalone case as well. I think it’s likely that most users do not write custom auth mechanisms, but simply want to reuse packaged or thirdparty auth in as few steps as possible.

To Darran’s question though, do you ever see a valid use case for KeyCloak combining with other authentication mechanisms?

If you do how should they do it? Keycloak SPI? Plain-ole Handlers?

On Dec 13, 2013, at 9:07 AM, Bill Burke <bburke(a)redhat.com&gt; 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(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 >>> > > -- > 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 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

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.

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(a)redhat.com&gt; 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(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 >>>> >> >> -- >> 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 > > -- > 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

What does ordering have to do with AuthMechFactory? Are you planning an additional META-INF/services mechanism for AuthMechFactorys? If not, how does one plug in one? Via a ServletExtension? If so, *AGAIN*, what is the point of the AuthMechFactory when all the construction can be done within the ServletExtension?

But, while we're talking about ordering... For Keycloak there's an "oauth redirect" mechanism that sends a 302 response back for its challenge. The way the Undertow logic works now, if this mechanism isn't first, the 302 status code will never be sent back, it will never work and you might as well not even list the mechanism. Either my ServletExtension can force it to be first by calling LoginConfig.addFirst(), or it can throw a deployment exception.

BTW, I'm also not sure if you combine a 302 and a WWW-Authenticate it won't confuse the User-Agent. Maybe the ChallengeResult should specify whether iteration of the mechanisms should continue. Finally, I'm assuming that <auth-method>Basic, Keycloak, SSO</auth-method> will fill up the LoginConfig object thats available in DeploymentInfo? Is it ok for the KeycloakServletExtension to remove "KEYCLOAK" from LoginConfig and add two new ones? Looks like I can, just want to make sure any undocumented contract isn't going to be enforced in the future.

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

Again, it would be great if a ChallengeResult could abort the sendChallenge loop. It would suck if there was no workaround for cases that were sensitive to a strict response.

> > On 12/14/2013 5:33 AM, Stuart Douglas wrote: >> >>> What does ordering have to do with AuthMechFactory? Are you planning an >>> additional META-INF/services mechanism for AuthMechFactorys? If not, >>> how does one plug in one? Via a ServletExtension? If so, *AGAIN*, what >>> is the point of the AuthMechFactory when all the construction can be >>> done within the ServletExtension? >> >> Because you can have multiple servlet extensions. This way undertow >> controls the order. If both extensions just add themselves you have no >> defined order. >> > > Again, what does ordering have to do with requiring an AuthMechFactory > interface? > > MyServletExtension { > di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...)); > } > > Why do i need a AuthMechFactory if the servlet extension is able to > construct the AuthMech? I just would never use AuthMechFactory as all > config information is already available within the ServletExtension for > me to construct the AuthMechanism. In fact, there's much more metadata > available within the ServletExtension than is passed to the AuthMechFactory. Note that with my latest changes you can do exactly what you mention above (di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));). I guess the only real thing it buys you is having the ability to configure the same mechanism with different properties, although I am not sure if that is really something that anyone would ever want to do. It also makes reading the config properties easier, as they are passed directly to the factory, although I guess it is pretty easy to just retrieve them directly, especially if I just add a convenience method. So maybe it is not really worth having the factory concept, although given that you don't have to use it if you don't want to I am not sure if we should keep it or not.