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