Date: Thu, 28 Mar 2024 14:22:50 +0000 (UTC) Message-ID: <959200004.6509.1711635770453@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6508_78543129.1711635770451" ------=_Part_6508_78543129.1711635770451 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page lists several of the known OpenID to SAML gateway implementati= ons, and provides information about how they operate.
UW-Madison chose to go the path of defining separate IdP entities for ea= ch of the supported social identity providers for a development instance of= a Social2SAML service. The solution was developed with an earlier re= lease of SimpleSAMLphp and the latest version would make the implementation= much simpler. We currently have support for Google, Facebook and Twi= tter. When combined with the Shib SP 2.4+ Embedded Discovery Service,= and our own SAML metadata provider, this gives us a way to list the social= providers as if they were any other SAML IdP in the selection drop-down bo= x.
----------
UW-Madison''s Soc2SAML gateway
-----
Twitter:
Shib-Application-ID default
Shib-Session-ID _0ad867d6e583e8f5f897bd102e97f15f
Shib-Identity-Provider https://panda.doit.wisc.edu/idp/twitter
Shib-Authentication-Instant 2012-08-27T15:00:13Z
Shib-Authentication-Method urn:oasis:names:tc:SAML:2.0:ac:classes:Password=
Shib-AuthnContext-Class urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Shib-Session-Index _0eeb7aae8714bf1115a36911662025165295a75ae5
Shib-Assertion-Count 00
cn khazelton
displayName khazelton
eppn 16xxxxxx@twitter.com
persistent-id [https://panda.doit.wisc.edu/idp/twitter]! [https://persepol=
is.wisc.edu/shibboleth-sp]! 8a6bxxxxxxb2a5599564655df607f99e7b220c29
-----
Facebook:
Shib-Application-ID default
Shib-Session-ID _280ef30bdbb6b3d74407bcd98e9a55fc
Shib-Identity-Provider https://panda.doit.wisc.edu/idp/facebook
Shib-Authentication-Instant 2012-08-27T15:04:42Z
Shib-Authentication-Method urn:oasis:names:tc:SAML:2.0:ac:classes:Password=
Shib-AuthnContext-Class urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Shib-Session-Index _901fc506235ea6bb89c77a09d7385b9c1065869297
Shib-Assertion-Count 00
cn Keith D Hazelton
displayName Keith D Hazelton
eppn 100002457xxxxxx@facebook.com
givenName Keith
mail khazelton@gmail.com
persistent-id [https://panda.doit.wisc.edu/idp/facebook]! [https://persepo=
lis.wisc.edu/shibboleth-sp]! 725fxxxxxx5afc40fc1af43131c027cac474deda
sn Hazelton
-----
Google:
Value
Shib-Application-ID default
Shib-Session-ID _d602f68653201efbd494d278c5f02b8d
Shib-Identity-Provider https://panda.doit.wisc.edu/idp/google
Shib-Authentication-Instant 2012-08-27T15:07:23Z
Shib-Authentication-Method urn:oasis:names:tc:SAML:2.0:ac:classes:Password=
Shib-AuthnContext-Class urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Shib-Session-Index _6375bb12c3e643580fe4e7b4e710f66cbcd4af4c94
Shib-Assertion-Count 00
cn Keith Hazelton
displayName Keith Hazelton
eppn 58159e6705c4df4eedafce4b56xxxxxx@google.com
givenName Keith
mail khazelton@gmail.com
persistent-id [https://panda.doit.wisc.edu/idp/google]! [https://persepoli=
s.wisc.edu/shibboleth-sp]! dac0xxxxxx2b374401d64924f2b5874b8d691eeb
sn Hazelton
The IDCorral Shibboleth IdP Proxy is a proof-of-concept for proxying Ope= nID login for Shibboleth-enabled applications. Since it is only a proof-of-= concept, it was implemented with JanRain Engage as the mechanism by which a= user selects his/her ID provider. JanRain Engage also aggregates OpenID/OA= uth/Facebook Connect into a unified API so that the implementing service = =E2=80=93 in this case the Shibboleth IdP proxy =E2=80=93 has a consistant = set of attributes to work with.
The original writeup on this concept can be found here: http://luc= asrockwell.com/other/idpproxy.html
What attributes does the external IDP offer? =
|
The attributes which JanRain Engage offeres u= p for each provider are listed here: https://rpxnow.com/docs/providers = td> |
What attributes do you ask for? |
All of the attributes listed under "Basic Pro= file" are returned regardless. |
Which attributes require user consent ? |
All of them. |
Given Name |
givenName (urn:oid:2.5.4.42) |
Family Name |
sn (urn:oid:2.5.4.4) |
Display Name |
cn (urn:oid:2.5.4.3) (This should be changed = to displayName) |
Verified Email |
mail (urn:oid:0.9.2342.19200300.100.1.3) <= /td> |
Preferred Username |
eduPersonPrincipalName* (urn:oid:1.3.6.1.4.1.= 5923.1.1.1.6) |
*At this time, the eduPersonPrincipalName is set by the user the first t= ime he/she logs in, and the Preferred Username is used as a guide for setti= ng this information. The Preferred Username can not be taken at face value = because it is not guaranteed to be unique.
The Apache module, "Apache2::AuthAny" was developed as an extensible aut= hentication/authorization system. The module currently protects the Distrib= ute project at https://isds-auth.cirg.washington.edu/di= stribute/index.php
Apache2::AuthAny creates a set of authentication URLs, one for each prov= ider, that are separate from the location of the protected content. A demo = with documentation is available at https://authany.cirg.washington.edu
The production version of AuthAny only supports Google authentication th= rough OpenID with the Google email being passed (through AX). The architect= ure allows any authentication mechanism to be used however, so if another p= rovider is added that passes other attributes, they could potentially be st= ored in the AuthAny database, and passed through to the protected applicati= on.
IdPproxy was developed as an proxy authentication system, to bridge the = divide between SAML2 federations and Social Media. It only works one way, t= hat is it uses Social Media to authenticate persons to SAML2 federation. &n= bsp;
The focus has all the time been on authentication, gathering identity in= formation has always been more of a 'nice if we get some'. The reason for t= his is of course the level of assurance that you get for this information. = IdPproxy today supports Facebook, Google, Twitter, general OpenID and Windo= ws Live ID. It does not ask for any attributes outside what these services = provide by-default. Hence, we have, so far, not tried to find out what= is possible to get out of them.
IdPProxy does some transformations of information received from Social M= edia, like constructing a displayName from given name and family name if no= full name was given. It also constructs an eduPersonPrincipalName from an = identifier provided by the service and the domain name of the service.
Below is the template to use for listing attributes from the external Id= P.
What attributes does the external IDP offer? =
|
|
What attributes do you ask for? |
|
Which attributes require user consent ? |
|
(name of input attribute) |
repeat this row for each input attribute. Thi=
s column should contain the name, value, syntax, and semantics of the SAML =
attribute that you assert using this input value. |
Extract from above:
openid.sreg.nickname |
Any UTF-8 string that the End User wants to u= se as a nickname. [Note: The Profile's Label for this attribute is "A= lias/Username."] |
openid.sreg.email |
The email address of the End User as specifie= d in section 3.4.1 of RFC2822 |
openid.sreg.fullname |
UTF-8 string free text representation of the = End User's full name |
openid.sreg.dob |
The End User's date of birth as YYYY-MM-DD. A=
ny values whose representation uses fewer than the specified number of digi=
ts should be zero-padded. The length of this value MUST always be 10. If th=
e End User user does not want to reveal any particular component of this va=
lue, it MUST be set to zero. |
openid.sreg.gender |
The End User's gender, "M" for male, "F" for = female |
openid.sreg.postcode |
UTF-8 string free text that SHOULD conform to= the End User's country's postal system |
openid.sreg.country |
The End User's country of residence as specif= ied by ISO3166 |
openid.sreg.language |
End User's preferred language as specified by= ISO639 |
openid.sreg.timezone |
ASCII string from TimeZone database |