openid plugin and attributes

[Paul Hethmon]

> On Mar 2, 2016, at 5:31 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> 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 I will take a closer look at the 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.

I’ve got the OIDC component loosely coupled with Shib at the moment. So it’s aware of Shib and can dig into the Relying Party manager/api to pull out relevant information. It uses that to determine the IdP metadata for one. It also grabs the public/private key for use as the same in OIDC.

Right now, it also identifies one Shib RP that is itself. From this the flow works by it publishing OIDC endpoints like

	https://idp.example.com/idp/openid/authorization
	https://idp.example.com/idp/openid/token

So its servlet is receiving the actual inbound OIDC request. For an authentication request, it takes the inbound OIDC data, uses pieces of it, and then creates a SAML AuthnRequest to the co-resident IdP for authentication. So whatever authentication mechanism is used by the IdP is used and the IdP also ends up creating its session with that browser. The SAML Response is consumed by another OIDC servlet which validates the response and from the data in it, creates the OIDC data.

So I’ve created a proxy between OIDC and SAML. My point today was to take that another step and actually be a corresponding SAML RP for each OIDC RP. For each RP pair, the OIDC proxy would receive the correct set of attributes to release.

I went down this path for a couple of reasons. The first is I’m still running Shib v2 and I wanted a model/plugin I could use now for v2 and later this year for v3. The second reason is that I wasn’t aware of a way to trigger the current flows in Shib for a different protocol. If I can do that, I’m definitely interested in going there. I feel I’m fairly familiar with the v2 stuff, mostly on the login handler and attribute models. I never had a reason to go deep into the profile handlers. I haven’t looked at v3 architecture at all.

So if I can add a profile handler and insert myself into the core of Shib via configuration (ie internal.xml, handler.xml, etc) I’m definitely game to go there. All of the OIDC stuff I’ve done could easily move into handler for either v2 or v3. To me that would be a big win since it would consolidate configuration. The RPs can be either protocol and Shib keeps their metadata as it does all metadata. I could drop the entire “proxy” part I’ve built, simplifying code and speeding up the overall process.

> 
>> 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.

Without a doubt.

-----
Paul Hethmon
Chief Software Architect
paul.hethmon at clareitysecurity.com