Shibboleth Developers

["Scott Cantor" <>]

> I'd like to stay somewhat focused on the "elements of the profiling
> activity" that were apparently very important to the goals of the Shib
> community. Its immaterial to me whether they are expressed in the form of
> SAML1.1 or SAML2.

The "profiling" that Shibboleth did can be divided into things that were 
technical contributions to SAML and those that are simply community norms and 
practices that were interesting to the educational community. The latter 
aren't really Shibboleth, they're just things that the people deploying 
Shibboleth use it to do and are defined totally outside it and apply just as 
much to any other SAML product.

The "Shibboleth profile" you're talking about is only a SAML 1.1 thing. It 
was subsumed by SAML 2.0 and there is nothing on the wire that Shibboleth 
adds to what SAML 2.0 defines.

So it does matter quite a bit which you use in the sense that with SAML 1.1, 
you probably need to be working in the context of the Shibboleth profile to 
get anything done with Shibboleth-using sites, whereas sites deploying 
Shibboleth 2.0 and SAML 2.0 should be on more equal footing. My point being 
that talking about "Shibboleth interop" in the context of SAML 2.0 is no 
different than talking about Sun Access manager interop, etc.

> We can start with SAML2, if you prefer, so long as
> messages can be made to be consistent with the SAML messages/flows used in
> the Drummond Group's interoperability testing of (the many) commercial SAML2
> server implementations.

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.

You MAY wish to examine the other profiles that the MACE/I2MI community and 
other Shibboleth-using communities have developed (e.g. eduPerson), but 
that's a quite distinct body of ongoing work.

> If we can make a hookup between Shib and OpenID2 via SAML2 ,I'd be happy to
> engage in an experimental-grade connection.

Technically this is not difficult, but I would submit (and have) that there's 
no reason one *has* to use a gateway to do this vs. just adding OpenID 
support to the Shibboleth IdP software (and/or SP for that matter). If 
there's demand and/or programmers to do it, it will certainly happen. I think 
it may be happening already, actually.

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

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

> Second, the connection should leverage the
> persistent nameid protocol, where an additional "shib" attribute may
> optionally contain the user's local id on the IDP, coded as common string.

I'm not sure why that would be useful or desired. Using a federated alias 
implies a desire for privacy; why undermine it?

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

> 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