[undertow-dev] AuthenticationMechanismFactory

Bill Burke bburke at redhat.com
Fri Dec 13 13:34:00 EST 2013 





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 at redhat.com> 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 at redhat.com>
>>>> To: undertow-dev at 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 at redhat.com>
>>>>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>>>> Cc: undertow-dev at 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 at redhat.com>
>>>>>>>>> To: undertow-dev at 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 at redhat.com>
>>>>>>>>>>> To: undertow-dev at 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/undertow/security/api/AuthenticationMechanismFactory.java
>>>>>>>>>>>
>>>>>>>>>>> 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 at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> undertow-dev mailing list
>>>>>>>> undertow-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> undertow-dev mailing list
>>>>>>> undertow-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> undertow-dev mailing list
>>>>>> undertow-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at 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 at 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 at 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

More information about the undertow-dev mailing list