Le nom des attributs SAML n'est pas normalisé, seuls les identifiants numériques le sont. Et même si la présence d'un attribut facultatif FriendlyName dans le message transmis par l'IdP au SP peut laisser supposer le contraire, c'est en fait la configuration spécifique du SP qui va décider comment cette valeur va être identifiée avant d'être transmise à l'application.

Par exemple, avec ce message:

<Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <AttributeValue>prenom.nom@domaine.tld</AttributeValue>
</Attribute>

Et cette configuration d'extraction des attributs du SP:

<Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="eppn">
    <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/>
</Attribute>
<Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName" id="eppn">
    <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/>
</Attribute>

Le couple clé/valeur transmis à l'application sera:

eppn = prenom.nom@domaine.tld

De plus, le mécanisme de transport utilisé entre le SP et l'application (variables d'environnement, ou entête HTTP), ainsi que le langage ou le framework utilisé, vont influencer également sur le nom de cette clé:

• PHP capitalise le nom des entêtes HTTP, et leur ajoute un préfixe 'HTTP_'
• Apache remplace les caractères '-' par '_' dans le nom des variables d'environnement
• …

L'attribut de l'exemple précédent sera effectivement transmis par le proxy au serveur amont sous la forme d'une entête HTTP classique:

eppn: prenom.nom@domaine.tld

Mais sera visible d'une application PHP sous la forme:

$_SERVER["HTTP_EPPN"] = "prenom.nom@domaine.tld"

Pour plus de détails à ce sujet, voir la documentation officielle.