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