[undertow-dev] AuthenticationMechanismFactory

Fri Dec 13 09:27:53 EST 2013

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