Skip to content

DynamicClientRegistration

Jump to bottom
Scott Cantor edited this page Feb 12, 2021 · 17 revisions

Current File(s): conf/relying-party.xml, conf/idp-oidc.properties

Format: Native Spring

Overview

The OIDC.Registration profile configuration bean enables support for the OpenID Connect Dynamic Client Registration 1.0. Currently the clients (relying parties) cannot be authenticated during the protocol sequence, so the only way to exploit this profile is through shibboleth.UnverifiedRelyingParty, see RelyingPartyConfiguration.

Profile configuration

In addition to the options defined for CommonOIDCProfileConfiguration, the following configuration options can be used for the profile configuration:

  • securityConfiguration: An object containing all of the default security-related objects. Currently only client ID generation (through Security Configuration’s idGenerator -property). Default: reference to shibboleth.oidc.DefaultSecurityConfiguration.
  • registrationValidityPeriod: The period how long the dynamic registration should stay valid. Default PT24H, can be configured with idp.oidc.dynreg.defaultRegistrationValidity -property in conf/idp.properties.
  • secretExpirationPeriod: The period how long the client secret is valid. Default P12M, can be configured with idp.oidc.dynreg.defaultSecretExpiration -property in conf/idp.properties.

Activation

The following example enables this profile for clients to access it in this server's /idp/profile/oidc/register -endpoint. This example must be applied in the conf/relying-party.xml.

<bean id="shibboleth.UnverifiedRelyingParty" parent="RelyingParty">
    <property name="profileConfigurations">
        <list>
            ...
            <bean parent="OIDC.Registration" />
            ...
        </list>
    </property>
</bean>

Storage configuration

The dynamic client registration implementation exploits a StorageService for storing the dynamically registered clients. The interoperability has been verified with shibboleth.StorageService (in-memory) and shibboleth.JPAStorageService (RDBMS, default). The expired client informations are automatically cleaned from the storage.

The desired storage service can be configured with the option idp.oidc.dynreg.StorageService in conf/idp.properties. Also note that the deployer must configure a StorageServiceClientInformationResolver exploiting the same storage service where the dynamically registered clients are stored.

Messaging

The following standard metadata values are currently supported:

  • redirect_uris: Must be defined in the request.
  • response_types: code by default if not defined in the request.
  • grant_types: authorization_code, implicit and refresh_token.
  • application_type:
  • contacts:
  • subject_type: The default value can be configured with property idp.oidc.dynreg.defaultSubjectType in conf/idp.properties.
  • jwks and jwks_uri:
  • token_endpoint_auth_method:
  • logo_uri:
  • policy_uri:
  • tos_uri:

In addition to the standard values, the following is supported.

  • scope: If present, all the requested scopes are added to the stored client metadata. If not present, then the default scope set is stored. The default scope (space-separated list of values, e.g. "openid info") can be configured with property idp.oidc.dynreg.defaultScope in conf/idp-oidc.properties.

All the other (standard or not) values in the request messages are currently ignored. The response message contains all the values that were stored by the OP during the sequence.

(Migrated)

Clone this wiki locally