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