Testing OIDC client registration

[Janne Lauros]

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%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 | 
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 ] 


OIDCOAuthSSLValidateServer Off # Test client doesn’t have https 

OIDCSSLValidateServer Off 

OIDCRedirectURI [ http://client.example.edu/protected/redirect_uri | 
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 [ mailto:username at example.edu | username at example.edu ] looks require that .well-known information be located at [ https://example.edu/ | 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 ( [ http://idp.example.edu/ | idp.example.edu ] ) does not match the "issuer" value in the provider metadata file: [ https://idp.example.edu/ | https://idp.example.edu ] , referer: [ https://sp.example.umich.edu/oidc/ | 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 " [ http://mitreid.org/ | mitreid.org ] " (but even [ http://mitreid.org/ | mitreid.org ] generates an error, requiring " [ https://mitreid.org/ | 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 







-- 
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/1e0e9898/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: ~WRD000.jpg
URL: <http://shibboleth.net/pipermail/users/attachments/20190523/1e0e9898/attachment.jpg>