[undertow-dev] Authentication Mechanism Configuration

[Darran Lofthouse]

I think these are the main problem areas we could choose to solve.

1 - Definition of new mechanisms.
2 - Chaining of mechanisms.
3 - Custom mechanism configuration.
4 - Overriding default definition in an app.

For #1 the ServletExtension makes that quite easy, if you want to add a 
new mechanism to WildFly you can add it as a module or within the 
deployment - provided it is found by a ServiceLoader it can set the 
mechanism and as the extension was found class loading should be simplified.

#2 is also already in there, I see the mechanisms now support being a 
comma separated list.

The issue there however is that I don't think  #1 and #2 are working 
together cleanly, i.e. we may have an ordered list of methods and 
ServletExtension implementations assuming only one mechanism is 
specified - or even if the ServletExtension does take it as a comma 
separated list no way for the two to work together to get the mechanisms 
in the desired order.

For #3 we could concentrate on the areas involving the standard 
mechanisms, we still need config for SPNEGO and we need a few more 
options for Digest - there is a chance some of this config could become 
specific to the web app but we could leave that until it becomes a problem.

For #4 I have seen demand for taking a web app with existing 
configuration and overriding the security settings without modifying the 
app - this would allow the same app to be taken through development 
through QA, staging and into production with just the servers 
configuration differing.

But then maybe what we have is sufficient, if the PicketLink subsystem 
is going to be setting mechanisms maybe that is the place a chained 
configuration should be defined.  I think this is going to be a key 
question - long term as we place more emphasis on PicketLink IDM where 
is the responsibility going to be to set a chain of authentication 
mechanisms?

Regards,
Darran Lofthouse.



On 25/11/13 15:48, Stuart Douglas wrote:
> If we allowed users to set ServletContext attributes at the subsystem level, you could also support the subsystem wide case via ServletExtension.
>
> Basically instead of looking at the auth mechanism an extension can look at the servlet context attributes and decide to activate or not.
>
> Not sure if we also need a 'cleaner' way to do this.
>
> Stuart
>
>
>
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Monday, 25 November, 2013 4:37:06 PM
>> Subject: Re: [undertow-dev] Authentication Mechanism Configuration
>>
>>  From my side, the deployment level approach will suffice.
>>
>> Since a deployment goes through the PicketLink WildFly Subsystem, we can
>> always
>> use the Undertow API to replace the default authentication mechanism
>> with what we need, in the PL subsystem.
>>
>> I am unsure if we have WF users who really want to bulk change
>> authentication mechanisms in a few web archives
>> at the subsystem level.
>>
>> 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?
>>>
>>> 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.
>> _______________________________________________
>> 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
>