February 2010 - DG-Concordia - mailman.kantarainitiative.org

No Concordia call
by Paul Madsen 23 Feb '10

23 Feb '10

Apologies for late notice but as we decided last call to keep the surveys open till post-RSA, and the only other agenda item from that call was the SAML/OpenID deployment guide - I'm proposing we cancel today's call in anticipation of the Portland meetings. Paul

1 0

Re: [DG-Concordia] Rev of Deployment Guideline for Proxying SAML & OpenID
by Joost Van Dijk 09 Feb '10

09 Feb '10

On 2/9/10 7:42 PM, Scott Cantor wrote: > Joost Van Dijk wrote on 2010-02-09: >> In this scheme, a user presenting an OpenID URL like >> >> https://openid.surfnet.nl/myuniversity/john >> >> would be redirected by the RP first to our gateway, then to the SAML IDP >> mapped from 'myuniversity', where the user needs to authenticate as >> 'john'. After returning on the gateway, before being sent back to the >> RP, it is checked that it was actually john who logged in. > > Ok, so your gateway is basically creating OpenIDs that facilitate mapping. I > was wondering also what the opposite direction looked like. How do your > (originally SAML) RPs handle OpenID users? Do they get EPPNs? SAML NameIDs? > Handle both types of IDs? > > -- Scott > > When accessing a SAML SP that allows guests, a user selects "OpenID" from the list of IDPs on the SP's WAYF. This entry points to the gateway, that will simply allow the user to enter his/her OpenID URL. In the checkid_setup request to the OpenID Provider, some attributes are requested using sreg or AX. If these are released in the response, they are mapped onto the SAML attributes used by the SAML SP. This list is now restricted to the following attributes: urn:mace:dir:attribute-def:uid urn:mace:dir:attribute-def:cn urn:mace:dir:attribute-def:displayName urn:mace:dir:attribute-def:mail The OpenID URL is mapped onto both the SAML subject and the uid attribute. By the way: this gateway is based on Feide's simpleSAMLphp, which is often used for bridging. -- Joost

1 0

Re: [DG-Concordia] Rev of Deployment Guideline for Proxying SAML & OpenID
by Joost Van Dijk 09 Feb '10

09 Feb '10

On 2/9/10 6:06 PM, Scott Cantor wrote: > Joost Van Dijk wrote on 2010-02-09: >> 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. > > I'd be interested to know how and whether you harmonized identifiers. Did > you just force everything into OpenID/URL syntax for user identification, or > do applications handle different identifier types? > > -- Scott > > We basically made a one-to-one mapping between OpenID URLs and a combination of SAML entity ID / subject. As these can get rather ugly, we also tried a more static mapping with the IDPs domain name and it's user's uid. In this scheme, a user presenting an OpenID URL like https://openid.surfnet.nl/myuniversity/john would be redirected by the RP first to our gateway, then to the SAML IDP mapped from 'myuniversity', where the user needs to authenticate as 'john'. After returning on the gateway, before being sent back to the RP, it is checked that it was actually john who logged in. We're still experimenting with alternatives. One extreme is to forget about all SAML attribute mapping to OpenID's sreg or AX, use OpenID 2.0's identifier select feature to circumvent the OpenID URL mapping problem and release privacy-preserving obfuscated URLs to RPs. This would of course limit usefulness somewhat, but avoids a lot of the hairiness... both protocol-wise and policy-wise. -- Joost

2 1

Fwd: Re: Rev of Deployment Guideline for Proxying SAML & OpenID
by Paul Madsen 09 Feb '10

09 Feb '10

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(a)surfnet.nl> To: Paul Madsen <paulmadsen(a)rogers.com> CC: Hans Zandbelt <hans.zandbelt(a)surfnet.nl>, Scott Cantor <cantor.2(a)osu.edu>, 'kantara Initiative' <dg-concordia(a)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(a)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 >> >> >

1 0

Re: [DG-Concordia] Rev of Deployment Guideline for Proxying SAML & OpenID
by Scott Cantor 09 Feb '10

09 Feb '10

Joost Van Dijk wrote on 2010-02-09: > 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. I'd be interested to know how and whether you harmonized identifiers. Did you just force everything into OpenID/URL syntax for user identification, or do applications handle different identifier types? -- Scott

1 0

KI F2F
by Paul Madsen 09 Feb '10

09 Feb '10

Who is attending? Paul

1 0

Rev of Deployment Guideline for Proxying SAML & OpenID
by Paul Madsen 09 Feb '10

09 Feb '10

Hi, I've had an AI for a while to rev the deployment guideline to reflect the SAML LOA profile and the ICAM OpenID profile. New version at http://kantarainitiative.org/confluence/display/concordia/Deployment+Guide+… When the SAML LOA profile becomes available for public review, I'd hope Concordia can vote this doc out for the same Thanks Paul

3 4

Agenda for February 9 Concordia DG call
by Paul Madsen 08 Feb '10

08 Feb '10

- Tuesday, 09 Feb 2010 - EST 1:30-2:30pm - Skype: +9900827044630912 - North American Dial-In: +1-201-793-9022 | Room Code: 4630912 - International numbers are on Concordia DG wiki page 0) Roll 1) Approval of minutes from last call http://kantarainitiative.org/confluence/display/concordia/Call+Jan+26+2010 2) Surveys - status (Joni) - fish or cut bait 3) Proxying assurance for OpenID/SAML guidelines - latest draft (Paul) - http://bit.ly/dpbMeU - related Japanese PoC (Tatsuki?) - list discussion - next steps? 4) AOB

1 0

Re: [DG-Concordia] Rev of Deployment Guideline for Proxying SAML & OpenID
by Paul Madsen 05 Feb '10

05 Feb '10

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

2 2

Re: [DG-Concordia] Rev of Deployment Guideline for Proxying SAML & OpenID
by Tatsuki Sakushima 05 Feb '10

05 Feb '10

Hi Scott, So, does a Shibboleth just act as an OP in the meantime of acting a SAML IDP? Tatsuki Sakushima NRI Pacific - Nomura Research Institute America, Inc. (2/5/10 11:36 PM), 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 > >

2 1