...
In this example, Mediasite requires the an attribute named "eduPersonEntitlement" attribute. What is that??
There are a few attributes that everyone understands (first name, last name). Unfortunately, these attributes are so well known that they have been used down through the years and have several different names in different standards. First name is "givenName" and last name is "sn" (short for surname) in some international standards. So Shibboleth needs to know not only the attribute, but also the name the attribute should be given. Less commonly, it also needs to know the format, so Birth Date might be January 2, 1995 or 01/02/95, or 1995-01-02.
There are other attributes that can only be understood in the context of Yale University IT systems. If the other system needs your E-Mail address to send you messages, then probably Shibboleth will want to send what Yale calls your "Primary E-Mail Alias" which is frequently Firstname.Lastname@yale.edu. However, if a user has requested Privacy (an option required by Federal law) then the user will not be listed in normal Yale directories and releasing his secret E-Mail alias may require approval. There is also a system specific E-Mail address, such as Firstname.Lastname@bulldogs.yale.edu, which is different from the generic E-Mail alias. Also, your E-Mail alias can be changed, and this can confuse certain Relying Parties, although your Netid almost never changes.
So releasing additional attributes may require a discussion with Yale ITS Identity Management to make sure that the information is being released properly, with the right attribute name, and in the right format.
If the partner provides documentation on the attributes and their formats, include a reference to it in the ServiceNow Change Request.
SAML also defines a set of named attribute formats. The problem is that a simple attribute like Netid can be reported to have format "unspecified", or it can be "a character string", and frequently someone will want it to claim to be in the format of "an E-Mail address" even when it isn't a real E-mail address. Each attribute is sent with a name and a format id, so if the Relying Party wants the format id to be a specific value Shibboleth needs to know to generate that specific format name.
The partner Metadata (or a written specification) will tell ITS just exactly how to generate the SAML boilerplate for an attribute. It does not, however, tell us which value to plug into the Attribute assertion. That requires a real discussion with a real person.
Some Relying Parties ask for "mail", the standard name for E-Mail address. Unfortunately, someone at Yale may have more than one E-Mail account (netid@pantheon.yale.edu, netid@connect.yale.edu, firstname.lastname@bulldogs.yale.edu) and may have more than one E-Mail alias (Firstname.Lastname@yale.edu, Firstname.Lastname.eliapps@yale.edu) where the alias is configured to point to a specific account. Over time, the alias may be redefined to point to a different account (if a user's mail migrates), and the alias name may change. Most people at Yale have no idea how complex this can be, and yet when you are making decisions about how Yale interacts with an external partner you have to configure a result that will work for everyone, not just for the simple cases. This is why even seemingly simple attributes sometimes have to be discussed with ITS Identity Management to choose the right value to release from the set of available options.
The Netid
If the Shibboleth SAML Response is a "letter of introduction", then it has a Subject. Unless requested otherwise, Shibboleth will automatically include the Netid of the user as the Subject.
...