Testing OIDC client registration

Wessel, Keith kwessel at illinois.edu
Thu May 23 12:00:43 EDT 2019

Hey, Nate,

For us, the Apache OIDC module was sufficient. I’ll also note that a quick Google search produces a number of existing OIDC test clients. If we start doing things with OIDC federations that the masses currently aren’t doing, I can see some value in this, but not yet.

Thanks for tossing out the idea, though.


From: Nate Klingenstein <ndk at sudonym.me>
Sent: Thursday, May 23, 2019 10:45 AM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: Testing OIDC client registration


I write this with great trepidation as we have a large and growing pile of other things to do, but Signet might be willing to set up an OIDC testing service like SAMLtest if there's the popular demand.

Are we at the stage where such a service would be useful?  Do people really need one, or is it simple enough to configure on one's own servers?

Best wishes,

On Thu, May 23, 2019 at 12:09 AM Janne Lauros <janne.lauros at csc.fi<mailto:janne.lauros at csc.fi>> wrote:
Hi Keith and all,

>> Geant folks, one item missing from your documentation.
Thanks for pointing that out. Adding the keyset is mentioned in https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/Installing-from-archive#profile-configurations and in https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/OIDC.Keyset. The example activation in https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/DynamicClientRegistration was bad and you propably copied the example losing the keyset configuration. I changed the wording and also the example to prevent that. I hope it is better now.

Br Janne

From: "Keith Wessel" <kwessel at illinois.edu<mailto:kwessel at illinois.edu>>
To: "users" <users at shibboleth.net<mailto:users at shibboleth.net>>
Sent: Wednesday, 22 May, 2019 17:00:02
Subject: RE: Testing OIDC client registration

Hi, all,

Just wanted to report that I did get this working without having to manually download the OP metadata.

Geant folks, one item missing from your documentation. You mention that the OIDC.Registration bean has to be added to the UnverifiedRelyingParty configratuion. That gets the registration done, but the client can’t retrieve the keyset. I also had to add the OIDC.Keyset bean.

And for anyone trying to test this with Apache mod_auth_openidc, my config looks like this:

OIDCClientID test_rp

OIDCClientSecret <redacted>

OIDCProviderIssuer https://idp.example.edu # matching issuer from IdP’s OIDC extension configuration and a resolvable URL that, when appended with .well-known/openid-configuration, will result in your OIDC provider config)u<https://idp.example.edu%20#%20matching%20issuer%20from%20IdP's%20OIDC%20extension%20configuration%20and%20a%20resolvable%20URL%20that,%20when%20appended%20with%20.well-known/openid-configuration,%20will%20result%20in%20your%20OIDC%20provider%20config)u>

OIDCOAuthSSLValidateServer Off # Test client doesn’t have https

OIDCSSLValidateServer Off

OIDCRedirectURI http://client.example.edu/protected/redirect_uri

OIDCCryptoPassphrase <redacted>

OIDCResponseType "code"

OIDCScope "openid profile email address phone"

OIDCMetadataDir /var/cache/httpd/mod_auth_openidc/metadata

OIDCCacheDir /var/cache/httpd/mod_auth_openidc/cache

<Location /protected>

AuthType openid-connect

# And whatever Require or Grant directives go here


The first time you log in, you’ll be prompted by the Apache module to enter your provider. If you type in the full issuer ID including the https://, it should go to .well-known/opened-configuration and retrieve everything it needs to know. It will then perform a client registration, and everything should work from there on out for logging in and getting back claims.


From: users <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>> On Behalf Of Liam Hoekenga
Sent: Wednesday, May 15, 2019 5:30 PM
To: Shib Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: Re: Testing OIDC client registration

One question before I try this, though: why do I have to manually download the OP’s metadata and install it? Isn’t part of the whole thing the module’s ability to dynamically discover and download the OP’s information?

I think that it's supposed to be able to download the metadata.

I believe if you give it a hostname, it's supposed to try to find the well-known information, and I think that username at example.edu<mailto:username at example.edu> looks require that .well-known information be located at https://example.edu.

I think that hostname based discovery has issues (at least it did in mid-March).   If I don't specify the protocol, it complains..

[Fri Mar 15 16:09:00 2019] [error] [client xxx.xxx.xxx.xxx] oidc_metadata_provider_is_valid: requested issuer (idp.example.edu<http://idp.example.edu>) does not match the "issuer" value in the provider metadata file: https://idp.example.edu, referer: https://sp.example.umich.edu/oidc/

The spec says iss is supposed to be a case sensitive HTTPS url.   I had assumed the hostname was sufficient based on the default form and "mitreid.org<http://mitreid.org>" (but even mitreid.org<http://mitreid.org> generates an error, requiring "https://mitreid.org" to work).

I asked the developer (Hans Zandbelt) and he said he believed that it was due to a change at some point in the code where he started to put more strict requirements on the provided issuer values because of recent attacks but failed to adapt the HTML discovery pages.


[Image removed by sender.]

For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190523/00f4d8af/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 823 bytes
Desc: image001.jpg
URL: <http://shibboleth.net/pipermail/users/attachments/20190523/00f4d8af/attachment.jpg>

More information about the users mailing list