Testing OIDC client registration

Thu May 23 11:44:46 EDT 2019

All,

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,
Nate.

On Thu, May 23, 2019 at 12:09 AM Janne Lauros <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>
> *To: *"users" <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
>
> </Location>
>
>
>
> 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.
>
>
>
> Keith
>
>
>
> *From:* users <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>
> *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 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) 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" (but even 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.
>
>
>
> Liam
>
>
>
> [image: 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
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190523/40feab0c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20190523/40feab0c/attachment.jpg>