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.