<div dir="ltr"><div>tldr; use the GEANT extension - <a href="https://github.com/CSCfi/shibboleth-idp-oidc-extension">https://github.com/CSCfi/shibboleth-idp-oidc-extension</a></div><div><br></div><div>If you are looking to integrate OIDC with the Shibboleth IDP, you should used the GEANT extension. The current release is 1.0.2. University of Michigan has been using in our production environments since the beginning of the calendar year (and in non-prod since last summer).<br></div><div><br></div>I know of two OIDC implementations for the Shibboleth IDP...<div>- <a href="https://github.com/uchicago/shibboleth-oidc">https://github.com/uchicago/shibboleth-oidc</a></div><div>- <a href="https://github.com/CSCfi/shibboleth-idp-oidc-extension">https://github.com/CSCfi/shibboleth-idp-oidc-extension</a></div><div><br></div><div>The UChicago implementation was done by Unicon on behalf of the University of Chicago (and later the University of Michigan) and it basically embeds MitreID Connect OIDC server (<a href="https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server">https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server</a>) into the Shibboleth IDP. It's not a tight integration. MitreID maintains it's own session store completely independently of the IDP, and we found it didn't work well with our clustering configuration. The attributes available via OIDC are also limited to the standard claims defined in <a href="https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims">OpenID Connect Core 1.0</a>, and the mappings between the SAML attributes that are used to populate those claims are "hard" - they are located in java source code, so to change them, you'd need to recompile the extension. If you have a single IDP, and don't need anything beyond the standard claims, it works ok.</div><div><br></div><div>The CSCfi implementation was sponsored by GEANT. It is a "from the ground up" implementation. While it depends on the "<a href="https://connect2id.com/products/nimbus-oauth-openid-connect-sdk">Nimbus OAuth 2.0 SDK with OpenID Connect Extensions</a>", this was written as an extension to the Shibboleth IDP from the very beginning. It is much more tightly integrated - they use common session storage, new claims and scopes are easily defined in using the native attribute resolver and filter mechanisms, and there is an excellent chance that this code will eventually be adopted as into the Shibboleth IDPv4 distribution. We've been very happy using this extension.</div><div><br></div><div>Liam</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2019 at 12:35 PM Joshua Brodie <<a href="mailto:josbrodie@gmail.com">josbrodie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>For the folks using OIDC on IDP:</div><div><br></div><div>- what module do you use?</div><div>- is it considered 'production' ready?</div><div>- would it be better to wait for IDPv4?<br></div></div>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a></blockquote></div>