By default the following attributes will be released to a correctly configured and authenticated MIT SP.
If you use the standard attribute-map.xml file in the 2.x Shibboleth SP, they are mapped to the environment/header names indicated:
• eppn (AKA eduPersonPrincipalName), typically also mapped to REMOTE_USER (e.g. johndoe@mit.edu)
• affiliation (eduPersonScopedAffiliation, i.e. staff@mit.edu, student@mit.edu, or affiliate@mit.edu)
• unscoped-affiliation (eduPersonAffiliation, i.e. staff, student, or affiliate)
• primary-affiliation (eduPersonPrimaryAffiliation, i.e. staff, student, or affiliation)
• displayName (e.g. John Q Doe)
• nickname (eduPersonNickname, deprecated, new applications should use displayName)
• mail (currently always username@mit.edu)
The SP itself will also pass the following internal values to the application:
• Shib-Identity-Provider (e.g. https://idp.mit.edu/shibboleth)
• Shib-Authentication-Method (e.g. urn:oasis:names:tc:SAML:2.0:ac:classes:SoftwarePKI)
• Shib-AuthnContext-Class (e.g. urn:oasis:names:tc:SAML:2.0:ac:classes:SoftwarePKI)
• Shib-Application-ID (e.g. default)
• Shib-Authentication-Instant (e.g. 2010-12-15T16:21:46.888Z)
• Shib-Session-ID (e.g. _514488c547ac735ec8f17a96999ea1f2)
The affiliation is not disclosed via certificates that are used today, however a web application can easily look it up via ldap, or get the data from the warehouse. Releasing this via Shibboleth will help to get some application developers thinking about how to use assertions in the future.
The following additional information could be released to a correctly configured and authenticated MIT SP if business requirement is identified and an SLA is created.
• givenName (e.g. John)
• sn (AKA surname, e.g. Doe)
• telephoneNumber (e.g. 617-253-xxxx)
Clearly there is no reason to release the phone number by default. If someone had a third party application that expected to receive the phone number via this mechanism, and they had a business for the data, we might be willing to let them have it. If we're already giving them the displayName, the rest of the data that we can easily provide is redundant.
The following information will be released to a correctly configured and authenticated external SP by default:
• affiliation (eduPersonScopedAffiliation, e.g. staff@mit.edu)
• unscoped-affiliation (eduPersonAffiliation, e.g. staff)
• primary-affiliation (eduPersonPrimaryAffiliation, e.g. staff)
By default we will not release the username or full name to another site by default, but simply indicating that the user authenticated at our IdP and they have a given affiliation can be useful to some applications while not invading the user's privacy.
The following information may be released to a correctly configured and authenticated external SP after IS&T review and approval:
• eppn (eduPersonPrincipalName e.g. johndoe@mit.edu)
• affiliation (eduPersonScopedAffiliation, e.g. staff@mit.edu)
• unscoped-affiliation (eduPersonAffiliation, e.g. staff)
• primary-affiliation (eduPersonPrimaryAffiliation, e.g. staff)
• displayName (e.g. John Q Doe)
• nickname (eduPersonNickname, deprecated, new applications should use displayName)
• mail (currently always username@mit.edu)
Each attribute would be on a case by case basis.