OIDFEDOP
Overview
This plugin provides OpenID Federation (OIDFED) compliant automatic and explicit registration functionality to the OIDC OP plugin.
This plugin is under construction and all the features are still subject to change.
Plugin Installation
The current (work in progress) version of the plugin requires the latest snapshot of OpenID Federation Common Library and OpenID Connect OP Plugin to be installed, together with their dependencies (OpenID Connect Common Library and OpenID Connect Common Config). The most convenient way to find the links to the latest snapshots is via Shibboleth IdP and Plugins status page. It contains a Current Snapshot column that contains link to the corresponding plugin.
The snapshot distribution package is signed with the Shibboleth Jenkins' key. To use that key as the truststore, download it from https://shibboleth.net/downloads/SHIBBOLETH_SNAPSHOT_PGP_KEYS.
Installation example
cd /opt/shibboleth-idp
wget https://shibboleth.net/downloads/SHIBBOLETH_SNAPSHOT_PGP_KEYS
sh bin/plugin.sh --noCheck --truststore SHIBBOLETH_SNAPSHOT_PGP_KEYS -i https://build.shibboleth.net/maven/snapshots/net/shibboleth/oidc/oidc-common-dist/3.4.0-SNAPSHOT/oidc-common-dist-3.4.0-20260902.012051-250.tar.gz
sh bin/plugin.sh --noCheck --truststore SHIBBOLETH_SNAPSHOT_PGP_KEYS -i https://build.shibboleth.net/maven/snapshots/net/shibboleth/idp/plugin/config/oidc/idp-plugin-oidc-config-dist/3.1.0-SNAPSHOT/idp-plugin-oidc-config-dist-3.1.0-20260902.133837-145.tar.gz
sh bin/plugin.sh --noCheck --truststore SHIBBOLETH_SNAPSHOT_PGP_KEYS -i https://build.shibboleth.net/maven/snapshots/net/shibboleth/oidfed/oidfed-common-dist/1.0.0-SNAPSHOT/oidfed-common-dist-1.0.0-20260901.134726-5.tar.gz
sh bin/plugin.sh --noCheck --truststore SHIBBOLETH_SNAPSHOT_PGP_KEYS -i https://build.shibboleth.net/maven/snapshots/net/shibboleth/idp/plugin/oidc/idp-plugin-oidc-op-distribution/4.4.0-SNAPSHOT/idp-plugin-oidc-op-distribution-4.4.0-20260902.133942-405.tar.gz
sh bin/plugin.sh --noCheck --truststore SHIBBOLETH_SNAPSHOT_PGP_KEYS -i https://build.shibboleth.net/maven/snapshots/net/shibboleth/idp/plugin/oidfed/idp-plugin-oidfed-op-dist/1.0.0-SNAPSHOT/idp-plugin-oidfed-op-dist-1.0.0-20260915.111009-355.tar.gzConfiguration overview
The distribution package deploys the following files into conf/oidfed directory:
oidfed-op.properties - configuration properties related to OpenID Federation plugin for OP
The following subsections describe the minimum required configuration for the features to operate. All available configuration settings are included in their respective subpages.
Prerequisites
Configure entity statement and trust anchors by following the instructions at OIDFEDCommon and its subpages.
Automatic registration
Profile configuration
Enable OIDFED.AutomaticRegistration for shibboleth.DefaultRelyingParty in conf/relying-party.xml
...
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
<property name="profileConfigurations">
<list>
...
<bean parent="OIDFED.AutomaticRegistration" />
</list>
</property>
</bean>
...Enable automatically registered RP access per endpoint
The access may be controlled with the Predicate<ProfileRequestContext> beans, configurable with the following endpoint-specific properties in conf/oidfed/oidfed-op.properties:
idp.oidfed.op.automaticRegistration.activationCondition.authorize: condition for the authorize endpoint
idp.oidfed.op.automaticRegistration.activationCondition.token: condition for the token endpoint
idp.oidfed.op.automaticRegistration.activationCondition.par: condition for the PAR endpoint
idp.oidfed.op.automaticRegistration.activationCondition.userinfo: condition for the UserInfo endpoint
They all default to shibboleth.Conditions.FALSE. The example below enables the automatic registration to three endpoints (authorize, token and UserInfo):
idp.oidfed.op.automaticRegistration.activationCondition.authorize = shibboleth.Conditions.TRUE
idp.oidfed.op.automaticRegistration.activationCondition.token = shibboleth.Conditions.TRUE
idp.oidfed.op.automaticRegistration.activationCondition.userinfo = shibboleth.Conditions.TRUETrust chain resolution method
By default, all the valid trust chains for the incoming RP are resolved locally. The valid trust anchors are configured as described in section OIDFEDCommon.
The following properties may be used for wiring a Predicate<ProfileRequestContext> bean for activating remote trust chain resolution and possibly fallback into local resolution:
idp.oidfed.op.automaticRegistration.trustchain.resolver.useResolverApiCondition
idp.oidfed.op.automaticRegistration.trustchain.resolver.fallbackToLocalCondition
Explicit registration
Profile configuration
Enable OIDFED.ExplicitRegistration for shibboleth.DefaultRelyingParty in conf/relying-party.xml
...
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
<property name="profileConfigurations">
<list>
...
<bean parent="OIDFED.ExplicitRegistration" />
</list>
</property>
</bean>
...Trust chain resolution method
By default, all the valid trust chains for the incoming RP are resolved locally. The valid trust anchors are configured as described in section OIDFEDCommon.
The following properties may be used for wiring a Predicate<ProfileRequestContext> bean for activating remote trust chain resolution and possibly fallback into local resolution:
idp.oidfed.op.explicitRegistration.trustchain.resolver.useResolverApiCondition
idp.oidfed.op.explicitRegistration.trustchain.resolver.fallbackToLocalCondition
Storage
Similarly to the OIDC dynamic client registration, the explicit registration implementation relies on a StorageService for storing the registered client information. The in-memory and JPA options have been tested. Expired client information is automatically pruned.
Obviously the simple in-memory service is only sufficient for testing, and the only real option designed for durable persistence is the JPA variant using a database.
The desired storage service bean can be set with the idp.oidfed.op.explicitRegistration.clientInformationManager property in conf/oidfed/oidfed-op.properties. Also note that the deployer must configure a StorageServiceClientInformationResolver exploiting that same service to allow the information to be accessed when requests are handled.
Remote trust chain resolution endpoints
If the condition for using remote resolver entity API returns true for the incoming client, by default the configuration in the conf/oidfed/oidfed-trustchain-resolver.xml -file is exploited.
...
<bean id="shibboleth.oidfed.DefaultTrustedRemoteResolverEntitiesLookupStrategy" parent="shibboleth.Functions.Constant">
<constructor-arg name="target">
<util:list value-type="net.shibboleth.idp.plugin.oidc.op.oidfed.profile.TrustedRemoteResolverEntity">
<bean parent="shibboleth.oidfed.TrustedRemoteResolverEntity"
c:entity="https://trust-anchor.federation.local"
c:anchors="https://trust-anchor.federation.local,https://another.federation.local" />
</util:list>
</constructor-arg>
</bean>
...The example above configures an entity https://trust-anchor.federation.local to be trusted for remote resolution. Its federation_resolve_endpointis automatically fetched and used as the endpoint together with the two trust_anchors parameters as specified by the c:anchors value. It could also contain a single value. Multiple values are separated by commas. Only the trust anchors that are locally trusted are used: others are filtered out.