[undertow-dev] Overriding Authentication Mechanism for the deployment

[Stuart Douglas]

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