[undertow-dev] AuthenticationMechanismFactory

Fri Dec 13 10:51:51 EST 2013

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 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
>>>>>>>
>>>>>>>   