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