Re: [undertow-dev] AuthenticationMechanismFactory

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