Clareity OpenID Work

[Russell Beall]

Hi Paul,

This looks great.  Seems like you are building this with quite a bit of interlacing with the Shibboleth configuration as well as manually handling a number of OIDC server components.

I’ve been working on a very similar project but my research led me to stand up the MITREid server, which is a Java Spring project with a maven overlay that lets you customize it pretty easily.  I’m keeping the server somewhat separate and have fronted the server with a shib SP that lives on the same server as the IdP.  Login to the OIDC server shunts over to the IdP similar to what you mentioned below and then when it comes back, I’ve set a filter to set up a user in the OIDC database.  There is still a lot of work to do on it, but it seems like a good start, and I’ve been able to leave all the details of the OIDC server to the MITREid project which has the whole server and configuration UI built right in.

I’ve been wondering if the systems are too separate and I might run into an issue such as some type of back-channel request that would not be deliverable.  Theoretically the OIDC server should be operable independently and all I’ve had to do is replace the built in j_security_check form login with a preauth filter.

Did you happen to look at that project during your research?

Any reason this approach might have pitfalls to avoid where it would instead be better to deeply embed the two servers together to better share data, sessions and such?

Thanks,
Russ.

=========================
Russell Beall  |  Systems Programmer IV 
Enterprise Identity Management | University of Southern California 
(213) 740-7221  |  beall at usc.edu



> On Dec 11, 2015, at 8:58 AM, Paul Hethmon <paul.hethmon at clareitysecurity.com> wrote:
> 
> I’ve been talking to Tom about this and I know he’s brought it up on some of the dev calls, so fulfilling my promise of providing some details.
> 
> Here at Clareity, we’ve made the commitment to our customers to support OpenID Connect in our solutions. Given we are very big SAML/Shibboleth supporters, I needed something that blended seamless with Shibboleth. So I’ve been working on this for the last month and I’m getting close to initial testing. I am hoping (and recommending) that we put this out in our open source repository for others to use. I haven’t got that approved yet (or actually asked for that matter), but I don’t see it as a problem. Given that, here’s some of the assumptions and decisions I’ve made:
> 
> 1. All authentication is handled by Shibboleth using the configured handler.
> 2. The OIDC issuer value is the same as the default provider entityID. In my use of Shib, that’s all I have configured. Not sure if that’s a good design choice for Shib in general.
> 3. The OIDC certificate uses the Shib certificate, grabbed at runtime via the default relying party configuration manager.
> 4. Minimal separate configuration, ideally no extra configuration, but not sure yet if that’s possible or desirable.
> 5. Support for the “.well_known” OIDC discovery mechanism via a servlet that builds it dynamically.
> 6. OIDC authentication requests are translated to SAML Authn Requests. This is to tie the browser session between the protocols.
> 7. The OpenID module itself is configured as a SAML relying party to the IdP, so a proxy. I’m picking up the entityID via a configuration file I have for my Shib login handler. From there, I grab the metadata from the relying party manager. That works for my needs, but wouldn’t for Shib in general.
> 8. Given the OIDC protocol design, there is a requirement that the session data established by the end user logging in is available to all Shib nodes independent of the Shib session. So I’m using my design for the DB backed storage engine from v2 to store the OIDC session information. So the access token returned by the authorization step can be used by the OIDC RP to request the id token (server to server).
> 9. There is a need to be able to authenticate the direct request by the RP for the id token. In my design, I’m re-using my HTTP Basic Auth filter for ECP access. Which means that the RP credentials are stored in the same system and authenticated in the same way.
> 
> To lay out the flow here, you would see:
> 
> 1. Inbound OIDC authorization request to IdP module
> 2. IdP module creates SAML Authn Request and redirects browser to Shib
> 3. Shib processes as normal
> 4. SAML Response is sent back to the OpenID module within the Shib instance and consumed as normal (sig verified, attributes pulled, etc)
> 5. OIDC access token issued
> 6. OIDC normal flows continue
> 
> I think it will be necessary to store/obtain OIDC metadata about the relying parties on that protocol. The module has to know who are the allowed RP’s. So that part and also knowing what SAML entityID to make use of is necessary configuration.
> 
> I don’t feel I’m far enough along yet to really know everything I need to know, both about the integration and OIDC in general.
> 
> For library support, I’m using the Nimbus libraries by Connect2Id. I started out with Apache Oltu, but they are incomplete, have no documentation, and no comments in the source code. The Nimbus is more complete, and their examples are slightly better. Still, as in most projects, documentation sucks. They also believe that their code is self documenting (no comments anywhere). So couple that with me learning the protocol and its slow going.
> 
> Clareity did officially join the OpenID Foundation, so I do have access to their certification tool to verify I’m doing things correctly.
> 
> There’s my summary to the community. Hopefully I can open source what I have and perhaps it can be included in Shibboleth. One last thing is that what I’m doing currently is hooking into v2. I don’t see that as a big problem though since the only places its hooking is getting some of the configuration information currently, that should be easy enough to update for v3.
> 
> cheers,
> 
> Paul
> 
> -----
> Paul Hethmon
> Chief Software Architect
> paul.hethmon at clareitysecurity.com
> 
> 
> -- 
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net