10:59 p.m.
Hi Stuart/Darran,
I sent in a PR
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
to override the authentication mechanism used for a particular web app
irrespective of what is configured in web.xml login config
I need this behavior to introduce saml workflow into a web app.
I put the API change at the DeploymentManagerImpl level. If you have a
better alternative, I would like to hear.
Regards,
Anil
1:13 a.m.
I changed this to the DeploymentInfo level, and also made it a list to
allow multiple custom authentication mechanisms to be used in the same
deployment.
Stuart
Anil Saldhana wrote:
Hi Stuart/Darran,
I sent in a PR
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
to override the authentication mechanism used for a particular web app
irrespective of what is configured in web.xml login config
I need this behavior to introduce saml workflow into a web app.
I put the API change at the DeploymentManagerImpl level. If you have a
better alternative, I would like to hear.
Regards,
Anil
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
1:21 a.m.
New subject: Overriding Authentication Mechanism for the deployment
Also another location is Undertow->LoginConfig class probably we need the same
flexibility.
I did see a TODO there.
On May 13, 2013, at 6:13 PM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
I changed this to the DeploymentInfo level, and also made it a list
to
allow multiple custom authentication mechanisms to be used in the same
deployment.
Stuart
Anil Saldhana wrote:
> Hi Stuart/Darran,
> I sent in a PR
>
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
> to override the authentication mechanism used for a particular web app
> irrespective of what is configured in web.xml login config
>
> I need this behavior to introduce saml workflow into a web app.
>
> I put the API change at the DeploymentManagerImpl level. If you have a
> better alternative, I would like to hear.
>
> Regards,
> Anil
> _______________________________________________
> 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
1:29 a.m.
New subject: Overriding Authentication Mechanism for the deployment
That maps to the login-config element in web.xml. I was just thinking
about how we could allow this to configure custom authenticators. A
class name by itself is not enough, as you need some way of configuring
the authenticator.
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>
Thoughts?
Stuart
Anil Saldhana wrote:
Also another location is Undertow->LoginConfig class probably we
need the same flexibility.
I did see a TODO there.
On May 13, 2013, at 6:13 PM, Stuart Douglas<sdouglas(a)redhat.com> wrote:
> I changed this to the DeploymentInfo level, and also made it a list to
> allow multiple custom authentication mechanisms to be used in the same
> deployment.
>
> Stuart
>
> Anil Saldhana wrote:
>> Hi Stuart/Darran,
>> I sent in a PR
>>
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
>> to override the authentication mechanism used for a particular web app
>> irrespective of what is configured in web.xml login config
>>
>> I need this behavior to introduce saml workflow into a web app.
>>
>> I put the API change at the DeploymentManagerImpl level. If you have a
>> better alternative, I would like to hear.
>>
>> Regards,
>> Anil
>> _______________________________________________
>> 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
2:26 a.m.
New subject: Overriding Authentication Mechanism for the deployment
I will answer tomorrow. Need to provide some details. :)
On May 13, 2013, at 6:29 PM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
That maps to the login-config element in web.xml. I was just thinking
about how we could allow this to configure custom authenticators. A
class name by itself is not enough, as you need some way of configuring
the authenticator.
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>
Thoughts?
Stuart
Anil Saldhana wrote:
> Also another location is Undertow->LoginConfig class probably we need the same
flexibility.
> I did see a TODO there.
>
> On May 13, 2013, at 6:13 PM, Stuart Douglas<sdouglas(a)redhat.com> wrote:
>
>> I changed this to the DeploymentInfo level, and also made it a list to
>> allow multiple custom authentication mechanisms to be used in the same
>> deployment.
>>
>> Stuart
>>
>> Anil Saldhana wrote:
>>> Hi Stuart/Darran,
>>> I sent in a PR
>>>
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
>>> to override the authentication mechanism used for a particular web app
>>> irrespective of what is configured in web.xml login config
>>>
>>> I need this behavior to introduce saml workflow into a web app.
>>>
>>> I put the API change at the DeploymentManagerImpl level. If you have a
>>> better alternative, I would like to hear.
>>>
>>> Regards,
>>> Anil
>>> _______________________________________________
>>> 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
2:26 a.m.
New subject: Overriding Authentication Mechanism for the deployment
One thing we have been attempting to do, is not have any class names show up in
configuration, also an Andiamo tenant.
We had some of this with XNIO/Remoting for awhile, but there were all removed, after I
discovered it. I'm not sure what the implementation approach was to keep from
exposing the internal class names in the configuration, but I am pretty sure Brian knows
what the approach has been.
Of course, in this case, you are talking about a user supplied implementation, so I'm
not sure this is avoidable, or even applicable, but I thought I would mention it.
Andy
----- Original Message -----
From: "Stuart Douglas" <sdouglas(a)redhat.com>
To: "Anil Saldhana" <asaldhan(a)redhat.com>
Cc: undertow-dev(a)lists.jboss.org
Sent: Monday, May 13, 2013 5:29:29 PM
Subject: Re: [undertow-dev] Overriding Authentication Mechanism for the deployment
That maps to the login-config element in web.xml. I was just thinking
about how we could allow this to configure custom authenticators. A
class name by itself is not enough, as you need some way of
configuring
the authenticator.
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>
Thoughts?
Stuart
Anil Saldhana wrote:
> Also another location is Undertow->LoginConfig class probably we
> need the same flexibility.
> I did see a TODO there.
>
> On May 13, 2013, at 6:13 PM, Stuart Douglas<sdouglas(a)redhat.com>
> wrote:
>
>> I changed this to the DeploymentInfo level, and also made it a
>> list to
>> allow multiple custom authentication mechanisms to be used in the
>> same
>> deployment.
>>
>> Stuart
>>
>> Anil Saldhana wrote:
>>> Hi Stuart/Darran,
>>> I sent in a PR
>>>
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
>>> to override the authentication mechanism used for a particular
>>> web app
>>> irrespective of what is configured in web.xml login config
>>>
>>> I need this behavior to introduce saml workflow into a web app.
>>>
>>> I put the API change at the DeploymentManagerImpl level. If you
>>> have a
>>> better alternative, I would like to hear.
>>>
>>> Regards,
>>> Anil
>>> _______________________________________________
>>> 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
2:46 a.m.
New subject: Overriding Authentication Mechanism for the deployment
This would be for user supplied authenticators.
Stuart
Andrig Miller wrote:
One thing we have been attempting to do, is not have any class names
show up in configuration, also an Andiamo tenant.
We had some of this with XNIO/Remoting for awhile, but there were all removed, after I
discovered it. I'm not sure what the implementation approach was to keep from
exposing the internal class names in the configuration, but I am pretty sure Brian knows
what the approach has been.
Of course, in this case, you are talking about a user supplied implementation, so I'm
not sure this is avoidable, or even applicable, but I thought I would mention it.
Andy
----- Original Message -----
> From: "Stuart Douglas"<sdouglas(a)redhat.com>
> To: "Anil Saldhana"<asaldhan(a)redhat.com>
> Cc: undertow-dev(a)lists.jboss.org
> Sent: Monday, May 13, 2013 5:29:29 PM
> Subject: Re: [undertow-dev] Overriding Authentication Mechanism for the deployment
>
> That maps to the login-config element in web.xml. I was just thinking
> about how we could allow this to configure custom authenticators. A
> class name by itself is not enough, as you need some way of
> configuring
> the authenticator.
>
> 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>
>
> Thoughts?
>
> Stuart
>
>
> Anil Saldhana wrote:
>> Also another location is Undertow->LoginConfig class probably we
>> need the same flexibility.
>> I did see a TODO there.
>>
>> On May 13, 2013, at 6:13 PM, Stuart Douglas<sdouglas(a)redhat.com>
>> wrote:
>>
>>> I changed this to the DeploymentInfo level, and also made it a
>>> list to
>>> allow multiple custom authentication mechanisms to be used in the
>>> same
>>> deployment.
>>>
>>> Stuart
>>>
>>> Anil Saldhana wrote:
>>>> Hi Stuart/Darran,
>>>> I sent in a PR
>>>>
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
>>>> to override the authentication mechanism used for a particular
>>>> web app
>>>> irrespective of what is configured in web.xml login config
>>>>
>>>> I need this behavior to introduce saml workflow into a web app.
>>>>
>>>> I put the API change at the DeploymentManagerImpl level. If you
>>>> have a
>>>> better alternative, I would like to hear.
>>>>
>>>> Regards,
>>>> Anil
>>>> _______________________________________________
>>>> 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
>
3:02 a.m.
New subject: Overriding Authentication Mechanism for the deployment
Maybe have something more sophisticated?
Couldn't you just configure these custom application-provided security
providers through context parameters?
On 5/13/2013 8:26 PM, Andrig Miller wrote:
One thing we have been attempting to do, is not have any class names
show up in configuration, also an Andiamo tenant.
We had some of this with XNIO/Remoting for awhile, but there were all removed, after I
discovered it. I'm not sure what the implementation approach was to keep from
exposing the internal class names in the configuration, but I am pretty sure Brian knows
what the approach has been.
Of course, in this case, you are talking about a user supplied implementation, so I'm
not sure this is avoidable, or even applicable, but I thought I would mention it.
Andy
----- Original Message -----
> From: "Stuart Douglas" <sdouglas(a)redhat.com>
> To: "Anil Saldhana" <asaldhan(a)redhat.com>
> Cc: undertow-dev(a)lists.jboss.org
> Sent: Monday, May 13, 2013 5:29:29 PM
> Subject: Re: [undertow-dev] Overriding Authentication Mechanism for the deployment
>
> That maps to the login-config element in web.xml. I was just thinking
> about how we could allow this to configure custom authenticators. A
> class name by itself is not enough, as you need some way of
> configuring
> the authenticator.
>
> 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>
>
> Thoughts?
>
> Stuart
>
>
> Anil Saldhana wrote:
>> Also another location is Undertow->LoginConfig class probably we
>> need the same flexibility.
>> I did see a TODO there.
>>
>> On May 13, 2013, at 6:13 PM, Stuart Douglas<sdouglas(a)redhat.com>
>> wrote:
>>
>>> I changed this to the DeploymentInfo level, and also made it a
>>> list to
>>> allow multiple custom authentication mechanisms to be used in the
>>> same
>>> deployment.
>>>
>>> Stuart
>>>
>>> Anil Saldhana wrote:
>>>> Hi Stuart/Darran,
>>>> I sent in a PR
>>>>
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
>>>> to override the authentication mechanism used for a particular
>>>> web app
>>>> irrespective of what is configured in web.xml login config
>>>>
>>>> I need this behavior to introduce saml workflow into a web app.
>>>>
>>>> I put the API change at the DeploymentManagerImpl level. If you
>>>> have a
>>>> better alternative, I would like to hear.
>>>>
>>>> Regards,
>>>> Anil
>>>> _______________________________________________
>>>> 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
>
_______________________________________________
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
3:05 a.m.
New subject: Overriding Authentication Mechanism for the deployment
On 5/13/2013 9:02 PM, Bill Burke wrote:
Maybe have something more sophisticated?
more == less, sorry
Couldn't you just configure these custom application-provided
security
providers through context parameters?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:24 a.m.
New subject: Overriding Authentication Mechanism for the deployment
You could do something like that, however you would still need a factory
class that took the ServletContext as a parameter as Authenticators by
themselves have no direct way of getting access to the servlet context.
This is because the AuthenticationMechanism is part of Undertow core,
which as no servlet dependency (a big reason for this split is that we
don't want any servlet dependency in the EAP management console, but we
do need full authentication support).
So if we need the factory anyway my personal preference would be to make
it accept its configuration parameters in the same place it is defined,
so it is obvious how it is configured.
Stuart
Bill Burke wrote:
On 5/13/2013 9:02 PM, Bill Burke wrote:
> Maybe have something more sophisticated?
>
more == less, sorry
> Couldn't you just configure these custom application-provided security
> providers through context parameters?
>
3:34 a.m.
New subject: Overriding Authentication Mechanism for the deployment
Another thing to consider is that if we use a factory based approach we
could also give the factory the ability to register additional handlers
as part of the bootstrap process. This could be useful for things like
your OAuth integration, where you need to register handlers for specific
URL's.
Stuart
Bill Burke wrote:
Maybe have something more sophisticated?
Couldn't you just configure these custom application-provided security
providers through context parameters?
On 5/13/2013 8:26 PM, Andrig Miller wrote:
> One thing we have been attempting to do, is not have any class names show up in
configuration, also an Andiamo tenant.
>
> We had some of this with XNIO/Remoting for awhile, but there were all removed, after
I discovered it. I'm not sure what the implementation approach was to keep from
exposing the internal class names in the configuration, but I am pretty sure Brian knows
what the approach has been.
>
> Of course, in this case, you are talking about a user supplied implementation, so
I'm not sure this is avoidable, or even applicable, but I thought I would mention it.
>
> Andy
>
> ----- Original Message -----
>> From: "Stuart Douglas"<sdouglas(a)redhat.com>
>> To: "Anil Saldhana"<asaldhan(a)redhat.com>
>> Cc: undertow-dev(a)lists.jboss.org
>> Sent: Monday, May 13, 2013 5:29:29 PM
>> Subject: Re: [undertow-dev] Overriding Authentication Mechanism
for the deployment
>>
>> That maps to the login-config element in web.xml. I was just thinking
>> about how we could allow this to configure custom authenticators. A
>> class name by itself is not enough, as you need some way of
>> configuring
>> the authenticator.
>>
>> 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>
>>
>> Thoughts?
>>
>> Stuart
>>
>>
>> Anil Saldhana wrote:
>>> Also another location is Undertow->LoginConfig class probably we
>>> need the same flexibility.
>>> I did see a TODO there.
>>>
>>> On May 13, 2013, at 6:13 PM, Stuart Douglas<sdouglas(a)redhat.com>
>>> wrote:
>>>
>>>> I changed this to the DeploymentInfo level, and also made it a
>>>> list to
>>>> allow multiple custom authentication mechanisms to be used in the
>>>> same
>>>> deployment.
>>>>
>>>> Stuart
>>>>
>>>> Anil Saldhana wrote:
>>>>> Hi Stuart/Darran,
>>>>> I sent in a PR
>>>>>
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
>>>>> to override the authentication mechanism used for a particular
>>>>> web app
>>>>> irrespective of what is configured in web.xml login config
>>>>>
>>>>> I need this behavior to introduce saml workflow into a web app.
>>>>>
>>>>> I put the API change at the DeploymentManagerImpl level. If you
>>>>> have a
>>>>> better alternative, I would like to hear.
>>>>>
>>>>> Regards,
>>>>> Anil
>>>>> _______________________________________________
>>>>> 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
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
1:40 p.m.
New subject: Overriding Authentication Mechanism for the deployment
I like the idea of a factory. Pretty much the same thing as the Feature
component in JAX-RS. It should also though be passed in a "resource"
classloader so it can load config files from the deployment.
I really need to fool around with this stuff instead of just throwing
shit in the wind here...
On 5/13/2013 9:34 PM, Stuart Douglas wrote:
Another thing to consider is that if we use a factory based approach
we
could also give the factory the ability to register additional handlers
as part of the bootstrap process. This could be useful for things like
your OAuth integration, where you need to register handlers for specific
URL's.
Stuart
Bill Burke wrote:
> Maybe have something more sophisticated?
>
> Couldn't you just configure these custom application-provided security
> providers through context parameters?
>
>
> On 5/13/2013 8:26 PM, Andrig Miller wrote:
>> One thing we have been attempting to do, is not have any class names
>> show up in configuration, also an Andiamo tenant.
>>
>> We had some of this with XNIO/Remoting for awhile, but there were all
>> removed, after I discovered it. I'm not sure what the implementation
>> approach was to keep from exposing the internal class names in the
>> configuration, but I am pretty sure Brian knows what the approach has
>> been.
>>
>> Of course, in this case, you are talking about a user supplied
>> implementation, so I'm not sure this is avoidable, or even
>> applicable, but I thought I would mention it.
>>
>> Andy
>>
>> ----- Original Message -----
>>> From: "Stuart Douglas"<sdouglas(a)redhat.com>
>>> To: "Anil Saldhana"<asaldhan(a)redhat.com>
>>> Cc: undertow-dev(a)lists.jboss.org
>>> Sent: Monday, May 13, 2013 5:29:29 PM
>>> Subject: Re: [undertow-dev] Overriding Authentication Mechanism
>>> for the deployment
>>>
>>> That maps to the login-config element in web.xml. I was just thinking
>>> about how we could allow this to configure custom authenticators. A
>>> class name by itself is not enough, as you need some way of
>>> configuring
>>> the authenticator.
>>>
>>> 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>
>>>
>>>
>>> Thoughts?
>>>
>>> Stuart
>>>
>>>
>>> Anil Saldhana wrote:
>>>> Also another location is Undertow->LoginConfig class probably we
>>>> need the same flexibility.
>>>> I did see a TODO there.
>>>>
>>>> On May 13, 2013, at 6:13 PM, Stuart Douglas<sdouglas(a)redhat.com>
>>>> wrote:
>>>>
>>>>> I changed this to the DeploymentInfo level, and also made it a
>>>>> list to
>>>>> allow multiple custom authentication mechanisms to be used in the
>>>>> same
>>>>> deployment.
>>>>>
>>>>> Stuart
>>>>>
>>>>> Anil Saldhana wrote:
>>>>>> Hi Stuart/Darran,
>>>>>> I sent in a PR
>>>>>>
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
>>>>>>
>>>>>> to override the authentication mechanism used for a particular
>>>>>> web app
>>>>>> irrespective of what is configured in web.xml login config
>>>>>>
>>>>>> I need this behavior to introduce saml workflow into a web app.
>>>>>>
>>>>>> I put the API change at the DeploymentManagerImpl level. If you
>>>>>> have a
>>>>>> better alternative, I would like to hear.
>>>>>>
>>>>>> Regards,
>>>>>> Anil
>>>>>> _______________________________________________
>>>>>> 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
>>>
>> _______________________________________________
>> 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:07 p.m.
New subject: Overriding Authentication Mechanism for the deployment
Stuart,
from experience, rough estimate for users wanting to customize auth
mechanisms (authenticators from TC lingo).
Of the users who want to customize authentication mechanisms for SAML
Scenario 1:: Webapp level: 10%
Scenario 2:: Apply custom auth scheme to a selected set of web apps
(configure outside the webapp at the AS level irrespective of what
login-config set up in web.xml): 60%
Scenario 3:: Apply custom auth scheme to all the web apps running in AS: 30%
Scenario 2 is typically when the AS is managed by administrators who
configure security. The webapps may be provided by various teams. Admin
type webapps will then be customized at the web app level to override
the global custom auth scheme.
Given this, I am not sure if we really want to muck inside the web.xml
login-config/auth-method. IMO it is very few users who really want to
apply at the webapp level.
Ideally we need to enable customizing the auth mechs at the wildfly/web
configuration level. So Undertow ->deploymentinfo/overrideAuthMech
should suffice.
Regards,
Anil
On 05/13/2013 06:29 PM, Stuart Douglas wrote:
That maps to the login-config element in web.xml. I was just
thinking
about how we could allow this to configure custom authenticators. A
class name by itself is not enough, as you need some way of configuring
the authenticator.
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>
Thoughts?
Stuart
Anil Saldhana wrote:
> Also another location is Undertow->LoginConfig class probably we need the same
flexibility.
> I did see a TODO there.
>
> On May 13, 2013, at 6:13 PM, Stuart Douglas<sdouglas(a)redhat.com> wrote:
>
>> I changed this to the DeploymentInfo level, and also made it a list to
>> allow multiple custom authentication mechanisms to be used in the same
>> deployment.
>>
>> Stuart
>>
>> Anil Saldhana wrote:
>>> Hi Stuart/Darran,
>>> I sent in a PR
>>>
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
>>> to override the authentication mechanism used for a particular web app
>>> irrespective of what is configured in web.xml login config
>>>
>>> I need this behavior to introduce saml workflow into a web app.
>>>
>>> I put the API change at the DeploymentManagerImpl level. If you have a
>>> better alternative, I would like to hear.
>>>
>>> Regards,
>>> Anil
7:38 p.m.
I see this thread has a few replies but don't forget the thread I
already started with a proposed approach for overriding the
authentication mechanisms by providing additional configuration in the
undertow subsystem.
That also covered the scenario of allowing a single war to be deployed
in multiple environments with different security mechanisms being used
in the different environment.
Regards,
Darran Lofthouse.
On 13/05/13 21:59, Anil Saldhana wrote:
Hi Stuart/Darran,
I sent in a PR
(https://github.com/anilsaldhana/undertow/commit/70838540d01c821973b38f530...)
to override the authentication mechanism used for a particular web app
irrespective of what is configured in web.xml login config
I need this behavior to introduce saml workflow into a web app.
I put the API change at the DeploymentManagerImpl level. If you have a
better alternative, I would like to hear.
Regards,
Anil
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
3977
days inactive
3994
days old
13 comments
6 participants
participants (6)
-
Andrig Miller -
Anil Saldhana -
Anil Saldhana -
Bill Burke -
Darran Lofthouse -
Stuart Douglas