cscfi/shibboleth-idp-oidc-extension

OpenID Connect Plugin for Shibboleth Identity Provider

This software implements an OpenID Connect OP extension for Shibboleth Identity Provider V3 and Shibboleth Identity Provider V4. The plugin is distributed in versions for both Shibboleth IdP3 and IdP4.

The initial development work was done as part of GÉANT 4-2 and 4-3 projects and the product was handed over to the Shibboleth consortium in December 2019.

The plugin has been certified in OpenID Foundation's certification program

Downloading

The plugin is distributed as an extension that you can download and add to your Shibboleth Identity Provider installation.

Version 1.x for Shibboleth IdP3 is available from Github releases

Version 2.x for Shibboleth IdP4 is available from Shibboleth download site

Installation and Documentation

Installation and configuration instructions for both versions are available in the Github wiki

Support and Help

The OIDC plugin is supported under the Shibboleth consortium support

Version 1.x will receive only maintenance updates and all future development is for the version 2.x. Version 2.x development is done on Shibboleth Git under java-idp-oidc repository.

shibboleth-idp-oidc-extension's Issues

URL matchmaking for redirect should allow GET parameters

We are testing the OIDC extension with a Django application that uses Python Social for OAuth2 authentication.

We ended in the following log message:

==> logs/idp-warn.log <==
2020-01-06 16:36:04,689 - ERROR [org.geant.idpextension.oidc.profile.impl.ValidateRedirectURI:115] - Profile Action ValidateRedirectURI: Redirection URI http://localhost:8000/social/complete/beuthtest/?redirect_state=o2eOmbd3CL3MG1jKy44t20R94JMv8sFp not matching any of the registered Redirection URIs [http://localhost:8000/social/complete/beuthtest/] 

The source code of ValidateRedirectURI.java looks like there is a match making on the complete URL, even if it contains a query string. This does not seem to be correct.

Order of consent interceptors in postAuthenticationFlows matters

I thought I would share this problem, because it took me quite some time to figure this out.
I tried to add some claims to the id_token, but for some reason those attributes did not end up in the id_token (resolving, filtering, etc) was all fine.

relying-party.xml looked like:

<bean parent="OIDC.SSO" p:postAuthenticationFlows="#{ {'impersonate', 'context-check', 'attribute-release', 'terms-of-use'} }" />

The logs:

DEBUG [org.geant.idpextension.oidc.profile.impl.SetConsentToResponseContext:145] - Profile Action SetConsentToResponseContext: Set to response context consented attributes [] and consentable attributes ["givenName","surname","commonName","email","uid","eduPersonOrgUnitDN"] - 

When I put the terms-of-use interceptor before attribute-release it worked:

DEBUG [org.geant.idpextension.oidc.profile.impl.SetConsentToResponseContext:145] - Profile Action SetConsentToResponseContext: Set to response context consented attributes ["givenName","surname","commonName","email","uid","eduPersonOrgUnitDN"] and consentable attributes ["givenName","surname","commonName","email","uid","eduPersonOrgUnitDN"] - 

and all the attributes with placeToIDToken="true" were present in the id_token.

This is probably due to the fact that both the attribute-release and terms-of-use interceptor are using the same ConsentContext.

Missing return statements in org.geant.idpextension.oidc.profile.impl.ValidateRedirectURI

I believe there are error events being signaled in the execute body that aren't followed by return statements. Eyeballing it, my guess is it NPEs instead of failing as intended.

refresh_token available without going through consent

The OIDC extension will issue refresh tokens w/o the RP specifying prompt=consent

Acc'd to https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess

When offline access is requested, a prompt parameter value of consent MUST be used unless other conditions for processing the request permitting offline access to the requested resources are in place. The OP MUST always obtain consent to returning a Refresh Token that enables offline access to the requested resources. A previously saved user consent is not always sufficient to grant offline access.

Of similar concern, but probably a separate issue - "prompt=consent" only displays consent if relying-party.xml has added the attribute-release flow to OIDC.SSO..

<bean parent="OIDC.SSO" p:postAuthenticationFlows="attribute-release" />

client-side storage of user sessions failing

Storing user sessions to client-side storage fails. Authorize flow does not populate the client storage load context. Will be fixed in 1.1

Testing PKCE flow

Hi

I am trying to get the OAuth2 Authorization Code flow with PKCE extension working.

I added a client configuration:

{
  "client_id": "https://spa.example.com",
  "client_name": "description",
  "logo_uri": "https://spa.example.com/logo.jpg",
  "response_types": [
    "code"
  ],
  "grant_types": [
    "authorization_code"
  ],
  "scope": "openid profile",
  "redirect_uris": ["https://spa.example.com/callback"],
  "subject_type": "public"
}

I can get a code:

https://idp.example.com/idp/profile/oidc/authorize?scope=openid%20profile&response_type=code&client_id=https%3A%2F%2Fspa.example.com&code_challenge=1854380fe9792fd611478d2f98a948a098efee3bb2ae38721efa6f69c696d00b&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fspa.example.com%2Fcallback

After authn, I am redirected to:
https://spa.example.com/callback?code=AApz...UeHg

When I try to resolve the code for a token:

curl --request POST \
  --url 'https://idp.example.com/idp/profile/oidc/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=authorization_code \
  --data 'client_id=https://spa.example.com' \
  --data code_verifier=ooYaingahhiewie2Oofaelie6chai7phaif1dai1eeg \
  --data code=AApz...UeHg \
  --data 'redirect_uri=https://spa.example.com/callback'

I get:

{"error_description":"AccessDenied","error":"invalid_request"}

Logs:

WARN [org.geant.idpextension.oidc.profile.impl.ValidateEndpointAuthentication:206] - Profile Action ValidateEndpointAuthentication: Unrecognized client authentication null for client_secret_basic - 
WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: AccessDenied - 

Am I missing some configuration to overrule the authentication at the token endpoint? The client_secret is absent, since I am using the PKCE flow.

Thanks

(Invalid) logo in client metadata causes NPE

##Version
1.0.1
##Type
Bug
##Description
Setting logo to client metadata results NPE if the logo has no content:
2019-04-23 11:30:05,171 - 81.197.147.73 - ERROR [net.shibboleth.idp.saml.profile:-2] - Uncaught runtime exception
java.lang.NullPointerException: null
at org.geant.idpextension.oidc.profile.impl.InitializeOutboundAuthenticationResponseMessageContext.doExecute(InitializeOutboundAuthenticationResponseMessageContext.java:209)

Maven parent POM should be in project root directory

Is there any reason why your Maven parent pom.xml is located in the subdirectory idp-oidc-extension-parent?

Although this works, it is not the usual "Maven way" where the parent POM -- when it is bundled in the same repository -- lies in the project's root directory. Putting it in a subdirectory makes everything a bit more complicated and error-prone: you have to remember to use ../ to reference modules, files (like your checkstyle config) and every child module must have <relativePath>../idp-oidc-extension-parent</relativePath> added to its parent definition.

I know this is how the Shibboleth IdP and OpenSAML code is organised, but you don't have to follow that habit... ;)

issue noted in maven build

during the mvn package stage:

---

T E S T S

Running TestSuite
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.mockito.cglib.core.ReflectUtils$2
(file:/Users/alanbuxey/.m2/repository/org/mockito/mockito-core/1.10.8/mockito-core-1.10.8.jar)
to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of
org.mockito.cglib.core.ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Tests run: 292, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
10.812 sec - in TestSuite

Results :

Tests run: 292, Failures: 0, Errors: 0, Skipped: 0

"mvn package" fails

Error: Failed to execute goal on project idp-oidc-extension-impl: Could not resolve dependencies for project org.geant:idp-oidc-extension-impl:jar:1.1.1-SNAPSHOT: Failure to find com.duosecurity:DuoWeb:jar:1.3

Error loading class [org.geant.idpextension.oidc.profile.impl.PopulateOIDCSignatureSigningParameters]

Hi there,
I deployed this OIDC extension on top of my existing shibboleth idp.
I have setup a relying-party which connects to my shibboleth idp using OIDC profile and authorization code flow.
When I triggered the authentication flow, I got an error, "Error loading class [org.geant.idpextension.oidc.profile.impl.PopulateOIDCSignatureSigningParameters]".

Here's the log:
org.springframework.beans.factory.CannotLoadBeanClassException: Error loading class [org.geant.idpextension.oidc.profile.impl.PopulateOIDCSignatureSigningParameters] for bean with name 'PopulateIDTokenSignatureSigningParameters' defined in file [/opt/shibboleth-idp/flows/oidc/authorize/oidc-beans.xml]: problem with class file or dependent class; nested exception is java.lang.NoClassDefFoundError: org/opensaml/profile/action/AbstractHandlerDelegatingProfileAction
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1360)
Caused by: java.lang.NoClassDefFoundError: org/opensaml/profile/action/AbstractHandlerDelegatingProfileAction
at java.lang.ClassLoader.defineClass1(Native Method)
Caused by: java.lang.ClassNotFoundException: org.opensaml.profile.action.AbstractHandlerDelegatingProfileAction
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1335)

I have confirmed that idp-oidc-extension-impl-0.8.0.jar is in the right place, and in the idp.war file.
Any idea of what is happening here?

Thanks,
Zunan

request - consistent naming for config files.

More current releases of the plugin have separated the oidc specific configuration out of the base shibboleth configuration files into additional files that are referenced by the stock shibboleth configuration.

However, the names are inconsistent..
attribute-filter-oidc.xml
attribute-resolver-oidc.xml
credentials-oidc.xml
global-oidc.xml
idp-oidc.properties
services-oidc.xml

versus...
oidc-metadata-providers.xml
oidc-relying-party.xml
oidc-subject.properties

I feel like there should be a single naming convention.

Allow multiple authorization methods per RP in token endpoint

Currently allows only single authorization method per RP. Could allow any supported method simultaneously.

Attributes with the type SubjectDerivedAttribute not passed to id_token or userinfo

We have some attributes which are passed from the authentication phase and retrieved using the SubjectDerivedAttribute definition.

It works without any problem using SAML. They are also resolved at the "authorize" step.
But the values are not resolved at the token or userinfo steps. There is just 0 values.

An example of the definitions we use :

    <AttributeDefinition id="email" xsi:type="SubjectDerivedAttribute" principalAttributeName="mail">
        <AttributeEncoder xsi:type="oidcext:OIDCString" name="email"  placeToIDToken="true" denyUserinfo="false"/>
    </AttributeDefinition>

Configurable client_secret expiration not wired up

The GenerateClientSecret bean in the dynamic reg flow doesn't have the lookup function wired in to obtain the exp period from the profile config.

I believe it's just missing the p:secretExpirationPeriodStrategy="org.geant.idpextension.oidc.config.navigate.SecretExpirationPeriodLookupFunction" declaration.

claims parameter parsed incorrectly when in request object

##Version
1.0.1
##Type
Bug
##Description
Claims parameter is not handled correctly when part of request object. The result is that claims parameter set to request object is ignored.
ERROR [org.geant.idpextension.oidc.profile.context.navigate.DefaultRequestedClaimsLookupFunction:58] - claims claim is not of expected type

NPE when disabled OIDC.Configuration or OIDC.Keyset flows are called

If OIDC.Configuration and/or OIDC.Keyset profiles are not enabled for shibboleth.UnverifiedRelyingParty in relying-party.xm, then a call to their corresponding endpoints causes following error entry looping in the process log:

ERROR [org.geant.idpextension.oidc.profile:-1] - Uncaught runtime exception
java.lang.NullPointerException: null
at org.geant.idpextension.oidc.profile.impl.AbstractBuildErrorResponseFromEvent.doExecute(AbstractBuildErrorResponseFromEvent.java:155)

Update examples to 3.4 syntax

examples on https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/AttributeEncoderPluginConfiguration are deprecated as of v3.4

New syntax makes use of and :
https://wiki.shibboleth.net/confluence/display/IDP30/DataConnectorConfiguration#DataConnectorConfiguration-%3CDependency%3E

feature request - "password" grant

Is there any chance that the extension might support the "password" grant type, as described in the OAuth2 RFC:

https://tools.ietf.org/html/rfc6749#section-4.3.2

Access-token as JWT

Hi,

First of all, thank you for this great extension!
Was it a deliberate choice to create opaque access tokens for clients? Many OAuth2.0 implementations nowaday issue access tokens in a JWT-format.
Resources could than validate the access tokens based on their signature and metadata. I believe this could be useful for shortlived access tokens. Client are now obliged to do introspection of the token, which could be a costly operation for every call to the resource.

Could it be an option to issue the access token as a JWT on the OIDC.SSO profile?

Thanks

Documentation lacks info on Client Metadata and UIInfo handling and display

I've noticed that the login page we use for SAML logins is unable to render the UIInfo elements I included in the OIDC metadata as laid out here.

The documentation available doesn't include how to do this or I didn't find it.

So my suggestions are:

• Explicitly link to the OIDC specs in the MetadataConfiguration page, this stuff is confusing enough for newbies :-)
• Include a documentation page detailing how to include UIInfo elements in the IDP's page templates for both SAML and OIDC flows.
• Include an example showing a fully featured client metadata example.

idp install directory hardcoded as "/opt/shibboleth-idp"

There are hard coded paths to "/opt/shibboleth-idp" in both
conf/oidc-metadata-providers.xml
system/conf/services-system.xml

This should be updated to use the idp.home property, e.g.
%{idp.home}/conf/oidc-metadata-providers.xml

Maybe this is just in the demo IDP set up by vagrant / ansible?

feature request - implement requirements for dynamic registration

Acc'd to the dynamic registration spec , the only required piece of information are the redirect_uris.

We would like to be able to require certain optional pieces of data in the registration request - contact information, redirect URIs in specific domains, etc.

deprecated config

note some deprecated config on the bootup/creation (bottom of this output)

vagrant up

Bringing machine 'app' up with 'virtualbox' provider...
==> app: Running provisioner: ansible...
Vagrant has automatically selected the compatibility mode '2.0'
according to the Ansible version installed (2.5.5).

Alternatively, the compatibility mode can be specified in your Vagrantfile:
https://www.vagrantup.com/docs/provisioning/ansible_common.html#compatibility_mode

app: Running ansible-galaxy...

• downloading role 'xml', owned by cmprescott
• downloading role from
  https://github.com/cmprescott/ansible-xml/archive/1.0.0.tar.gz
• extracting cmprescott.xml to
  /root/shibboleth-idp-oidc-extension/roles/cmprescott.xml
• cmprescott.xml (1.0.0) was installed successfully
• downloading role 'mariadb', owned by CSCfi
• downloading role from
  https://github.com/CSCfi/ansible-role-mariadb/archive/v1.0.0.tar.gz
• extracting CSCfi.mariadb to
  /root/shibboleth-idp-oidc-extension/roles/CSCfi.mariadb
• CSCfi.mariadb (v1.0.0) was installed successfully
• downloading role 'jetty', owned by CSCfi
• downloading role from
  https://github.com/CSCfi/ansible-role-jetty/archive/v1.0.0.tar.gz
• extracting CSCfi.jetty to
  /root/shibboleth-idp-oidc-extension/roles/CSCfi.jetty
• CSCfi.jetty (v1.0.0) was installed successfully
• downloading role 'shibboleth-idp', owned by CSCfi
• downloading role from
  https://github.com/CSCfi/ansible-role-shibboleth-idp/archive/1.0.1.tar.gz
• extracting CSCfi.shibboleth-idp to
  /root/shibboleth-idp-oidc-extension/roles/CSCfi.shibboleth-idp
• CSCfi.shibboleth-idp (1.0.1) was installed successfully
  [WARNING]: - dependency cmprescott.xml from role CSCfi.shibboleth-idp differs
  from already installed version (1.0.0), skipping
  [WARNING]: - dependency CSCfi.jetty from role CSCfi.shibboleth-idp differs
  from already installed version (v1.0.0), skipping
• downloading role 'apache', owned by CSCfi
• downloading role from
  https://github.com/CSCfi/ansible-role-apache/archive/v1.0.0.tar.gz
• extracting CSCfi.apache to
  /root/shibboleth-idp-oidc-extension/roles/CSCfi.apache
• CSCfi.apache (v1.0.0) was installed successfully
• downloading role '389-ds', owned by CSCfi
• downloading role from
  https://github.com/CSCfi/ansible-role-389-ds/archive/master.tar.gz
• extracting CSCfi.389-ds to
  /root/shibboleth-idp-oidc-extension/roles/CSCfi.389-ds
• CSCfi.389-ds (master) was installed successfully
  app: Running ansible-playbook...
  [DEPRECATION WARNING]: Using 'port' as a role param has been deprecated. In the
  future, these values should be entered in the vars: section for roles, but
  for now we'll store it as both a param and an attribute.. This feature will be
  removed in version 2.7. Deprecation warnings can be disabled by setting
  deprecation_warnings=False in ansible.cfg.

Release policy for OAuth2 scope values based on IdPAttributes

Hi

I would like to use the OAuth2 scope attribute for authorization purposes on a OAuth2 resource server. For example, the resource server could implement a REST endpoint at /courses and use 2 scopes: courses:read & courses:write

• GET /courses would require scope courses:read
• POST /courses would require scope courses:write
• PUT /courses/1 would require scope courses:write
• etc

The scopes are now all or nothing based on the client's settings. But I would like to restrict who can read and who can write courses based on the available attributes the IdP has access to, e.g. students can only read, faculty can read & write courses.

The OAuth2 client would be allowed to request both scopes, but the context of the user will define which scopes will be granted or not.

Kid missing from JWE header

##Version
1.0.0
##Type
Bug
##Description
If there are multiple keys in keyset, Kid should be set to JWE Header. Not setting the Kid may result in RP rejecting the ID Token or UserInfo response if encryption is used and RP has several keys for the operation in keyset. No such case is yet reported though.

Shibboleth warnings

noted these in the idp-warn.log from fresh install

2018-07-02 12:06:25,439 - WARN
[net.shibboleth.idp.attribute.resolver.spring.enc.BaseAttributeEncoderParser:80]

• Configuration contains at least one element in the deprecated
  'urn:mace:shibboleth:2.0:attribute:encoder' namespace.
  2018-07-02 12:06:25,498 - WARN
  [net.shibboleth.idp.attribute.resolver.spring.ad.BaseAttributeDefinitionParser:123]
• Attribute Definition 'email_idtoken': sourceAttributeID was not
  specified but is required
  2018-07-02 12:06:25,500 - WARN
  [net.shibboleth.idp.attribute.resolver.spring.ad.BaseAttributeDefinitionParser:123]
• Attribute Definition 'name_idtoken': sourceAttributeID was not
  specified but is required

first is caused by legacy IdP 2.x statements (those shouldn't appear
in a fresh v3 install...or if the v2 was upgraded to v3. the last 2
are cleared by adding the relevant sourceAttributeID in
attribute-resolver.xml ie

<!-- claim that is placed always to id token -->
<AttributeDefinition id="email_idtoken" xsi:type="Simple"

sourceAttributeID="email_idtoken">

<!-- claim that is placed always to id token -->
<AttributeDefinition id="name_idtoken" xsi:type="Simple"

sourceAttributeID="name_idtoken">

Maven test failures for fresh builds

Using Maven 3.5.4 with OpenJDK 11.0.4 after a successful git clone running mvn package which will execute for a good while without error until eventually at "idp-oidc-extension-api":

[INFO] Running TestSuite
[ERROR] Tests run: 141, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 36.141 s <<< FAILURE! - in TestSuite
[ERROR] testSuccessNoSecurity(org.geant.idpextension.oidc.metadata.resolver.RemoteJwkSetCacheTest)  Time elapsed: 0.309 s  <<< FAILURE!
java.lang.AssertionError: expected object to not be null
	at org.geant.idpextension.oidc.metadata.resolver.RemoteJwkSetCacheTest.testSuccessNoSecurity(RemoteJwkSetCacheTest.java:100)

Regardless how often the package is being built, at the following step it always identifies changes:

[INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @ idp-oidc-extension-api ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 117 source files to /home/xxx/shibboleth-idp-oidc-extension/idp-oidc-extension-api/target/classes
[INFO] /home/xxx/shibboleth-idp-oidc-extension/idp-oidc-extension-api/src/main/java/org/geant/idpextension/oidc/profile/context/navigate/DefaultRequestMaxAgeLookupFunction.java: Some input files use or override a deprecated API.
[INFO] /home/xxx/shibboleth-idp-oidc-extension/idp-oidc-extension-api/src/main/java/org/geant/idpextension/oidc/profile/context/navigate/DefaultRequestMaxAgeLookupFunction.java: Recompile with -Xlint:deprecation for details.

Calling mvn package often enough (maybe 5-6 times), it may also go past the above error but fails nevertheless at "idp-oidc-extension-impl":

[INFO] Running TestSuite
[ERROR] Tests run: 532, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 266.45 s <<< FAILURE! - in TestSuite
[ERROR] testWithAuthorizationCodeFlow(org.geant.idpextension.oidc.profile.flow.AuthorizeFlowTest)  Time elapsed: 1.774 s  <<< FAILURE!
java.lang.AssertionError: expected [CommitResponse] but found [ErrorView]
	at org.geant.idpextension.oidc.profile.flow.AuthorizeFlowTest.testWithAuthorizationCodeFlow(AuthorizeFlowTest.java:81)

[ERROR] testRevokeAccessToken(org.geant.idpextension.oauth2.profile.impl.RevokeTokenTest)  Time elapsed: 0.024 s  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
	at org.geant.idpextension.oauth2.profile.impl.RevokeTokenTest.testRevokeAccessToken(RevokeTokenTest.java:132)

[ERROR] testRevokeRefreshToken(org.geant.idpextension.oauth2.profile.impl.RevokeTokenTest)  Time elapsed: 0.027 s  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
	at org.geant.idpextension.oauth2.profile.impl.RevokeTokenTest.testRevokeRefreshToken(RevokeTokenTest.java:143)

Currently running this on SuSE's Tumbleweed, but had the same happen under CentOS 7 and also Fedora 30, so I can likely rule out some strange distro behavior or strange customization issues within an older system installation.

Expected behavior for me would be, of course, that it builds without error on a fresh default install or a hint if more configuration or setup is needed before it can be built.

cannot parse redirect_uris with hash marks in them

When trying to load an OIDC client definition from the file based resolver (FilesystemClientInformationResolver), if a redirect_uri contains a hash mark, e.g.

"redirect_uris": ["https://rp.example.edu/new/#/"],

The plugin returns:

2020-02-03 13:27:50,275 - DEBUG [org.geant.idpextension.oidc.metadata.impl.FilesystemClientInformationResolver:186] - 127.0.0.1 - Could not parse single client information from the file, checking for array 2020-02-03 13:27:50,303 - ERROR [org.geant.idpextension.oidc.metadata.impl.AbstractReloadingOIDCEntityResolver:178] - 127.0.0.1 - Error occurred while attempting to refresh metadata from '/opt/shibboleth-idp/metadata/oidc-client.json' com.nimbusds.oauth2.sdk.ParseException: Could not parse a single or an array of OIDC client information object(s). at org.geant.idpextension.oidc.metadata.impl.FilesystemClientInformationResolver.parse(FilesystemClientInformationResolver.java:197)

And like #40, the plugin reports that the cofiguration has been reloaded without mention of any errors.

Missing acr causes error

If acr is not defined in request, runtime exception is caught

2018-04-12 07:18:20,768 - ERROR [net.shibboleth.idp.saml.profile:-2] - Uncaught runtime exception java.lang.RuntimeException: Invalid parameters, programming error at org.geant.idpextension.oidc.token.support.TokenClaimsSet.<init>(TokenClaimsSet.java:137)

Can be avoided by defining acr in authentication configuration:

<bean parent="shibboleth.OIDCAuthnContextClassReference" c:classRef="password" />

Authentication for OIDCClientRegistration

I added Basic authentication on container-level (jetty) in order to protect the oidc-client-registration endpoint (/idp/profile/oidc/register). But the Authorization header is passed along com.nimbusds.openid.connect.sdk.rp.OIDCClientRegistrationRequest, which eventually throws a ParseException because he expects a Bearer token:

ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action DecodeMessage: Unable to decode incoming request - org.opensaml.messaging.decoder.MessageDecodingException: com.nimbusds.oauth2.sdk.ParseException: Token type must be "Bearer"
        at org.geant.idpextension.oidc.decoding.impl.OIDCClientRegistrationRequestDecoder.doDecode(OIDCClientRegistrationRequestDecoder.java:83)
Caused by: com.nimbusds.oauth2.sdk.ParseException: Token type must be "Bearer"
        at com.nimbusds.oauth2.sdk.token.BearerAccessToken.parse(BearerAccessToken.java:259)

Is there a way to enable the OIDC-registration endpoint with authentication?
Perhaps I could strip the Authorization-header after validation by jetty.

Any thoughts on this?

ClientInformationResolvers are prematurely expiring cached keys

As I'm porting this, I believe there's a bug in the StorageServiceClientInformationResolver and FilesystemClientInformationResolver classes where they pass in a keyFetchInterval expressed as a Duration into what turns into the expiration time to set on the stored records.

The expiration value is a timestamp, so it's essentially expiring the records immediately (treating 30 minutes past the epoch as the expiration time).

I'm patching this for the V4 port into Instant.now().plus(keyFetchInterval) and a similar translation would be needed in this version.

OIDC Metadata refresh not working as expected

I've noticed that calling

/opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.MetadataResolverService

doesn't reload the OIDC metadata I've added.

So I tried adding the OIDC metadata provides to the service config like this:

    <util:list id="shibboleth.MetadataResolverResources">
        <value>%{idp.home}/conf/metadata-providers.xml</value>
        <value>%{idp.home}/conf/oidc-metadata-providers.xml</value> <-------------
        <value>%{idp.home}/system/conf/metadata-providers-system.xml</value>
    </util:list>

While the metadata are verified and loaded, they aren't used by the IDP.
I'm guessing it's because the OIDC stuff doesn't tie in the inner workings of the service called here, but being able to reload the metadata without restarting the whole application would be nice.

feature request - allow use client_name instead of / in addition to client_id if available

It would be nice if logging could use the client_name (if it's available in the metadata) instead of / in addition to the client_id,
e.g.
2018-06-26 16:48:53,952 - INFO [org.geant.idpextension.oidc.metadata.impl.AbstractReloadingOIDCEntityResolver:183] - - Parsed entity information for 292085223830.apps.googleusercontent.com
vs
2018-06-26 16:48:53,952 - INFO [org.geant.idpextension.oidc.metadata.impl.AbstractReloadingOIDCEntityResolver:183] - - Parsed entity information for "student app"

client_name is a valid (though optional) metadata element acc'd to https://openid.net/specs/openid-connect-registration-1_0.html

Unable to use introspection endpoint

I can't find how to use the introspection endpoint.
The documentation is unclear about how to configure the access policy for this endpoint.
From what I found, it seems that i have to call it as a POST method, with "token=OIDC_TOKEN" as POST data.
But I always get an error message saying that clientId cannont be null.
I also tried to pass an "Authorization: Bearer xxx" with the same token or another one, but I can't find a call configuration which anything else than an error.
What are the required parameters to call this endpoint, and what configuration is required?

Feature request: implement kid checking to authentication request validation

Apparently the extension does not currently check for the kid value on request object header, but iterates all keys in the keyset. According to the core (10.1.1):

The signer publishes its keys in a JWK Set at its jwks_uri location and includes the kid of the signing key in the JOSE Header of each message to indicate to the verifier which key is to be used to validate the signature

Please, would it be possible to consider implementing the core kind of way and using the JOSE Header kid value in selecting the key to validate the signature?

"reload-service.sh -id shibboleth.ClientInformationResolverService" reports success when loading invalid files

I'm using the file based resolver in oidc-metadata-providers.xml,
<bean id="ExampleFileResolver" class="org.geant.idpextension.oidc.metadata.impl.FilesystemClientInformationResolver" p:id="ExampleFileResolver1" p:remoteJwkSetCache-ref="shibboleth.oidc.RemoteJwkSetCache" c:metadata="%{idp.home}/metadata/oidc-client.json" />

I frequently use the Shibboleth provided "reload-service.sh" script, to load RP client definitions. It appears to load any file you care to point at without error, or at least the command line tells you that the file has loaded...

[STAGING bin]$ /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.ClientInformationResolverService Configuration reloaded for 'shibboleth.ClientInformationResolverService'

But the logs show errors...
2020-01-31 17:49:50,810 - DEBUG [org.springframework.webflow.execution.ActionExecutor:49] - 127.0.0.1 - Executing net.shibboleth.idp.profile.impl.ReloadServiceConfiguration@43a0be85 2020-01-31 17:49:50,810 - DEBUG [net.shibboleth.idp.profile.impl.ReloadServiceConfiguration:124] - 127.0.0.1 - Profile Action ReloadServiceConfiguration: Reloading configuration for 'shibboleth.ClientInformationResolverService' 2020-01-31 17:49:50,811 - INFO [net.shibboleth.utilities.java.support.service.AbstractReloadableService:258] - 127.0.0.1 - Service 'shibboleth.ClientInformationResolverService': Reloading service configuration 2020-01-31 17:49:50,812 - INFO [net.shibboleth.ext.spring.util.SchemaTypeAwareXMLBeanDefinitionReader:317] - 127.0.0.1 - Loading XML bean definitions from file [/opt/shibboleth-idp/conf/oidc-metadata-providers.xml] 2020-01-31 17:49:50,842 - INFO [net.shibboleth.ext.spring.context.FilesystemGenericApplicationContext:583] - 127.0.0.1 - Refreshing shibboleth.ClientInformationResolverService: startup date [Fri Jan 31 17:49:50 EST 2020]; parent: Root WebApplicationContext 2020-01-31 17:49:50,887 - DEBUG [org.geant.idpextension.oidc.metadata.impl.AbstractReloadingOIDCEntityResolver:159] - 127.0.0.1 - Beginning refresh of metadata from '/opt/shibboleth-idp/metadata/oidc-client.json' 2020-01-31 17:49:50,887 - DEBUG [org.geant.idpextension.oidc.metadata.impl.AbstractFileOIDCEntityResolver:118] - 127.0.0.1 - Returning the contents of /opt/shibboleth-idp/metadata/oidc-client.json as byte array 2020-01-31 17:49:50,888 - DEBUG [org.geant.idpextension.oidc.metadata.impl.AbstractReloadingOIDCEntityResolver:165] - 127.0.0.1 - Processing new metadata from '/opt/shibboleth-idp/metadata/oidc-client.json' 2020-01-31 17:49:50,889 - DEBUG [org.geant.idpextension.oidc.metadata.impl.FilesystemClientInformationResolver:186] - 127.0.0.1 - Could not parse single client information from the file, checking for array 2020-01-31 17:49:50,890 - ERROR [org.geant.idpextension.oidc.metadata.impl.AbstractReloadingOIDCEntityResolver:178] - 127.0.0.1 - Error occurred while attempting to refresh metadata from '/opt/shibboleth-idp/metadata/oidc-client.json' com.nimbusds.oauth2.sdk.ParseException: Could not parse a single or an array of OIDC client information object(s).

It seems like it should behave more like when you try to reload other services with bad configuration files...
[STAGING bin]$ ./reload-service.sh -id shibboleth.AttributeResolverService (http://localhost/idp/profile/admin/reload-service?id=shibboleth.AttributeResolverService) Server returned HTTP response code: 500 for URL: http://localhost/idp/profile/admin/reload-service?id=shibboleth.AttributeResolverService

Matchers should return empty for null

For completeness I'll pop this in, it was reported here.

The getMatchingValues method in AttributeInOIDCRequestedClaimsMatcher returns null quite a lot.

the filters (both matchers and policy) return a tristate in which we distinguish between "worked but nothing resulted" and "failed". For the former case you need to return an empty set for the latter null.

This is a signal to the upper layers to "do the right thing" depending on whether this is a deny rule (in which case failure means "deny everything") or an accept rule (in which case failure means "accept nothing").

I'm sure you've seen the case, this is just FWIW

Link the "Installing from archive" wiki page more prominently

After getting a mostly working configuration through reverse engineering and trial and error, by accident I discovered the Installing from archive wiki page, which was the holy grail I needed from the beginning. It's not linked from the Installation section of the README. In the repository, I only see it listed as one item in the middle of the wiki list of all pages, and in the 1.1.1 tag notes. On the wider internet, it's mentioned from the 2018 training tutorial, and in answer to a number of user list questions on where the setup instructions are.

I had been looking for instructions all through the process, but didn't get lucky with the search terms until the nth try. I thought it was odd that instructions were missing, but assumed it was related to moving the 2.x archive to Shibboleth hosting.

Client information storing

When user logins to the service, client information is stored. Is this information different for each login? And it actually never could find any records for the client or should this occur only at the first login to the service. Anyways I assume this shouldn't be an ERROR at the first attempt to find records.

2019-09-10 12:54:51,176 - <IP 1> - ERROR [org.geant.idpextension.oidc.metadata.impl.StorageServiceClientInformationResolver:132] - Could not find any records with clientId <CLIENT ID_1> 2019-09-10 12:55:02,424 - <IP 2> - ERROR [org.geant.idpextension.oidc.metadata.impl.StorageServiceClientInformationResolver:132] - Could not find any records with clientId <CLIENT ID_1> 2019-09-10 12:55:03,746 - <IP 1> - ERROR [org.geant.idpextension.oidc.metadata.impl.StorageServiceClientInformationResolver:132] - Could not find any records with clientId <CLIENT ID_1>

feature request: additional metadataprovider types (LocalDynamicMetadataProvider?)

It would be helpful if the OIDC provider had an equivalent to the SAML LocalDynamicMetadataProvider type. Specifically, I would like to be able to point my configuration at a directory full of OIDC metadata files rather than having to define an aggregate file, or per-provider files.