[undertow-dev] Authentication Mechanism Configuration

[Anil Saldhana]

On 11/25/2013 09:25 AM, Darran Lofthouse wrote:
> I am in favour of both deployment specific approaches and subsystem
> specific approaches - as you say we have two different audiences to make
> use of this.
>
> Looking at your specific mechanism what level of configuration would you
> require?
>
> If you have any complex requirement for the deployment specified
> configuration could you follow a similar approach to Bill and use a
> ServletExtension?
The ServletExtension approach may work for my usecase for deployment level
configuration. I will try it out.

Is there an easy way to test the ServletExtension mechanism in Undertow 
via JUnit,
without the use of WildFly? Not a deal breaker if there is none. :)

> Regards,
> Darran Lofthouse.
>
>
> On 25/11/13 15:19, Anil Saldhana wrote:
>> On 11/25/2013 09:15 AM, Darran Lofthouse wrote:
>>> On 25/11/13 15:11, Anil Saldhana wrote:
>>>>> In my usecase, I want to install my custom authentication mechanism
>>>>> irrespective of what is defined in web.xml
>>> That is what I want to to be able to achieve on the subsystem side of
>>> the configuration.
>>>
>>> I have lost count of the number of times I have seen users say, "I want
>>> to take a single jar and deploy it to a development machine and a
>>> production machine and have different security settings applied on each"
>>> - with the subsystem side of the configuration this is something I want
>>> to be able to achieve.
>>>
>>>>> This is done in JBossWeb by having an authenticator valve via
>>>>> context.xml in the deployment.
>>> Do you see the separate descriptor as a requirement or is that just how
>>> we have done this before?
>>>
>> Two scenarios:
>> a) You can just deploy a web archive with the descriptor and get the
>> functionality.
>> b) Configure at the subsystem level to apply the customization to
>> selected set of web archives.
>>
>> The first scenario is useful for developers who are trying out WF. The
>> second scenario is for devops.
>>
>> It may be better to support both.  Primarily we can recommend subsystem
>> level configuration while
>> supporting deployment level configuration also if desired.