This design is intended to address the following issues:

KNOX-179@jira: Simple way to introduce new provider/servlet filters into the chains

The basic issues is that the development and delivery of code is currently required to add a new provider into Knox.
This results in a barrier to entry for integrating new providers with Knox.
In particular the integration of an existing servlet filter into Knox should not require code development.
The design below is intended to introduce a very simple configuration based mechanism to accomplish this.
Naturally this will only cover very simple use-cases.
More advanced requirements will still require the development of a ProviderDeploymentContributor.

 

Topology
<topology>
  <gateway>
    <provider>
      <role>authentication</role>
      <name>generic</name>
      <enabled>true</enabled>
      <param>
        <name>filterClassName</name>
        <value>org.opensource.filters.ExistingFilter</value>
      </param>
    </provider>
    ...
  </gateway>
  ...
</topology>
DefaultProviderDeploymentContributor
public class DefaultProviderDeploymentContributor {

  String getRole() {
    return "*"; // The "*" will require special handling in the framework.

  String getName() {
    return "generic";
  }

  void initializeContribution( DeploymentContext context ) {
    // NoOp
  }

  void contributeProvider( DeploymentContext context, Provider provider ) {
    // NoOp
  }

  void contributeFilter(
      DeploymentContext context,
      Provider provider,
      Service service,
      ResourceDescriptor resource,
      List<FilterParamDescriptor> params ) {
    resource.addFilter()
        .name( getName() )
        .role( provider.getRole() )
        .impl( provider.getParams().get( "filterClassName" ) )
        .params( params );
  }

  void finalizeContribution( DeploymentContext context ) {
    // NoOp
  }
}
  • No labels

3 Comments

  1. Larry McCay

    We need to spell out the use of the '*' role and the default name here.

    It seems like you are trying to say that a provider with a returned role as '*' will match anything in the config. This seems to make sense, though I think that the role is probably known for a given provider. It is either authn or authz or whatever.

    It also seems to me that you are hinting that any custom providers would be called default. If this is the case, how do we distinguish them apart from each other?

    I think that we have a couple foundational things now that we need to consider (you probably already have):

    • the roles represent placeholders within the filter chain
    • names distinguish providers of the same role from each other
    • we have no easy way to introduce a custom role (perhaps we need another JIRA for this - a relative role might work: ie. authentication+ could mean after the authentication location appended to the end of other authentication+'s)

    What we are talking about here is the ability to indicate in topology the use of a custom provider for one of the existing roles.

    Can't we use what we have today and just happen to include the filterClassname init param?

    We could also have an optional boolean that indicates that it is custom and that would be how you bind it to the Custom contributor.

    1. Kevin Minder

      First off be aware that this was written in the context of the design for KNOX-177. Beyond that let me try and hit your points.
      1) Yes "*" will match any role. Since this is a generic provider it would inherit the role in the topology.
      2) I'm not saying that custom providers would be called default. We need a name for this specific special provider. I've since changed my opinion about the use of "default" as the name and I'm leaning toward "generic" although "customer" is in the running.
      3a) Roles do represent placeholder in a filter chain.
      3b) Names in general distinguish provider of the same role. However in this "special" case the name of this provider will globally apply to all roles.
      3c) I tried to address this in the design for KNOX-177.
      4) Not necessarily, due to KNOX-177 it should work for any role.
      5) We could but then what does it mean to have a role+name+filterClassName init param? Would all ProviderDeploymentContributors be expected to honor this init param?
      6) I don't think this makes sense given answers provided above.

      1. Kevin Minder

        I also do agree that the algorithm for selecting a provider implemented needs to be more clearly spelled out and documented. We need to get a Developer's Guide started for this type of info. At any rate I don't think that the "generic" provider should ever be considered by the framework when only provider role is specified in <topology><gateway><provider>. This is mainly because there is no reasonable default for the filterClassName init param.