OIDC Deployment Working Group

[Steven Carmody <>]

Hi,

there's an interesting thread on the Shib-dev email list describing the 
GEANT supported work being done in Finland to add OIDC/OAuth2 support to 
Shib IDP v3. This is the first post in the thread, from the two developers.

The thread can be viewed here:

https://shibboleth.net/pipermail/dev/2017-November/009568.html


-------- Forwarded Message --------
Subject: GEANT OIDC-work status
Date: Mon, 13 Nov 2017 16:31:11 +0200
From: Henri Mikkonen 
<>
Reply-To: Shib Dev 
<>
To: 


Hi,

Scott asked us to give a short status update to this list every now and 
then. So, here you are, a rough list of features we’ve been working on 
after summer. The list is not 100% accurate: purpose is to give you some 
kind of description where we are at the moment. Feel free to ask more 
details.

In overall, we aim at packaging an alpha version before end of the year, 
supporting standard implicit flow and dynamic client registration. We’ll 
test it against the OpenID foundation’s certification tool and some RPs, 
but naturally we welcome any help/input from you.

BR,
Henri & Janne

---

How to add RPs?

1. File system via JSON

- The implementation is very similar to Shib’s metadata resolvers, but 
we needed to fork the whole (abstract) class hierarchy from the root as 
the existing were based on SAML EntityDescriptors.

- Example “metadata” (serialized OIDCClientInformation class from 
Nimbus): 
https://github.com/CSCfi/shibboleth-idp-oidc-extension/blob/master/roles/oidc-extension/templates/oidc-client.json

2. Dynamic registration, 
https://openid.net/specs/openid-connect-registration-1_0.html

- The registered RPs are stored & obtained via StorageService (still on 
PoC-phase), seems to be compatible with Shib’s in-memory and JPA services.

- OIDCfed (spec by Roland Hedberg et al.) compatibility under 
construction now, need to be in testable shape before end of November: 
https://wiki.geant.org/display/gn42jra3/OIDCfed+Hackathon

---

Authorize flow

1. Implicit flow

- Fairly mature already, some certification tool steps 
(https://op.certification.openid.net:60000/) need still work / 
verification. The configuration we use for certifying our alpha version 
of OP is 
https://github.com/CSCfi/shibboleth-idp-oidc-extension/blob/master/roles/oidc-extension/templates/openid-configuration.

2.  Security configuration - Id token signing

- See: 
https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/SecurityConfiguration

- JWK credential support. Using JWK credentials is not mandatory. 
Shibboleth signing configurations are used for determining the algorithm 
and algorithm support.

- “All” OIDC RSA, ES and HS signing configurations supported.

3. Attribute resolution

- 
https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/AttributeEncoderPluginConfiguration

- Encoders to support OIDC claims: string, int, boolean, array and 
simple JSON objects.

- More complex cases of JSON object still need work.

4. Attribute filtering

- 
https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/AttributeFilterConfiguration

- Policy for scopes and matcher for requested claims. Example filter 
explains a lot - 
https://github.com/CSCfi/shibboleth-idp-oidc-extension/blob/master/roles/oidc-extension/templates/attribute-filter.xml

- Filtering claim values based on requested claim values is still missing

5. Subject Identifier

- 
https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/SubjectIDConfiguration

- Shibboleth persistent name id generation mechanism is used for 
generating subject identifier. Subject Identifier configuration is 
independent of SAML name id configuration.
--
To unsubscribe from this list send an email to