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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev