[undertow-dev] Authentication Mechanism Configuration

[Darran Lofthouse]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>