Re: [undertow-dev] AuthenticationMechanismFactory

Stuart, I suggest getting rid of setJASPIAuthenticationMechanism(xyz) on the deployment info. You are basically tying an API method to a mechanism such as JASPI.

Have an enum on the auth method (Authmethod.FORM, AuthMethod.DIGEST, AuthMethod.BASIC, AuthMethod.JASPI) (The web.xml login-method is just a string) and then use the addFirstAuthenticationMechanism() or setAuthenticationMechanism api to install this adhoc low demand jaspi mechanism. Users should be able to provide arbitrary string to the API method.

I am mainly viewing this from DeploymentInfo API aesthetics/usability perspective. To me, Undertow is a standalone web container (like Jetty) with an usable API (JUnit tests would be the litmus test). Extensions/WildFly etc come later.

Regards, Anil On 12/13/2013 08:58 AM, Stuart Douglas wrote: > Ok, I have added some convenience methods. > > Now you can just do: > > d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new OAuthAuthenticationMechanism()); > > Behind the scenes it is still the same thing though. Basically the first call clears out any configured auth methods, and the second registers a factory that just returns the same instance, and then adds it to the start of the authentication mechanisms list. > > Stuart > > ----- Original Message ----- >> From: "Bill Burke" <bburke(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