[undertow-dev] AuthenticationMechanismFactory

Jason Greene jason.greene at redhat.com
Fri Dec 13 11:38:26 EST 2013 

On Dec 13, 2013, at 9:51 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

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

I am not sure why it’s separate either. Is it just for convenience? 

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

An enum would be nice, however, it might be confusing mixing Strings and 
enums since they are a closed set. There should definitely be some constant
mechanism though.

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

IMO auth extensions are useful in the standalone case as well. I think
it’s likely that most users do not write custom auth mechanisms, but 
simply want to reuse packaged or thirdparty auth in as few steps as possible.


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

More information about the undertow-dev mailing list