[undertow-dev] Overriding Authentication Mechanism for the deployment

Bill Burke bburke at redhat.com
Mon May 13 21:02:30 EDT 2013


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 at redhat.com>
>> To: "Anil Saldhana" <asaldhan at redhat.com>
>> Cc: undertow-dev at 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 at 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/70838540d01c821973b38f530a97be2f54e83c13)
>>>>> 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the undertow-dev mailing list