3:45 p.m.
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.
3:50 p.m.
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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:06 p.m.
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
>
4:11 p.m.
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.
>>
4:15 p.m.
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
4:19 p.m.
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.
4:25 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
4:37 p.m.
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.
4:48 p.m.
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(a)redhat.com>
To: undertow-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
7:10 p.m.
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(a)redhat.com>
> To: undertow-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
7:52 p.m.
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(a)redhat.com>
>> To: undertow-dev(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
8:33 p.m.
Maybe look at it more generically rather than as something specific to
security? Make the focus around ServletExtension. (is there an Undertow
only extension?). I say this because, at least for Keycloak, I needed
to not only add AuthMechs, but also handlers as I needed something to
run before and after auth. I also think that yuor #4, "Overriding the
default definition in an app" is also applicable to non-security
functionality. So I would vote for a way to attach a ServletExtension
to a specific deployment declaratively without using META-INF/services
For the case of:
<auth-method>org.some.class?config=1;config=2</auth-method>
You could just provide an implementation of ServletExtension that parses
the string. Maybe even make this string a URL
i.e.
<auth-method>extension://class.name/path?config=1&config=2</auth-method>
Maybe even take this further up the chain and provide a way within
Wildfly to attach a Wildfly extension per deployment. Works as long as
Undertow DeploymentInfo is available as an attachment in the Wildfly
deploy flow. This would be important for applying security (and other
features) to other environments beyond Undertow.
On 11/25/2013 1:10 PM, 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(a)redhat.com>
>> To: undertow-dev(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:26 p.m.
I think the real issue is making extensions 'play nicely' with each other.
Basically something like:
<auth-method>oauth?config=1,SPNEGO:config=2</auth-method>
Basically there is no way for a single extension to deal with that, as it needs to know
about both methods.
You could do something like:
<auth-method>com.acme.OauthProvider?config=1,com.acme.SPNEGOProvider:config=2</auth-method>
But listing the implementation class names is just not as nice. One option would be to
allow ServletExtensions to explicitly register an AuthenticationProviderFactory under a
given name, and then this name will be used to construct it from the <auth-method>
(although then there is the possibility that two extensions will pick the same name, so
probably pick use a full qualified name for the auth method, like org.keycloak.oauth).
Maybe look at it more generically rather than as something specific to
security? Make the focus around ServletExtension. (is there an Undertow
only extension?). I say this because, at least for Keycloak, I needed
to not only add AuthMechs, but also handlers as I needed something to
run before and after auth. I also think that yuor #4, "Overriding the
default definition in an app" is also applicable to non-security
functionality. So I would vote for a way to attach a ServletExtension
to a specific deployment declaratively without using META-INF/services
For the case of:
<auth-method>org.some.class?config=1;config=2</auth-method>
You could just provide an implementation of ServletExtension that parses
the string. Maybe even make this string a URL
i.e.
<auth-method>extension://class.name/path?config=1&config=2</auth-method>
Maybe even take this further up the chain and provide a way within
Wildfly to attach a Wildfly extension per deployment. Works as long as
Undertow DeploymentInfo is available as an attachment in the Wildfly
deploy flow. This would be important for applying security (and other
features) to other environments beyond Undertow.
This is pretty similar to what I suggest above, except that Undertow itself will parse the
string, and we don't use the actual class names for the authenticators. It probably
does not make that much difference either way.
Stuart
On 11/25/2013 1:10 PM, 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(a)redhat.com>
>>> To: undertow-dev(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
9:51 p.m.
On 11/25/2013 3:26 PM, Stuart Douglas wrote:
I think the real issue is making extensions 'play nicely'
with each other. Basically something like:
<auth-method>oauth?config=1,SPNEGO:config=2</auth-method>
Basically there is no way for a single extension to deal with that, as it needs to know
about both methods.
You could do something like:
<auth-method>com.acme.OauthProvider?config=1,com.acme.SPNEGOProvider:config=2</auth-method>
But listing the implementation class names is just not as nice. One option would be to
allow ServletExtensions to explicitly register an AuthenticationProviderFactory under a
given name, and then this name will be used to construct it from the <auth-method>
(although then there is the possibility that two extensions will pick the same name, so
probably pick use a full qualified name for the auth method, like org.keycloak.oauth).
Could add an annotation(s) to the extension:
@AuthMechanism(name="oauth")
public class KeycloakOauth implements ServletExtension {}
Add KeycloakOauth via META-INF/services. Its only triggered if applied
in a <auth-method>.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:58 p.m.
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?
The ServletExtension approach may work for my usecase for
deployment level
configuration. I will try it out.
Is there an easy way to test the ServletExtension mechanism in Undertow
via JUnit,
without the use of WildFly? Not a deal breaker if there is none. :)
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.
10:41 p.m.
On 11/25/2013 02:58 PM, Anil Saldhana wrote:
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?
The ServletExtension approach may work for my usecase for deployment level
configuration. I will try it out.
Is there an easy way to test the ServletExtension mechanism in Undertow
via JUnit,
without the use of WildFly? Not a deal breaker if there is none. :)
I am going to
try the ServiceLoader.load() approach in JUnit.
> 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.
>>
10:51 p.m.
There is no real easy way to do this at the moment, without defining a new class loader.
You can basically create the DeploymentInfo, and call ServletExtension.handleDeployment,
which will work as long as you don't actually need the ServletContext as there is no
way to get it at this point.
I will add a way to test it in the near future.
Stuart
----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
To: undertow-dev(a)lists.jboss.org
Sent: Monday, 25 November, 2013 9:58:34 PM
Subject: Re: [undertow-dev] Authentication Mechanism Configuration
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?
The ServletExtension approach may work for my usecase for deployment level
configuration. I will try it out.
Is there an easy way to test the ServletExtension mechanism in Undertow
via JUnit,
without the use of WildFly? Not a deal breaker if there is none. :)
> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
5:05 p.m.
This is an interesting idea, but it still does not really cover how extensions would work
together, and the extension would still have to manually parse the auth-method string to
read the properties. It also does not quite fit with the idea of what a ServletExtension
is, as they cover more than just security.
What I was thinking was maybe change the DeploymentInfo structure to represent a parsed
auth-method string, e.g.:
List<AuthMethod> authMethods;
class AuthMethod {
String name;
Map<String, String> properties;
}
And then allow extensions to register named factories. Wildfly would then be responsible
for parsing the auth-method string, and extensions can easily see if their auth method is
listed, and register handlers accordingly.
Thoughts?
Stuart
On 11/25/2013 3:26 PM, Stuart Douglas wrote:
> I think the real issue is making extensions 'play nicely' with each other.
> Basically something like:
>
> <auth-method>oauth?config=1,SPNEGO:config=2</auth-method>
>
> Basically there is no way for a single extension to deal with that, as it
> needs to know about both methods.
>
> You could do something like:
>
>
>
<auth-method>com.acme.OauthProvider?config=1,com.acme.SPNEGOProvider:config=2</auth-method>
>
> But listing the implementation class names is just not as nice. One option
> would be to allow ServletExtensions to explicitly register an
> AuthenticationProviderFactory under a given name, and then this name will
> be used to construct it from the <auth-method> (although then there is the
> possibility that two extensions will pick the same name, so probably pick
> use a full qualified name for the auth method, like org.keycloak.oauth).
>
Could add an annotation(s) to the extension:
@AuthMechanism(name="oauth")
public class KeycloakOauth implements ServletExtension {}
Add KeycloakOauth via META-INF/services. Its only triggered if applied
in a <auth-method>.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:06 p.m.
Unless we can do it all in deployers some form of named factories does
sound desirable. Initially within Undertow we have a standard set of
mechanisms with default config settings, within WildFly a factory can
then be used to supply configured instances. Longer term as PicketLink
also provides mechanisms these can be given higher priority than the
standard ones we provide.
I would say however I still think there is a case for a user supplying a
web app defined with a single authentication mechanism and at deployment
time there is a desire to add additional authentication mechansism.
One feature within JBoss Web was that at deployment time if an
authentication mechansism is already set on a web app the default
mechanism handling was skipped - we may also want to consider this to
allow deployers within WildFly to take over this handling.
One topic that has come up a few times recently is the management of
handler chains, I am seeing two different discussions - one on how
create the chain in the first place and secondly how to possible
manipulate it - I wonder if we should review this at the same time.
Regards,
Darran Lofthouse.
On 27/11/13 16:05, Stuart Douglas wrote:
This is an interesting idea, but it still does not really cover how
extensions would work together, and the extension would still have to manually parse the
auth-method string to read the properties. It also does not quite fit with the idea of
what a ServletExtension is, as they cover more than just security.
What I was thinking was maybe change the DeploymentInfo structure to represent a parsed
auth-method string, e.g.:
List<AuthMethod> authMethods;
class AuthMethod {
String name;
Map<String, String> properties;
}
And then allow extensions to register named factories. Wildfly would then be responsible
for parsing the auth-method string, and extensions can easily see if their auth method is
listed, and register handlers accordingly.
Thoughts?
Stuart
> On 11/25/2013 3:26 PM, Stuart Douglas wrote:
>> I think the real issue is making extensions 'play nicely' with each
other.
>> Basically something like:
>>
>> <auth-method>oauth?config=1,SPNEGO:config=2</auth-method>
>>
>> Basically there is no way for a single extension to deal with that, as it
>> needs to know about both methods.
>>
>> You could do something like:
>>
>>
>>
<auth-method>com.acme.OauthProvider?config=1,com.acme.SPNEGOProvider:config=2</auth-method>
>>
>> But listing the implementation class names is just not as nice. One option
>> would be to allow ServletExtensions to explicitly register an
>> AuthenticationProviderFactory under a given name, and then this name will
>> be used to construct it from the <auth-method> (although then there is the
>> possibility that two extensions will pick the same name, so probably pick
>> use a full qualified name for the auth method, like org.keycloak.oauth).
>>
>
> Could add an annotation(s) to the extension:
>
> @AuthMechanism(name="oauth")
> public class KeycloakOauth implements ServletExtension {}
>
> Add KeycloakOauth via META-INF/services. Its only triggered if applied
> in a <auth-method>.
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
6:34 p.m.
----- Original Message -----
From: "Darran Lofthouse"
<darran.lofthouse(a)jboss.com>
To: "Stuart Douglas" <sdouglas(a)redhat.com>, "Bill Burke"
<bburke(a)redhat.com>
Cc: undertow-dev(a)lists.jboss.org
Sent: Wednesday, 27 November, 2013 6:06:01 PM
Subject: Re: [undertow-dev] Authentication Mechanism Configuration
Unless we can do it all in deployers some form of named factories does
sound desirable. Initially within Undertow we have a standard set of
mechanisms with default config settings, within WildFly a factory can
then be used to supply configured instances. Longer term as PicketLink
also provides mechanisms these can be given higher priority than the
standard ones we provide.
I would say however I still think there is a case for a user supplying a
web app defined with a single authentication mechanism and at deployment
time there is a desire to add additional authentication mechansism.
That would still be possible with this approach, just register your factory and then add
its name to the auth mechanisms list.
One feature within JBoss Web was that at deployment time if an
authentication mechansism is already set on a web app the default
mechanism handling was skipped - we may also want to consider this to
allow deployers within WildFly to take over this handling.
Not sure exactly what you mean here, an extension can remove other mechanisms if it
desires.
One topic that has come up a few times recently is the management of
handler chains, I am seeing two different discussions - one on how
create the chain in the first place and secondly how to possible
manipulate it - I wonder if we should review this at the same time.
Sure.
Stuart
Regards,
Darran Lofthouse.
On 27/11/13 16:05, Stuart Douglas wrote:
> This is an interesting idea, but it still does not really cover how
> extensions would work together, and the extension would still have to
> manually parse the auth-method string to read the properties. It also does
> not quite fit with the idea of what a ServletExtension is, as they cover
> more than just security.
>
> What I was thinking was maybe change the DeploymentInfo structure to
> represent a parsed auth-method string, e.g.:
>
> List<AuthMethod> authMethods;
>
> class AuthMethod {
> String name;
> Map<String, String> properties;
> }
>
> And then allow extensions to register named factories. Wildfly would then
> be responsible for parsing the auth-method string, and extensions can
> easily see if their auth method is listed, and register handlers
> accordingly.
>
> Thoughts?
>
> Stuart
>
>> On 11/25/2013 3:26 PM, Stuart Douglas wrote:
>>> I think the real issue is making extensions 'play nicely' with each
>>> other.
>>> Basically something like:
>>>
>>> <auth-method>oauth?config=1,SPNEGO:config=2</auth-method>
>>>
>>> Basically there is no way for a single extension to deal with that, as it
>>> needs to know about both methods.
>>>
>>> You could do something like:
>>>
>>>
>>>
<auth-method>com.acme.OauthProvider?config=1,com.acme.SPNEGOProvider:config=2</auth-method>
>>>
>>> But listing the implementation class names is just not as nice. One
>>> option
>>> would be to allow ServletExtensions to explicitly register an
>>> AuthenticationProviderFactory under a given name, and then this name will
>>> be used to construct it from the <auth-method> (although then there
is
>>> the
>>> possibility that two extensions will pick the same name, so probably pick
>>> use a full qualified name for the auth method, like org.keycloak.oauth).
>>>
>>
>> Could add an annotation(s) to the extension:
>>
>> @AuthMechanism(name="oauth")
>> public class KeycloakOauth implements ServletExtension {}
>>
>> Add KeycloakOauth via META-INF/services. Its only triggered if applied
>> in a <auth-method>.
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
6:38 p.m.
On 27/11/13 17:34, Stuart Douglas wrote:
>
> One feature within JBoss Web was that at deployment time if an
> authentication mechansism is already set on a web app the default
> mechanism handling was skipped - we may also want to consider this to
> allow deployers within WildFly to take over this handling.
Not sure exactly what you mean here, an extension can remove other mechanisms if it
desires.
What I mean here is making sure we don't have mechanisms being added
from multiple locations - but maybe if the deployers are just setting
names and factories and Undertow calls the factories that double
processing of methods would not occur.
8:52 p.m.
Yes, that was another reason why I think the extensions should just register a name,
otherwise ordering between mechanisms would just be a mess.
Stuart
----- Original Message -----
From: "Darran Lofthouse"
<darran.lofthouse(a)jboss.com>
To: "Stuart Douglas" <sdouglas(a)redhat.com>, "Darran Lofthouse"
<darran.lofthouse(a)jboss.com>
Cc: "Bill Burke" <bburke(a)redhat.com>, undertow-dev(a)lists.jboss.org
Sent: Wednesday, 27 November, 2013 6:38:45 PM
Subject: Re: [undertow-dev] Authentication Mechanism Configuration
On 27/11/13 17:34, Stuart Douglas wrote:
>>
>> One feature within JBoss Web was that at deployment time if an
>> authentication mechansism is already set on a web app the default
>> mechanism handling was skipped - we may also want to consider this to
>> allow deployers within WildFly to take over this handling.
>
> Not sure exactly what you mean here, an extension can remove other
> mechanisms if it desires.
What I mean here is making sure we don't have mechanisms being added
from multiple locations - but maybe if the deployers are just setting
names and factories and Undertow calls the factories that double
processing of methods would not occur.
10:28 a.m.
So I have gone ahead with this.
Basically DeploymentInfo now contains a map of name -> AuthenticationMechanismFactory,
and the LoginConfig class now has a list of AuthMethodConfig
structures, which are basically just a name and a properties map.
Wildfly will be setup to parse comma separate auth methods with properties specified via a
query string like syntax, e.g.:
BASIC?silent=true,FORM?error_page=error/page/override.html&post_location=/custom_location
So basically something like oauth can simply register a factory under the name OAUTH (or
maybe com.keycloak.OAUTH to prevent clashes), and then rely on the user specifying that
they want to use it in web.xml.
If you want to register additional handlers etc then your extension should simply iterate
over the auth mechanisms list, and if your mechanisms name is mentioned then then install
your handlers. If you want to completely ignore what is in web.xml you can just clear the
auth methods list and add your own method.
As a result of this I have got rid of the additional authentication mechanims list, and
the ignore standard methods flag, as they should not longer be nessesary. Unfortunately
this is causing problems for the JASPI integration, so I am probably going to add a
special hook for JASPI.
Stuart
----- Original Message -----
From: "Stuart Douglas" <sdouglas(a)redhat.com>
To: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
Cc: undertow-dev(a)lists.jboss.org
Sent: Wednesday, 27 November, 2013 8:52:20 PM
Subject: Re: [undertow-dev] Authentication Mechanism Configuration
Yes, that was another reason why I think the extensions should just register
a name, otherwise ordering between mechanisms would just be a mess.
Stuart
----- Original Message -----
> From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
> To: "Stuart Douglas" <sdouglas(a)redhat.com>, "Darran
Lofthouse"
> <darran.lofthouse(a)jboss.com>
> Cc: "Bill Burke" <bburke(a)redhat.com>, undertow-dev(a)lists.jboss.org
> Sent: Wednesday, 27 November, 2013 6:38:45 PM
> Subject: Re: [undertow-dev] Authentication Mechanism Configuration
>
> On 27/11/13 17:34, Stuart Douglas wrote:
> >>
> >> One feature within JBoss Web was that at deployment time if an
> >> authentication mechansism is already set on a web app the default
> >> mechanism handling was skipped - we may also want to consider this to
> >> allow deployers within WildFly to take over this handling.
> >
> > Not sure exactly what you mean here, an extension can remove other
> > mechanisms if it desires.
>
> What I mean here is making sure we don't have mechanisms being added
> from multiple locations - but maybe if the deployers are just setting
> names and factories and Undertow calls the factories that double
> processing of methods would not occur.
>
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
3805
days inactive
3812
days old
22 comments
4 participants
participants (4)
-
Anil Saldhana -
Bill Burke -
Darran Lofthouse -
Stuart Douglas