PluginTestbedGuidance

Owned by Former user (Deleted)
Last updated: Jun 19, 2020
3 min read

Status

Under development - this is very rough and not highly generalized ATM.


Guidance for testing plugins using the IdP Testbed 


Add the plugin as a dependency of the testbed by modifying the testbed POM. First, define the version as a property (replace PLUGIN as appropriate):

<idp.plugin.authn.PLUGIN.version>0.0.1-SNAPSHOT</idp.plugin.authn.PLUGIN.version>

Add artifact dependencies as appropriate to the <dependency> section of the POM e.g.

dependency>
            <groupId>net.shibboleth.plugin.authn</groupId>
            <artifactId>idp-PLUGIN-api</artifactId>
            <version>${idp.plugin.authn.PLUGIN.version}</version>
        </dependency>
        <dependency>
            <groupId>net.shibboleth.plugin.authn</groupId>
            <artifactId>idp-PLUGIN-impl</artifactId>
            <version>${idp.plugin.authn.PLUGIN.version}</version>
        </dependency>
        <dependency>
            <groupId>net.shibboleth.plugin.authn</groupId>
            <artifactId>idp-PLUGIN-native-client-impl</artifactId>
            <version>${idp.plugin.authn.PLUGIN.version}</version>
            <scope>runtime</scope>
        </dependency>


All IdP dependencies of the plugin should have a provided scope. This limits the import of transitive dependencies from your plugin to hopefully only those required by the plugin that are not already provided by the IdP. It is worth checking the dependency tree either in Eclipse or Maven to check for dependency pollution (see PluginPOMGuidance). Note, the IdP version the plugin is compiled and tested against may now be different than the runtime version that the testbed provides.

Is there a better way than just adding directly to the testbed main POM e.g. a child POM for 'testing' plugins, import scope POMs, or the sometimes touted but perhaps not available `mixin` POM fragment stuff. Just a clearer way to say, 'test this plugin'.


Registring new flows

Plugin flows should be placed inside the src/main/resources/META-INF/net/shibboleth/idp/flows/ directory of your plugin jar. Such flows in this location are automatically registered into the flow registry by the IdP - see SpringConfiguration for more information - and require no explicit configuration in the testbed/IdP.

Flow IDs are derived relative to the base flows/ directory. So flows/auth/plugin would have an ID of auth/plugin.

Configure the flow


IdP flow configuration should be accomplished using a preconfig.xml and postconfig.xml bean file in the src/main/resources/META-INF/net.shibboleth.idp/ directory of your plugin. These are then loaded either before or after the global-system.xml - preconfig is overridden by global-system and global-system is overridden by postconfig.


Registering new spring Servlets/Controllers

Options may be:

  • Container servlets with annotations e.g. '@WebServlet'. Jetty would need to register these, they will not have access to the spring context for bean injection.
  • Container servlets in the web.xml. They will not have access to the spring context for bean injection.
    • Or a servlet using the DelegatingFilterProxy, which with then allow access to spring context.
  • Spring controllers with annotations e.g. '@Controller'. Spring needs to register these, so they must be in an 'outer' spring configuration file i.e. not inside a spring webflow bean definition file (I think?). It can be used to wire up any spring bean.

A borrowed mechanism (similar to that used for the postconfig in the previous section)  for loading webflow config beans from the classpath seems to work. That is adding the controller config to a src/main/resources/META-INF/net.shibboleth.idp/postwebflow-config.xml. This is picked up by the Spring DispatcherServlet config as part of the idp servlet.