Shibboleth Developers

[Peter Williams <>]

Scott:

 

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

 

Find a pdf attached. It screenshots an incomplete, OpenID2 Relying Party interaction. I chose the relying party site specficially  - to be in nature as "un-academic" and "un-telecommunications" and "un-corporate" as possible (so far).

 

As one can perhaps see, the site was attempting to bind a so-called  "directed OpenID" to its local identifier account. (This openid is derived from the SAML2 persistent NameID protocol run used by the gateway) One can also see that none of the openid "sreg" form-filling properties are present in the site's local account signup wizard, consistent with the presumed desire of many a wandering-eyed male seeking out partners via a dating site, semi-anonymously.

 

If we can make a hookup between Shib and OpenID2 via SAML2 ,I'd be happy to engage in an experimental-grade connection. 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. The site's SSL certificate chould chain to a root present by default in common consumer web browsers, such as FF or IE. 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. We can even experiment with character sets, including ગુજરાતી (Gujǎrātī). Third, optionally, we might sign SAML requests over Redirect binding, and post back a positive SAML response that shall be signed.

 

How does this first phase proposal sound?  It feels like about like 4-8 hours of effort. 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.

 

_________________________
Peter Williams
Mobile (805) 416-6305

---

From: Scott Cantor
Sent: Tue 3/18/2008 6:20 PM
To:
Subject: RE: OpenID2 to SAML2 to SAML1.1 ... to Shib, anyone?

> With suitable technical wizardry, I've little doubt that we can now bridge
> the gateways SAML1.1 endpoints to Shib endpoints - given Shib is a profile
> of the SAML1.1 standard.

Shibboleth is many things. That particular definition is fairly out of date.
The second generation of Shibboleth software already supports SAML 2.0 as
of, well, now, and any basis for interop should probably start there. If you
have a SAML 2 gateway, you're done, at least protocol-wise (ignoring my
general opinion of gateways).

> If we can accomplish the above, two worthwhile goals will have been met:
(1)
> the grassroots-centric OpenID standards process will gain direct access to
> the federation trust modeling work perfected in Shib

I would suspect that that's a more fruitful line of inquiry than the fairly
trivial issue of gatewaying between protocols.

> and (2) if the
> approach were to be adopted by the Shib community, academic users with
Shib
> credentials would be able to exploit them on the fast emerging OpenID-
> enabled sites.

No offense, but what are those exactly?

It's also fair to say there isn't a single uniform Shibboleth community.
You'll get a lot of different perspectives on the idea.

-- Scott

Attachment: openid1.pdf
Description: openid1.pdf