OPMetadataPolicies

File(s): conf/relying-party.xml - via file defined in the idp.oidc.dynreg.defaultMetadataPolicyFile -property by default
Format: Native Spring, JSON

1 Overview
2 Configuration
- 2.1 Custom operators 4.1
  - 2.1.1 Custom operator example
3 Policy Examples

Overview

A metadata policy is used to restrict the acceptable content of a dynamic registration request. The concept is defined in the OpenID Connect Federation 1.0 specification (draft 17 at the time of writing this documentation). We support the structure and rules specified in section 5.1 of the specification draft: the three value operators (value, add, default) and the four value checks (one_of, subset_of, superset_of and essential). We also support the regexp (regular expression) value operator.

All the restrictions on policy entries and the rules for combining/merging, applying and enforcing policies are respected as specified. In this use case, the combining/merging is related to metadata policies defined within a registration access token and in the profile configuration.

Since version 4.1, we provide a way to inject custom operators in addition to the set described above. The custom operators are merged in the same way as default, value and regex operators.

Configuration

The metadata policy configuration for a profile can be modified via the metadataPolicyLookupStrategy profile configuration setting. If left empty, the contents of the file path defined in the idp.oidc.dynreg.defaultMetadataPolicyFile property (if specified) will be used.

A custom file path value for a profile can be configured in the following way:

Create a bean (for instance with id custom.AnotherMetadataPolicyLookupStrategy) in the following way:

<bean id="custom.AnotherMetadataPolicyLookupStrategy"
  parent="shibboleth.oidc.dynreg.MetadataPolicyLookupStrategy"
  c:resource="file:/opt/shibboleth-idp/conf/metadata-policy2.json"
  c:id="AnotherProfileMetadataPolicyCache" />

Reference the bean as the metadataPolicyLookupStrategy within the profile configuration in relying-party.xml:

<bean parent="OIDC.Registration"
  p:metadataPolicyLookupStrategy-ref="custom.AnotherMetadataPolicyLookupStrategy"/>

Custom operators ^4.1

Since version 4.1, we provide a way to inject custom operators in addition to the set described above. A new operator bean demonstrates this feature. It can be used for wiring any bean that implements CustomMetadataPolicyOperator for performing the operation.

A new abstract global bean shibboleth.oidc.MetadataPolicyOperator can be used for wiring custom (including scripted/expression) policy operators. The bean contains two properties:

validator: Predicate<MetadataPolicy>
- The predicate should return true or false, depending whether the contents of the given MetadataPolicy are compatible with this custom policy operator.
- defaults to always true (shibboleth.Conditions.TRUE)
valueOperator: BiFunction<Object, MetadataPolicy, Object>
- input1: value candidate
- input2: policy related to the value
- The bi-function should return the value after the operator has been applied or throw net.shibboleth.shared.logic.ConstraintViolationException if the candidate was not accepted.

Custom operator example

The following example demonstrates the idea.

The custom metadata policy operator bean is EchoDemoOperator. Its valueOperator simply echoes back the value candidate (input1). As the validator is not explicitly defined, its default value (shibboleth.Conditions.TRUE) is used.

<bean id="EchoDemoOperator" parent="shibboleth.oidc.MetadataPolicyOperator">
    <property name="valueOperator">
        <bean parent="shibboleth.BiFunctions.Expression" c:expression="#input1">
        </bean>
    </property>   
</bean>

That operator could then be wired to a metadata policy in the following way:

Policy Examples

The following JSON contains an example of a metadata policy:

It should be read as follows:

client_name: default value is A known test application, but it can be overridden in the dynamic client registration request.
organization_name: The value A trusted organization will always be used, no matter what the dynamic client registration request contains for it
redirect_uris: The values must meet the regular expression, i.e. be in https-scheme, the host-part of the URL must end with example.org no custom port can be defined.
id_token_signed_response_alg: The algorithm specified in the request (if exists) must be one of the three RS-algortihms.
scope: The scope in the request (if exists) can contain the four values or a subset of them