openid plugin and attributes

[Cantor, Scott]

On 3/2/16, 4:50 PM, "dev on behalf of Paul Hethmon" <dev-bounces at shibboleth.net on behalf of paul.hethmon at clareitysecurity.com> wrote:



>I’m close to finishing up my OpenID Connect plug-in for Shib and have some choices relating to releasing attributes. My philosophy has been to maintain minimal configuration for OpenID, instead pulling what I can from the Shib configuration. So one thought on managing attribute release is to represent each OIDC RP as a SAML RP.

The IdP really doesn't deal in SAML RPs, it deals in RPs. Be them CAS, SAML, OIDC. All the machinery is geared to that.

If you want to establish the identity of that RP in a weak or non-existent way, that's a deployment choice, but you should separate those concerns, and the MetadataResolver API is a good way to do that. That API is based on SAML metadata, but it doesn't require using SAML metadata. The people that would like to reinvent can do what they like, and they will because that's their raison d'etre, but I don't see any compelling reason to do so since SAML's model accomodates any protocol.

> So from a configuration viewpoint, you would add a metadata file for each OIDC RP and configure attribute release as normal.

That is, as I say, not a given, even if you used the actual metadata API.

> The OIDC plugin would request authentication as that SAML RP when it received the corresponding OIDC authentication request.

I'm not sure what you mean by that, but taken literally, I wouldn't do that.

> The win would be the Shib attribute engine controlling the attribute release. The loss would be maintaining a fake/proxy metadata file for each OIDC RP.

I would use the metadata API, I wouldn't necessarily do anything fake, but I also wouldn't dismiss it out of hand because it doesn't have to be fake. If you need endpoints and keys, you need metadata.

Our CAS support will hopefully end up doing similar things.

-- Scott

>