Shibboleth Developers

[Peter Williams <>]

 

Let me try to be more clear: there is no Shibboleth profile anymore. We have a SAML implementation, the same as any other (well, hopefully better, but that's the goal of any product).

This message has generally failed to overcome the historical notion of what Shibboleth is, sometimes to our advantage from a marketing PoV, but for the purposes of what you're asking about, it matters a great deal that you understand this. You need do nothing specific to Shibboleth in your work.

 

Has the community addressed the particular use case that an "InCommon-participating" university with a commercial (non-Shib-project) SAML2 endpoint may seek to rely on assertions from a college operating only the traditional shib endpoints (particularly for the next year, or so)?

 

Do the rules for InCommon allow for a participant to offer SAML2 endpoints that (a) are provided for by a SAML2 implementation other than that from the Shib development team, and (b) may put user in the position of being unable to interwork with other InCommon participants still using the Shib-profile of SAML1.1?

 

Does this use case call out for bridging gateways - between SAML1.1 (shib profile) endpoints and SAML2 endpoints?

 

I'm thinking here of many a UK university's registrar departments, whose SAP systems can infact (for $$) participate in the SAML2 world - and would logically want to interwork with the deployed Shib infrastructure when managing central records.

> First, the entityIDs used in the
> bridging trial should be https URLs, at which SAML2 signed metadata should
> be present for use in auto-discovery of SAML2 metadata. Said metadata should
> contain the entity's self-signed X.509 v3 certificate.

Understood. Signed by who?

Let's make the entity self-sign its metadata, using the key associated with the cert in the metadata.

> The site's SSL
> certificate chould chain to a root present by default in common consumer web
> browsers, such as FF or IE.

I much prefer rejecting the notion that this false sense of security contributes much to the equation. I'll use my usual counter-example: anybody at OSU can get a commercial certificate for any domain name in the ohio-state.edu or osu.edu domains, whether or not they control that domain name. Ergo, they're worthless for authentication (in fact worse, since people assume things that they would not assume in the absence of a certificate).

That said, I'm sure you'll find takers for the idea.

Lets play with the public CA rule first, and then remove it. My vendor has biased their auto-discovery process for https channels assured "by well known public CAs". Rather than fight that bias, lets run with it for a first trial. Then, we will try remove the bias, which is based on a general thesis that has yet to be well tested: use one set of trust channels (those assured by public CAs) to bootstrap peer-to-peer trust in the self-signed entity metadata.

> How does this first phase proposal sound?  It feels like about like 4-8
> hours of effort.

I agree, doubt it would be much more than that. I also don't have it to give right now, but hopefully you'll find some takers. I'm just trying to provide some technical context for you in your work here and I'll continue to do so when I can.

I download the Shib SAML2 IDP. I'm attempting to use it on Windows 2003, whose install was (predictably) not easy or seamless. Ill see where I can get, by myself. it will be the 7th SAML implementation we interwork with in the US realty websso space. ( 2 of those are open source: a simple servlet wrapper around opensaml2 from the National Association of Realtors for the Java crowd, and simpleSAML being another for the php crowd).

 

I'll then turn back to the issue of interworking (via gatewaying) with those InCommon members who continue to use Shib software earlier than v2.

> Note, we will have little control over where invited
> participants may choose to wander on the web, once s/he has an OpenID. The
> second phase may then consider that very issue, seeking to limit by a
> federation's trust model the behaviour of the OpenID2 gateway.

I believe Caleb mentioned the UK's work in this area. Lots of people are certainly thinking about the implications of OpenID's approach to federation (I utterly reject the view that OpenID is "different", "user-centric", or anything other than yet another federation protocol.)

-- Scott

 

Our Openid implementation (based on gatewaying) took about 36h of additional programming work, to map the obvious signals between the 2 stacks. Our work was architected to be a pure protocol engine, one that simply delegates to a particular (common) flow within the SAML2 protocol. This would support the position that openid2 is just another protocol/binding delivering the sp-initiated websso profile. This is particularly true if SAML entities support auto-discovery of metadata, addressing openid2 main claim to fame: the auto-discovery model. However, having now built the concept, there certainly are valid counter arguments, I've found. There are various topics worthy of formal research concerning OpenID interaction with SAML's model, above and beyond implementing bits of software.

To cite the phrasing choices of SUN Microsystems folk, openid can be described as a lightweight websso protocol. That is: lightweight OpenID2 is to SAML2 what lightweight LDAP (once) was to the X.500 Directory Access Protocol. Just as Tim Howe's first LDAP listener was nothing more than a layer 7 gateway to an actual X.500 DSA running OSI layer 4-7 protocols, so our OpenID bridge is a gateway to SAML2. One day, perhaps soon, the bridging and gateway architecture will no longer have any need to exist. With the likes of the simpleSAML2 implementation, relying parties operators may well find that native support for SAML2 is as viable and easy to provide for as is providing for openid2. Having built a network of about 25 realty players from scratch in the last year - based off of the momentum achieved by the Shib community - I can attest that SAML need be neither expensive nor difficult.