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