[undertow-dev] Authentication Mechanism Configuration

[Darran Lofthouse]

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?

> On 11/25/2013 09:06 AM, Darran Lofthouse wrote:
>> Ok so the ServletExtension covers cases where a more advanced
>> initialisation is possibly required.
>>
>> How about cases where a mechanism could be instantiated using a default
>> constructor, should we simplify Stuart's example to just cover that?
>>
>> Regarding your keycloak mechanism, could you see any cases where a user
>> would want to be enabling this without the ServletExtension?
>>
>> Regards,
>> Darran Lofthouse.
>>
>> On 25/11/13 14:50, Bill Burke wrote:
>>> IMO, you don't really need to add another SPI.  For Keycloak (oauth)
>>> stuff I'm doing, I just wrote a ServletExtension.  It looks for
>>> "keycloak" in web.xml's auth-method, then applies the appropriate
>>> handlers and looks for the appropriate keycloak config file.
>>>
>>> On 11/25/2013 9:45 AM, Darran Lofthouse wrote:
>>>> Hopefully now is going to be the time to once and for all get the
>>>> authentication mechanism configuration completed for the Undertow /
>>>> WildFly integration.
>>>>
>>>> I have an old discussion I am going through again that covers
>>>> configuring the mechanisms from the subsystem level i.e. a war can have
>>>> it's security settings defined / overridden without the contents of the
>>>> war being affected.
>>>>
>>>> But there is also the second group of users that prefers to have
>>>> complete control within the deployment.
>>>>
>>>> I see you have already suggested the following Stuart: -
>>>>
>>>>      > I was thinking we introduce:
>>>>      >
>>>>      > interface AuthenticationMechanismFactory {
>>>>      >     AuthenticationMechanism create(final Map<String, String> properties);
>>>>      > }
>>>>      >
>>>>      > And then allow a syntax like so:
>>>>      >
>>>>      >
>>>> <auth-method>com.acme.MyAuthMechanismFactory?prop1=val1,prop2=val2</auth-method>
>>>>
>>>> In previous releases the equivalent would have been achieved by defining
>>>> a valve in the web app.
>>>>
>>>> Is this the kind of approach we want for web apps that are defining
>>>> their own mechanisms?  Is there any additional configuration required?
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>