[undertow-dev] AuthenticationMechanismFactory

[Darran Lofthouse]

Hi Anil,

For this mechanism can you guarantee to us 100% that there is not going 
to be any demand in the future to combine it with any other mechanism?

Regards,
Darran Lofthouse.


On 13/12/13 07:03, Anil Saldhana wrote:
> 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. :)
>
> 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
>