Page Comparison

Overview

The OIDC OP plugin is the successor to the original GEANT-funded add-on to Shibboleth and is now available as an offically-supported plugin for IdP V4.1 and above. It provides conformant OIDC OP functionality alongside the SAML and CAS support previously native to the IdP software.

Plugin Installation

...

...

For a detailed guide on configuring modules, see the ModuleConfiguration topic. Once the plugin has been installed, its module should be enabled automatically for you:

Check Module Is Enabled

/%{idp.home}/bin$ ./module.sh -l

...
Module: idp.oidc.OP [ENABLED]

However, if you need to enable it you can using the module command:

Enable the module

/%{idp.home}/bin$ ./module.sh -e idp.oidc.OP

...

The impact of this is to reduce the need for <AttributeDefinition> and <AttributeEncoder> elements in your Attribute Resolver configuration when adhering to "default" expectations for the names of attributes and how they map into OIDC claims. We encourage this as it makes things simpler and more consistent but it isn't mandatory.

The additional files created in conf/examples (oidc-attribute-resolver.xml and oidc-attribute-filter.xml) are intended as a source of examples to copy into your own files. The most critical definitions needed are the rules for creating and releasing the "sub" claim, as that as a required OIDC feature (see 2687696897 OIDC OP#ClaimSetup). If you want to use them directly (unlikely), you can copy them elsewhere and make us of them as you see fit.

...

The default configuration expects to have two RSA keys (one for signing and one for decryption), and one EC key. They are expected to be in locations defined via the following properties (with the shipping defaults shown):

• idp.signing.oidc.rs.key - %{idp.home}/credentials/idp-signing-rs.jwk

• idp.signing.oidc.es.key -%{idp.home}/credentials/idp-signing-es.jwk

• idp.signing.oidc.rsa.enc.key - %{idp.home}/credentials/idp-encryption-rsa.jwk

Keys may be generated using the provided wrapper in bin/jwtgen.sh and bin/jwtgen.bat:

Key Generation Example

$ cd /opt/shibboleth-idp
$ bin/jwtgen.sh -t RSA -s 2048 -u sig -i defaultRSASign | tail -n +2 > credentials/idp-signing-rs.jwk
$ bin/jwtgen.sh	-t EC -c P-256 -u sig -i defaultECSign | tail -n +2 > credentials/idp-signing-es.jwk
$ bin/jwtgen.sh	-t RSA -s 2048 -u enc -i defaultRSAEnc | tail -n +2 > credentials/idp-encryption-rsa.jwk

OIDC Issuer and Discovery

The OIDC "issuer" value needs to be determined, and the OpenID discovery document needs to be made accessiible.

The issuer value is set in conf/oidc.properties and must be a URL using the "https" scheme that contains host, and optionally, port number and path components and no query or fragment components. It must resolve to the deployment in question. As a result, while it may be the same as one's SAML entityID, it often cannot be, as SAML does not conflate identity and location in this fashion.

...

...

conf/oidc.properties

idp.oidc.issuer = https://your.issuer.example.org

...

For the RP to locate the file you will either have to:

• Configure your Java container or other web server "front-end" to publish it at this exact location (obviously the prefix depends on your issuer value):

https://your.issuer.example.org/.well-known/openid-configuration

• Or (more typically), configure that location to route into your IdP at "/idp/profile/oidc/discovery" to generate the document more dynamically.

The OPDiscovery topic describes this further.

...

Activating support for OIDC, as with other protocols supported, requires adjusting the RelyingPartyConfiguration in conf/relying-party.xml.

One of the profiles (the one that advertises keys) needs to be openly accessible:

...

...

conf/relying-party.xml

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

The rest are functional profiles that may be enabled more selectively but would normally be enabled by default:

...

conf/relying-party.xml

<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
	<property name="profileConfigurations">
		<list>
			<ref bean="OIDC.SSO" />
			<ref bean="OIDC.UserInfo"/>
			<ref bean="OAUTH2.Revocation"/>
			<ref bean="OAUTH2.Introspection" />
		</list>
	</property>
</bean>

...

There are some commented options in conf/oidc-clientinfo-resolvers.xml that can be uncommented to supply an example JSON file to load:

...

...

conf/oidc-clientinfo-resolvers.xml

    <util:list id="shibboleth.oidc.ClientInformationResolvers">
		<!-- Uncommented -->
        <ref bean="ExampleFileResolver" />

        <ref bean="ExampleStorageClientInformationResolver" />
    </util:list>

    <!-- Uncommented -->
    <bean id="ExampleFileResolver" parent="shibboleth.oidc.FilesystemClientInformationResolver"
        c:metadata="%{idp.home}/metadata/oidc-client.json" />

This in turn allows you to statically define a JSON array of client registrations in a file:

...

metadata/oidc-client.json

[
  {
    "scope":"openid email",
    "redirect_uris":["https://demorp.example.org/redirect_uri"],
    "client_id":"demo_rp",
    "client_secret":"topsecret",
    "response_types":["code"],
    "grant_types":["authorization_code"]
  }
]

...

Please refer to the topics below for more detailed information on different aspects of the extension.

• Client Registration (Metadata and Dynamic)

• Client Resolution

• Authentication

• Attribute/Claims Resolution

  • The "sub" Claim

• Attribute Filtering

• Security Configuration

• Profile Configuration

• OP Discovery