Forwarding -------- Original Message -------- Subject: Re: [DG-Concordia] Rev of Deployment Guideline for Proxying SAML & OpenID Date: Tue, 09 Feb 2010 17:54:38 +0100 From: Joost Van Dijk <joost.vandijk@surfnet.nl> To: Paul Madsen <paulmadsen@rogers.com> CC: Hans Zandbelt <hans.zandbelt@surfnet.nl>, Scott Cantor <cantor.2@osu.edu>, 'kantara Initiative' <dg-concordia@kantarainitiative.org> On 2/5/10 5:07 PM, Paul Madsen wrote:

Thanks Hans,

Joost, any and all info is appreciated

Hi Paul, Basically what we did is that we built two gateways: (1) bridging an A-Select SP and an OpenID Provider (2) bridging a SAML IDP and an OpenID RP, and Some context information: SURFnet is the dutch NREN and operates an Identity Management Federation called SURFfederatie. It joins the dutch HigherEd/Research institutions as both IDPs and SPs, and selected commercial SPs. Its architecture is somewhat different from completely distributed federations like InCommon, in that we use a central hub capable of doing protocol translation. This is important for our community, because there are many different IdM product/protocol combinations in use at our institutions. Using this approach, we can basically support any product as long as it features Shibboleth 1.3/2.0, SAML 2.0, A-Select, or ADFS/WS-Fed. So, for example, an A-Select IDP can connect to a SAML 2.0 SP through the central hub. The OpenID gateways facilitate two use-cases that are important to our community: (@1): the first gateway facilitates SSO for the users from our federation when visiting OpenID RPs outside of our federation. SURFnet already acts as a trusted third party for our users, so users do not need to maintain additional accounts with external "untrusted" OpenID Providers. A-Select is used here for historical reasons: a SAML-OpenID bridge would work just as well due to the nature of our federation. (@2): the second gateway facilitates collaboration between users from our federation and users external to our federation. Although our federation provides access to members of our community exclusively, some services we provide ourselves (i.e. SURFnet as an SP) can facilitate such collaboration through a "self-service" IDP (which is not connected to our federation, but which is connected to our SP). The gateway provides an alternative to running such an IDP, by letting any OpenID Provider act as a SAML IDP connected to our SP. As for the mappings between OpenID and SAML/A-Select - these are fairly simple. No policy mappings of any kind, just authentication and some attribute mappings. If you want me to elaborate more on these gateways, please let me know. -- Joost

Regards

Paul

p.s. in Dutch federations, are the Idp& SP expected to cover their own deployment costs? http://bit.ly/CdaNb :-)

On 2/5/2010 10:31 AM, Hans Zandbelt wrote:

...

Hi,

Paul Madsen wrote, On 2/5/10 3:47 PM:

...

A while back I had a brief thread with SURFNet's Joost Van Dijk about some PoC work there that involved OpenID& SAML proxying. The deployment guideline seemed of interest , albeit a bit early at the moment.

As it happens, Joost (cc.) is finishing his report (in Dutch) on that PoC today. If you're interested, you can contact him. I bet he wouldn't mind to provide some comments in English to you on the results.

Regards,

Hans Zandbelt - SURFnet/SURFfederatie

...

In addition to SURFnet, Joost pointed me to Spain's RedIRIS - http://yo.rediris.es/ (although its not clear to me that its SAML& OpenID that are being bridged, or OpenID and the internal PAPI....)

Paul

On 2/5/2010 9:36 AM, Scott Cantor wrote:

...

Tatsuki Sakushima wrote on 2010-02-05:

...

Sorry for not so active to updating this document. I have heard that InCommon or Internet2 is experimenting SAML/OpenID interop similar to what this document covers. They might focus more on authentication assertions not authentication policies. Do you know about the experiment?

Hmm, I don't know what you're referring to (and I'd know). We don't tend to do gateways, and other than Shibboleth starting to implement some OpenID code in the IdP, there's nothing else I can think of that would fit your description.

-- Scott

No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2668 - Release Date: 02/04/10 14:35:00

------------------------------------------------------------------------

_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia

No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2669 - Release Date: 02/05/10 02:35:00