New OpenID Connect implementation

[Bart Geesink]

Hi all,

Since 2016 the OpenConext software stack supports OpenID Connect as authentication protocol, next to
the well established SAML2 protocol.

When we started working on OpenID Connect, we decided not to reinvent the wheel ourselves, and used
an existing open source OpenID Connect Provider implementation, MitreID Connect. It was a good fit
at that time for the purpose that we had in mind and allowed us to have a working OpenID Connect
endpoint with a few weeks of development efforts.

Unfortunately, the MitreID Connect project development stopped for the most part after we started
using it. Furthermore, where the implementation out of the box worked very well, adding or removing
functionality proved to be quite challenging. However, it has served us very well in understanding
the challenges and possibilities of the OpenID Connect protocol, and having a working implementation
in a short period of time.

As we wanted to implement extra functionality, for example support for using OpenConext to secure
APIs, or integration with Manage, we decided to reimplement the OpenID Connect interface of
OpenConext, with the following starting points:

* The "trusted proxy" model works very well, and should not be changed. That means that a lot of the
heavy lifting is done by Engineblock: ACL's, attribute release policies, authorization decisions,
attribute aggregation, generating identifiers,
* A GUI is not needed: Entities are managed in OpenConext Manage
* For maximum flexibility in terms of features, we will build our own implementation on top of an
existing and well-supported library
* Simplify the publicly available OpenID configuration on the .well-known endpoint
* Support at least the same feature set as the current implementation

Furthermore, we are implementing a few new features:
1) Allowing Resource Servers to be connected to OpenConext: This would allow an OpenID Connect
Relying Party to request an access token with which it can then authenticate with a Resource Server.
The resource server in turn can check the access token, and if allowed, receive user information,
like the subject and configured claims. A typical use case would be a mobile app, requesting data
from an API.
2) Support PKCE which can be used to protect mobile and browser based apps.
3) The userinfo endpoint currently needs a local cache of user claims (attributes). The idea is to
encrypt these claims in the access token. When a client queries the userinfo endpoint, the claims
can be decrypted on the fly, eliminating the need to cache the claims.

Development work has started already and can be tracked here:
https://github.com/OpenConext/OpenConext-oidcng . The library that we chose is the Nimbus OAuth 2.0
SDK with OpenID Connect extensions.

We welcome any input you might have. We hope to be able to release a public alpha release soon.

Cheers,
Bart

[Niels van Dijk]

Hi Bart,

Thanks for the update. Question: The REFEDs OIDCre group last year
drafted a document[1] describing how to map SAML (eduPerson) attributes
to OIDC claims. While the document is not yet formalized by REFEDs,
there has been a good deal of community scrutiny as part of the public
consultation and there seems to be consensus on using the
recommendations. Is this something you intent to implement into the
OpenConext proxy?

Regards,

Niels

[1]
https://wiki.refeds.org/display/CON/Consultation%3A+SAML2+and+OIDC+Mappings?preview=/38895621/38895643/20181011-OIDC-WP.pdf

--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org

[Bart Geesink]

Hi Niels,

On 5/15/19 10:17 AM, Niels van Dijk wrote:
> Hi Bart,
>
> Thanks for the update. Question: The REFEDs OIDCre group last year
> drafted a document[1] describing how to map SAML (eduPerson) attributes
> to OIDC claims. While the document is not yet formalized by REFEDs,
> there has been a good deal of community scrutiny as part of the public
> consultation and there seems to be consensus on using the
> recommendations. Is this something you intent to implement into the
> OpenConext proxy?
>

Yes we would. It's even possible to create your own SAML to OIDC mapping even:
https://github.com/oharsta/oidc-ng/blob/master/src/main/resources/oidc/saml_mapping.json

Regards,
Bart

[Okke Harsta]

Any pull requests should be made on this file as the repo in the previous link has been moved:

https://github.com/OpenConext/OpenConext-oidcng/blob/master/src/main/resources/oidc/saml_mapping.json

This file will be moved to OpenConext-deploy in the future so that custom OpenConext instances can override the SAML -> OIDC mapping.

Regards,

Okke

-- 
OpenConext - Open For Collaboration
--- 
You received this message because you are subscribed to the Google Groups "OpenConext Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openconext+...@googlegroups.com.
To post to this group, send email to openc...@googlegroups.com.
Visit this group at https://groups.google.com/group/openconext.
To view this discussion on the web visit https://groups.google.com/d/msgid/openconext/cf4e4a6f-bd81-a128-e7f5-739f1d0b124a%40surfnet.nl.
For more options, visit https://groups.google.com/d/optout.