{"type":"doc","content":[{"type":"extension","attrs":{"layout":"default","extensionType":"com.atlassian.confluence.macro.core","extensionKey":"toc","parameters":{"macroParams":{"maxLevel":{"value":"3"}},"macroMetadata":{"macroId":{"value":"8bce1fa0-f505-4012-8931-43acdd495513"},"schemaVersion":{"value":"1"},"title":"Table of Contents"}},"localId":"94ff9955-fac8-43dc-891c-45c94a270af0"}},{"type":"heading","attrs":{"level":2},"content":[{"text":"Overview","type":"text"}]},{"type":"paragraph","content":[{"text":"There are two general ways to register and manage OIDC \"clients\" (RPs), with metadata and ","type":"text"},{"text":"dynamically","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879077"}}]},{"text":". Metadata-based registration is analagous to the way CAS and SAML are supported in the IdP, through metadata resolution to files or online sources. It's not necessarily static since there are many ways of obtaining metadata (e.g., the process could be offloaded to some other system entirely but with output compatible with one of the supported formats).","type":"text"}]},{"type":"paragraph","content":[{"text":"A \"native\" JSON format is supported, as well as a ","type":"text"},{"text":"profile","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/SC/pages/1912406916"}}]},{"text":" of SAML metadata. The former is obviously more concise, but the latter is advantageous because it supports signing by third parties, and because of the myriad configuration features that rely on the use of SAML metadata, and its extensions, and for consistency with the rest of the supported protocols. There are also more advanced metadata loading options using the SAML format, such as the ","type":"text"},{"text":"LocalDynamicMetadataProvider","type":"text","marks":[{"type":"link","attrs":{"href":"https://wiki.shibboleth.net/confluence/display/IDP4/LocalDynamicMetadataProvider"}}]},{"text":" or ","type":"text"},{"text":"DynamicHTTPMetadataProvider","type":"text","marks":[{"type":"link","attrs":{"href":"https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider"}}]},{"text":" approaches.","type":"text"}]},{"type":"paragraph","content":[{"text":"For further information on configuring support for resolving this information, see ","type":"text"},{"text":"OPClientResolution","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879144"}}]},{"text":".","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Avoiding Registration","type":"text"},{"text":" 3.1","type":"text","marks":[{"type":"subsup","attrs":{"type":"sup"}}]}]},{"type":"paragraph","content":[{"text":"As of V3.1, not every feature actually requires registration and management of clients. While the support for this with SAML or CAS is not heavily used, the IdP has always allowed for so-called “unverified” or (in very old versions, “anonymous”) relying party configuration, whereby profiles may be enabled for systems that are not found in metadata. This support is currently not universal within the OP feature set, but is expected to expand going forward because of the fact that OIDC and OAuth typically rely on back-channel communication to the OP with authentication methods that don’t necessarily require metadata.","type":"text"}]},{"type":"paragraph","content":[{"text":"Because of this additional authentication requirement, it may be desirable to operate (within an enterprise at least) with a more default profile configuration that extends to any clients issued credentials by some general management approach, such as service accounts managed within an IDM solution. Issuing service accounts may be more lightweight for many organizations than capturing details for creation of client metadata.","type":"text"}]},{"type":"paragraph","content":[{"text":"With V3.1, the following features are meant to operate successfully in the absence of client metadata, provided the relevant profiles are enabled for unverified relying party use:","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"OAuth 2 Client Credentials grant support on the Token endpoint (","type":"text"},{"text":"OAUTH2.Token","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/2931327005"}}]},{"text":" and ","type":"text"},{"text":"OAUTH2.TokenAudience","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/2931425281"}}]},{"text":")","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"OAuth 2 Introspection (","type":"text"},{"text":"OAUTH2.Introspection","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879310"}}]},{"text":")","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"OAuth 2 Revocation (","type":"text"},{"text":"OAUTH2.Revocation","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879313"}}]},{"text":")","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"These profiles all support client authentication, and this can be used in lieu of actually registering metadata for clients if desired.","type":"text"}]},{"type":"paragraph","content":[{"text":"As of V4.0, all the previously mentioned profiles but also ","type":"text"},{"text":"OIDC.SSO","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879266"}}]},{"text":" and ","type":"text"},{"text":"OIDC.UserInfo","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879306"}}]},{"text":" can be used with unverified relying party configuration, but all the request messages must meet the ","type":"text"},{"text":"unregistered client policy","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3274833948"}}]},{"text":".","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"JSON Format","type":"text"}]},{"type":"paragraph","content":[{"text":"Each RP is defined with a JSON structure that is defined by the ","type":"text"},{"text":"OpenID Connect Dynamic Client Registration 1.0","type":"text","marks":[{"type":"link","attrs":{"href":"https://openid.net/specs/openid-connect-registration-1_0.html"}}]},{"text":" specification. That is, the format is just the format of the messages in that protocol. The required fields are:","type":"text"}]},{"type":"table","attrs":{"layout":"default","width":1800.0,"localId":"a20acac3-35f5-450a-9589-7882eea26650"},"content":[{"type":"tableRow","content":[{"type":"tableHeader","attrs":{"colspan":1,"rowspan":1,"colwidth":[156.0]},"content":[{"type":"paragraph","content":[{"text":"Name","type":"text"}]}]},{"type":"tableHeader","attrs":{"colspan":1,"rowspan":1,"colwidth":[146.0]},"content":[{"type":"paragraph","content":[{"text":"Type","type":"text"}]}]},{"type":"tableHeader","attrs":{"colspan":1,"rowspan":1,"colwidth":[458.0]},"content":[{"type":"paragraph","content":[{"text":"Description","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[156.0]},"content":[{"type":"paragraph","content":[{"text":"client_id","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[146.0]},"content":[{"type":"paragraph","content":[{"text":"string","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[458.0]},"content":[{"type":"paragraph","content":[{"text":"OIDC client identifier for the RP","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[156.0]},"content":[{"type":"paragraph","content":[{"text":"response_types","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[146.0]},"content":[{"type":"paragraph","content":[{"text":"array of strings","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[458.0]},"content":[{"type":"paragraph","content":[{"text":"Accepted client response types","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[156.0]},"content":[{"type":"paragraph","content":[{"text":"scope","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[146.0]},"content":[{"type":"paragraph","content":[{"text":"string","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[458.0]},"content":[{"type":"paragraph","content":[{"text":"Known scopes (space-delimited list in one string)","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[156.0]},"content":[{"type":"paragraph","content":[{"text":"redirect_uris","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[146.0]},"content":[{"type":"paragraph","content":[{"text":"array of strings","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[458.0]},"content":[{"type":"paragraph","content":[{"text":"Required redirect response locations for the RP","type":"text"}]}]}]}]},{"type":"paragraph","content":[{"text":"Multiple RPs can be configured in a single file, and must be included in a JSON array.","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Examples","type":"text"}]},{"type":"paragraph","content":[{"text":"An example of a JSON file with minimal settings:","type":"text"}]},{"type":"codeBlock","attrs":{"language":"javascript"},"content":[{"text":"{\n \"client_id\": \"demo_rp\",\n \"response_types\": [\"id_token\"],\n \"scope\": \"openid info profile email address phone\",\n \"redirect_uris\": [\"https://192.168.0.150/static\"]\n}","type":"text"}]},{"type":"paragraph","content":[{"text":"An example with multiple RPs:","type":"text"}]},{"type":"codeBlock","attrs":{"language":"javascript"},"content":[{"text":"[\n\t{\n\t \"client_id\": \"demo_rp\",\n\t \"response_types\": [\"id_token\"],\n\t \"scope\": \"openid info profile email address phone\",\n\t \"redirect_uris\": [\"https://192.168.0.150/static\"]\n\t},\n {\n \"client_id\": \"demo_rp2\",\n \"response_types\": [\"id_token\"],\n \"scope\": \"openid info profile email address phone\",\n \"redirect_uris\": [\"https://192.168.0.150/static2\"]\n }\n]","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"SAML/XML Format","type":"text"}]},{"type":"paragraph","content":[{"text":"The alternative format supported is a profile of SAML metadata described in ","type":"text"},{"text":"OAuthRPMetadataProfile","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/SC/pages/1912406916"}}]},{"text":". This profile makes heavier use of extensions than past adaptations of SAML metadata because of the comparative complexity of OAuth and OIDC relative to simpler protocols that have more similarity to SAML.","type":"text"}]},{"type":"paragraph","content":[{"text":"There are also additional considerations around the way keys are resolved. OIDC typically relies on untrusted leap-of-faith access to remote, unsigned JSON files to acquire frequently-rotated client secrets (i.e. shared/symmetric keys, not longer-lived keypairs), and the use of SAML metadata has to account for that difference. The techniques below are all auto-configured into the system.","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Public Key Resolution","type":"text"}]},{"type":"paragraph","content":[{"text":"Public keys can be resolved in two previously supported ways (","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":" or ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":" elements) and two \"novel\" ways specific to OIDC:","type":"text"}]},{"type":"expand","attrs":{"title":"JSON Web Key Set (JWKS)"},"content":[{"type":"paragraph","content":[{"text":"You can embed a single JSON Web Key or a set of them in a JSON array, encoded into base64, inside a ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":" metadata element. This is just a way of embedding a more \"native\" structure into the metadata into the metadata in the same way that a certificate would be.","type":"text"}]},{"type":"codeBlock","attrs":{"language":"xml"},"content":[{"text":"\n \n mockJwkId\n \n ewogICJrdHkiOiAiUlNBIiwKICAiZSI6ICJBUUFCIiwKICAia2lkIjogIm1vY2siLAogICJhbGci\n OiAiUlMyNTYiLAogICJuIjogInBKcHRScnpyRlhEUnBaWkdpRmc1eW9KeVRPMlphUENSNEcwbjEx\n aUVSclBTdlVYX202Qmdvak5qVEZISk1pa19pbGhtVzY0Q3JLdGlMdklRTFF6VWV5RXdDZHdYZVB3\n UVpNeEV4VDJPV2thQy1DV0ZJNHR4X2VFWGRkUGtja1NMRERhMEVQd3dzWktQUFhoRTNWNTBfZ3pW\n VDJZQVRvRE9fMmoyeGpWcHFzU0dFc0xpYjZqLW52dFpVVV9CMHNHeUppR1ZzMkpUTmhCTVNrT2tR\n Zks2NkNCcW1sbzBuUE5NYVIxbWl2dG5JUG1aNnJKVHcwUDVZZ0dFS1hmZjBsa25Ib25ZVmRsVktw\n c0Q4VW5hY0JzdFlyeUhsM0NQR2Uyc3RmR2ExZ3N6NEdIVGVfRnlWVk04UlNoQ2dYVVo3MTdoenpf\n ekdQaVhDQkw0ZktEek5ZUXpIUSIKfQo=\n\t\t\n\t\n","type":"text"}]},{"type":"paragraph","content":[{"text":"The decoded data above is (single JSON Web Key):","type":"text"}]},{"type":"codeBlock","attrs":{"language":"javascript"},"content":[{"text":"{\n \"kty\": \"RSA\",\n \"e\": \"AQAB\",\n \"kid\": \"mock\",\n \"alg\": \"RS256\",\n \"n\": \"pJptRrzrFXDRpZZGiFg5yoJyTO2ZaPCR4G0n11iERrPSvUX_m6BgojNjTFHJMik_ilhmW64CrKtiLvIQLQzUeyEwCdwXePwQZMxExT2OWkaCCWFI4tx_eEXddPkckSLDDa0EPwwsZKPPXhE3V50_gzVT2YAToDO_2j2xjVpqsSGEsLib6jnvtZUU_B0sGyJiGVs2JTNhBMSkOkQfK66CBqmlo0nPNMaR1mivtnIPmZ6rJTw0P5YgGEKXff0lknHonYVdlVKpsD8UnacBstYryHl3CPGe2stfGa1gsz4GHTe_FyVVM8RShCgXUZ717hzz_zGPiXCBL4fKDzNYQzHQ\"\n}","type":"text"}]}]},{"type":"expand","attrs":{"title":"Remote JWKS"},"content":[{"type":"paragraph","content":[{"text":"You can reference a JWKS (as in the other JWKS example) remotely via a URI. This is analagous to a rarely used (because of security, obviously) technique of remotely referencing certificates.","type":"text"}]},{"type":"codeBlock","attrs":{"language":"xml"},"content":[{"text":"\n \n mockJwkId\n https://example.org/jwks\n\t\n","type":"text"}]}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Client Secret Resolution","type":"text"}]},{"type":"paragraph","content":[{"text":"Client secrets, which are effectively either passwords or symmetric keys, are not something natively understood by SAML metadata, so extensions are defined to support them in one of the following ways.","type":"text"}]},{"type":"expand","attrs":{"title":"By Value"},"content":[{"type":"paragraph","content":[{"text":"You can embed a client secret directly inside a ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":" metadata element. This works well for closely managed systems such as within an enterprise.","type":"text"}]},{"type":"codeBlock","attrs":{"language":"xml"},"content":[{"text":"\n \n verySecretClientSecretKeyValue1234567890\n\t\n","type":"text"}]}]},{"type":"expand","attrs":{"title":"By Reference"},"content":[{"type":"paragraph","content":[{"text":"Support also exists for indirectly referencing client secrets and resolving them at runtime separately. The metadata syntax is simply:","type":"text"}]},{"type":"codeBlock","attrs":{"language":"xml"},"content":[{"text":"\n \n secretReference1\n\t\n","type":"text"}]},{"type":"paragraph","content":[{"text":"The reference string is just a label that has to correspond to some external source.","type":"text"}]},{"type":"paragraph","content":[{"text":"Actually resolving secrets by reference requires one or more resolution beans be supplied in a list named ","type":"text"},{"text":"shibboleth.oidc.ClientSecretValueResolvers","type":"text","marks":[{"type":"strong"}]},{"text":", which does not exist by default.","type":"text"}]},{"type":"paragraph","content":[{"text":"There are two built-in types of resolvers.","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Property-Based Resolution","type":"text"}]},{"type":"paragraph","content":[{"text":"Client secrets can be placed in a Java properties file (the keys are the labels used in the metadata reference and the values are the secrets). You can supply any number of such sources in the resolver list, generally in ","type":"text"},{"text":"conf/global.xml","type":"text","marks":[{"type":"em"}]},{"text":". Each source is defined using a parent bean named ","type":"text"},{"text":"shibboleth.oidc.PropertiesClientSecretValueResolver","type":"text","marks":[{"type":"strong"}]},{"text":":","type":"text"}]},{"type":"codeBlock","content":[{"text":"\n\t\n","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Attribute Resolver Resolution","type":"text"}]},{"type":"paragraph","content":[{"text":"A \"generic\" solution to resolving secrets is provided by means of leveraging the ","type":"text"},{"text":"AttributeResolver","type":"text","marks":[{"type":"link","attrs":{"href":"https://wiki.shibboleth.net/confluence/display/IDP4/AttributeResolverConfiguration"}}]},{"text":" to resolve the secret. The parent bean named ","type":"text"},{"text":"shibboleth.oidc.ResolverServiceClientSecretValueResolver","type":"text","marks":[{"type":"strong"}]},{"text":" along with a set of attribute IDs will invoke the resolver and attempt to find a string value amongst them to return. During the resolution process, the \"principal\" variable is populated with the client secret reference label.","type":"text"}]},{"type":"codeBlock","content":[{"text":"\n\t\n","type":"text"}]},{"type":"paragraph","content":[{"text":"To simplify the configuration of the resolver, you may conditionalize connectors by attaching a ","type":"text"},{"text":"resolutionPhases","type":"text","marks":[{"type":"code"}]},{"text":" attribute set to \"ResolverServiceClientSecretValueResolver\", causing them to run only during this special case. You can also set ","type":"text"},{"text":"excludeResolutionPhases","type":"text","marks":[{"type":"code"}]},{"text":" to invert the check for other connectors.","type":"text"}]}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Hashed Secrets","type":"text"},{"text":" 3.1","type":"text","marks":[{"type":"subsup","attrs":{"type":"sup"}}]}]},{"type":"paragraph","content":[{"text":"If a secret value is prefixed by “{SHA2}”, then the supplied secret is hashed (with SHA-256) and base64-encoded before comparing it to the rest of the secret string. This is an unsalted hash so is not really suitable for exposing to offline attacks but is at least obsfuscated.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Reference","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Beans","type":"text"}]},{"type":"table","attrs":{"layout":"full-width","width":1800.0,"localId":"fc93ee56-3fd7-467a-b859-cf3372399dc1"},"content":[{"type":"tableRow","content":[{"type":"tableHeader","attrs":{"colspan":1,"rowspan":1,"colwidth":[686.0]},"content":[{"type":"paragraph","content":[{"text":"Name / Type","type":"text"}]}]},{"type":"tableHeader","attrs":{"colspan":1,"rowspan":1,"colwidth":[795.0]},"content":[{"type":"paragraph","content":[{"text":"Description","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[686.0]},"content":[{"type":"paragraph","content":[{"text":"shibboleth.oidc.ClientSecretValueResolvers","type":"text","marks":[{"type":"strong"}]}]},{"type":"paragraph","content":[{"text":"List","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[795.0]},"content":[{"type":"paragraph","content":[{"text":"List of client secret resolvers to apply to any ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":" elements in SAML metadata","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[686.0]},"content":[{"type":"paragraph","content":[{"text":"shibboleth.oidc.PropertiesClientSecretValueResolver","type":"text","marks":[{"type":"strong"}]}]},{"type":"paragraph","content":[{"text":"net.shibboleth.oidc.metadata.impl.PropertiesClientSecretValueResolver","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[795.0]},"content":[{"type":"paragraph","content":[{"text":"A resolver that looks for secrets in a Java properties file set via the ","type":"text"},{"text":"resource","type":"text","marks":[{"type":"code"}]},{"text":" bean property","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[686.0]},"content":[{"type":"paragraph","content":[{"text":"shibboleth.oidc.ResolverServiceClientSecretValueResolver","type":"text","marks":[{"type":"strong"}]}]},{"type":"paragraph","content":[{"text":"net.shibboleth.oidc.metadata.impl.ResolverServiceClientSecretValueResolver","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[795.0]},"content":[{"type":"paragraph","content":[{"text":"A resolver that executes the AttributeResolver to resolve one or more client secrets via attributes set via the ","type":"text"},{"text":"attributeIds","type":"text","marks":[{"type":"code"}]},{"text":" bean property","type":"text"}]}]}]}]},{"type":"paragraph"}],"version":1}

Browser not supported