[undertow-dev] Authentication Mechanism Configuration

Mon Nov 25 13:52:41 EST 2013

We could look at this an alternative way.

The two pressing tasks I have are: -
  1 - Configuration for SPNEGO to supply a 'GSSAPIServerSubjectFactory' 
and possibly some additional options.
  2 - Digest config, allowing different hashes, nonce handling and 
different integrity protection options.

When I first raised the subsystem level config idea feedback at the time 
was good - for that reason I was going to address all of this as one.

If the subsystem level config is no longer desired / we are happy with 
the options that exist now I can check that off as out of date and just 
concentrate on the two items above.

Regards,
Darran Lofthouse.

On 25/11/13 18:10, Darran Lofthouse wrote:
> 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
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>