Trust Management & OP configuration
Section Topics
- SAML IdP Metadata vs. OpenID Provider Configuration
- OIDC Client Information
- Trust relationship establishment between Shibboleth OP and test RP
SAML IdP Metadata vs. OpenID Provider Configuration
- Example IdP metadata: https://idp.csc.fi/idp/shibboleth
- By default, the contents are fetched from /opt/shibboleth-idp/metadata/idp-metadata.xml
- The file is generated by the installation script and is NOT updated afterwards automatically
- Example federation metadata: https://haka.funet.fi/metadata/haka-metadata.xml
- Signed by the federation operator (trusted 3rd party)
- OpenID Connect Discovery spec - responds to two questions
- How the OP configuration is found?
- https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
- Webfinger protocol exploited for finding out the issuer name from the resource identifier
- URL format: <issuer>/.well-known/openid-configuration
- https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
- What are the contents of the OP configuration?
- How the OP configuration is found?
- Two ways to publish OP configuration in Shibboleth OP: https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/DiscoveryAndOPConfiguration#openid-provider-metadata
- Static file - example found at /opt/shibboleth-idp/static/.well-known/openid-configuration
- Static file with dynamic claims - example found at /opt/shibboleth-idp/flows/oidc/discovery (URL-endpoint ../idp/profile/oidc/discovery)
Exercises
Google OP issuer name is 'https://accounts.google.com'
What is the endpoint URL for the openid-configuration?
Check the contents of Google's openid-configuration
Everybody has a Shibboleth OP instance running on a virtual machine with public IP. The OP issuer name is https://IP_ADDRESS
What is the endpoint URL for the openid-configuration?
What are the contents of the well-known endpoint?
OIDC Client Metadata
Static configuration example from Google:
Dynamic registration:
There's no direct equivalent to SAML SP Metadata (or EntityDescriptor/EntitiesDescriptor) on OIDC
- Similar federation metadata signing logic cannot be directly applied to OIDC
- See OIDC Federation draft
- https://openid.net/specs/openid-connect-federation-1_0.html
- Applies to OP discovery + dynamic client registration phases - different from the SAML R&E model
Trust relationship establishment between Shibboleth OP and test RP
Exercises
- Try OIDC flow with an RP that is not (yet) trusted
The OIDC sequence can be started with https://IP_ADDRESS:8443/protected/ endpoint - You should end up into an error screen at Shibboleth OP. The logs should show that the client is not trusted.
- Statically add an RP as trusted (RP config already done)
Verify that you have the following element in /opt/shibboleth-idp/conf/oidc-metadata-providers.xml
- The element enables loading the OIDC metadata file from the configured location
Add client metadata to the location defined in previous configuration /opt/shibboleth-idp/metadata/oidc-client.json
nano /opt/shibboleth-idp/metadata/oidc-client.json [ { "scope":"openid phone", "redirect_uris":["https://demorp.example.com/redirect_uri"], "client_id":"demo_rp", "client_secret":"topsecret", "response_types":["code"], "grant_types":["authorization_code","implicit","refresh_token"] } ]
Check the RP-side configuration first from /etc/httpd/conf.d/auth_openidc.conf. RP has been preconfigured for these training exercises. Note that pre-configured settings are at the bottom of the file and the file includes a lot of additional settings.
Pick up the settings for client_id, client_secret, redirect_uris and scope from the RP configuration.
Also add "response_types":["id_token","code"] and "grant_types":["authorization_code","implicit","refresh_token"] claims and apply them to /opt/shibboleth-idp/metadata/oidc-client.json. Either replace the existing configuration for client demo_rp, or add an additional configuration, as instructed by the wiki (MetadataConfiguration).
Reload the OIDC client metadata by reloading service shibboleth.ClientInformationResolverService.
Hints, Tips and Result[root@gn43-oidcshibop-devel shibboleth-idp]# /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.ClientInformationResolverService
- You should now get the login screen when starting the login sequence at: https://IP_ADDRESS:8443/protected/. Use username teppo with password testaaja. Check the logs during the login sequence.