[undertow-dev] Authentication Mechanism Configuration

Anil Saldhana Anil.Saldhana at redhat.com
Mon Nov 25 10:11:37 EST 2013


In my usecase, I want to install my custom authentication mechanism 
irrespective of what is defined in web.xml
This is done in JBossWeb by having an authenticator valve via 
context.xml in the deployment.

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.
>>>


More information about the undertow-dev mailing list