Attributes released by the Raven IdP: Difference between revisions

From RavenWiki
Jump to navigationJump to search
(Remove references to unregistered SPs)
No edit summary
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Following authentication, the IdP on Raven will release various attributes about the authenticated user. Most of these come from or are derived from lookup. An example [[Attribute-map.xml - internal use skeleton | attribute map]] is available for use by SPs within the University - this document assumes that this file is in use and that users are authenticating to the Raven IdP - other maps and other IdPs will behave differently. In particular, IdPs elsewhere in the UK federation are unlikely to release by default anything other than urn:mace:dir:attribute-def:eduPersonScopedAffiliation and urn:mace:dir:attribute-def:eduPersonTargetedID (and perhaps not even that).
{{New Docs}}


Each of these attributes has a formal 'name' (which appears in the protocol messages on the wire) and this is mapped, by the attribute-map.xml file, into a more useful 'id' which in turn is used to make attribute values available to web sites. How this happens depends on platform. For Apache, the 'id's are used as the names of environment variables (with all occurrences of '-' converted to '_' and with multiple values seperated by ';'). On IIS, the 'id's are used as the names of server variables.
Following authentication, the IdP on Raven will release various attributes about the authenticated user. Most of these come from or are derived from lookup. An example [[Attribute-map.xml - internal use skeleton | attribute map]] is available for use by SPs within the University - this document assumes that this file is in use and that users are authenticating to the Raven IdP - other maps and other IdPs will behave differently. In particular, IdPs elsewhere in the UK federation are unlikely to release by default anything other than <code><nowiki>urn:mace:dir:attribute-def:eduPersonScopedAffiliation</nowiki></code> and <code><nowiki>urn:mace:dir:attribute-def:eduPersonTargetedID</nowiki></code> (and perhaps not even that).
 
Each of these attributes has a formal 'name' (which appears in the protocol messages on the wire) and this is mapped, by the attribute-map.xml file, into a more useful 'id' which in turn is used to make attribute values available to web sites. How this happens depends on platform. For Apache, the 'id's are used as the names of environment variables (with all occurrences of '-' converted to '_' and with multiple values separated by ';'). On IIS, the 'id's are used as the names of server variables.
 
There are two common sets of formal names in use: one with names starting <code><nowiki>urn:mace:</nowiki></code> and one with names starting <code><nowiki>urn:oid:</nowiki></code>. In line with recommendations from the [https://www.ukfederation.org.uk/ UK Access Management Federation], the Raven IdP uses the <code><nowiki>urn:mace:</nowiki></code> format when available for responses delivered over SAMLv1, and the <code><nowiki>urn:oid:</nowiki></code> format otherwise.  


Exactly what is released will differ depend on how the SP is [[SP registration | registered]] with Raven. [[SP registration]] takes place by providing 'Metadata', which may appear either in the UK federation metadata file or in the local 'Ucam federation' one.  
Exactly what is released will differ depend on how the SP is [[SP registration | registered]] with Raven. [[SP registration]] takes place by providing 'Metadata', which may appear either in the UK federation metadata file or in the local 'Ucam federation' one.  
Common attribute definitions (including OIDs) are part of the [https://refeds.org/eduperson eduPerson] or [https://tools.ietf.org/html/rfc2798 inetOrgPerson] object classes.


==Registered, but with technical errors==
==Registered, but with technical errors==
Line 22: Line 28:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:eduPersonPrincipalName</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:eduPersonPrincipalName</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:1.3.6.1.4.1.5923.1.1.1.6</nowiki></code></td>
<td>eppn</td>
<td>eppn</td>
<td>A single persistent, unique user identifier which is consistent across all services. For a Raven user has the form <tt>''<crsid>''@cam.ac.uk</tt>. It is NOT an email address.</td>
<td>A single persistent, unique user identifier which is consistent across all services. For a Raven user has the form <tt>''<crsid>''@cam.ac.uk</tt>. It is NOT an email address.</td>
Line 28: Line 34:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:eduPersonScopedAffiliation</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:eduPersonScopedAffiliation</nowiki></code><br><code><nowiki>urn:oid:1.3.6.1.4.1.5923.1.1.1.9</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:1.3.6.1.4.1.5923.1.1.1.9</nowiki></code></td>
<td>affiliation</td>
<td>affiliation</td>
<td>One or more values indicating the authenticated user's relationship with the organisation operating the IdP. For a Raven user has the value <tt>member@cam.ac.uk</tt> for anyone who appears in lookup, and the value <tt>member@eresources.lib.ac.uk</tt> for anyone entitled to access the bulk of University Library-licensed electronic resources. New values may be added over time - applications relying on this attribute should ignore unrecognised values.</td>
<td>One or more values indicating the authenticated user's relationship with the organisation operating the IdP. For a Raven user has the value <tt>member@cam.ac.uk</tt> for anyone who appears in lookup, and the value <tt>member@eresources.lib.ac.uk</tt> for anyone entitled to access the bulk of University Library-licensed electronic resources. New values may be added over time - applications relying on this attribute should ignore unrecognised values.</td>
Line 34: Line 40:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:eduPersonEntitlement</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:eduPersonEntitlement</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:1.3.6.1.4.1.5923.1.1.1.7</nowiki></code></td>
<td>entitlement</td>
<td>entitlement</td>
<td>One or more values indicating particular entitlements. Currently includes <tt>urn:mace:dir:entitlement:common-lib-terms</tt> on behalf of anyone entitled to access the general University Library electronic resource collection. New values may be added over time - applications relying on this attribute should ignore unrecognised values.</td>
<td>One or more values indicating particular entitlements. Currently includes <tt><code><nowiki>urn:mace:dir:entitlement:common-lib-terms</nowiki></code></tt> on behalf of anyone entitled to access the general University Library electronic resource collection. New values may be added over time - applications relying on this attribute should ignore unrecognised values.</td>
</tr>
</tr>


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:eduPersonTargetedID</td>
<td>'''SAML1 as SAML1ScopedString:''' <code><nowiki>urn:mace:dir:attribute-def:eduPersonTargetedID</nowiki></code><br>'''SAML1 as SAML1XMLObject:''' <code><nowiki>urn:oid:1.3.6.1.4.1.5923.1.1.1.10</nowiki></code><br>'''SAML2 as SAML2XMLObject:''' <code><nowiki>urn:oid:1.3.6.1.4.1.5923.1.1.1.10</nowiki></code></td>
<td>targeted-id</td>
<td>targeted-id</td>
<td>A single persistent, unique user identifier which is consistent for all accesses to a particular SP by a particular user but which will be different for different users and for different services. The recommended attribute map returns this in the old, deprecated scoped format <tt>''<opaque string>''@cam.ac.uk</tt>. See https://spaces.internet2.edu/display/SHIB2/NativeSPTargetedID for discussion on this, and why it might be better to synthesise something in the persistent-id format (see below).</td>
<td>A single persistent, unique user identifier which is consistent for all accesses to a particular SP by a particular user but which will be different for different users and for different services. The recommended attribute map returns this in the old, deprecated scoped format <tt>''<opaque string>''@cam.ac.uk</tt>. See https://spaces.internet2.edu/display/SHIB2/NativeSPTargetedID for discussion on this, and why it might be better to synthesise something in the persistent-id format (see below).</td>
Line 49: Line 55:
==University SPs==
==University SPs==


Raven will additionally release the following to any SP for which it has registration data and which it recognises as being operated by the University. Note that many of these values are subject to suppression in lookup and that Raven can only release values that are not suppressed.
Raven will additionally release the following information (mainly from Lookup) to any SP for which it has registration data and which it recognises as being operated by the University. Note that access to many of these values may be restricted in Lookup -- Raven can only release values that have at least 'University Wide' visibility.
 
Note that much of the data in Lookup is under its subject's direct control and so should not be used for identification or authorisation purposes.


Note that many of these are only defined locally and it is unlikely to make any sense to accept them from IdPs other than the one provided by Raven. Indeed it could be positively dangerous to do so - for example any IdP can assert any value it likes for 'uid' and to assume that this was a correctly established CRSid would be insecure. The default Shib SP configuration described elsewhere in these pages only configures the SP to trust the Raven IdP, so in that configuration all these values could be considered trustworthy. However more care should be taken should additional IdP's (such as those in the UK federation) be added as trusted.
Note that many of these are only defined locally and it is unlikely to make any sense to accept them from IdPs other than the one provided by Raven. Indeed it could be positively dangerous to do so - for example any IdP can assert any value it likes for 'uid' and to assume that this was a correctly established CRSid would be insecure. The default Shib SP configuration described elsewhere in these pages only configures the SP to trust the Raven IdP, so in that configuration all these values could be considered trustworthy. However more care should be taken should additional IdP's (such as those in the UK federation) be added as trusted.  


<table class="wikitable" cellpadding="5">
<table class="wikitable" cellpadding="5">
Line 63: Line 71:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:sn</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:sn</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:2.5.4.4</nowiki></code></td>
<td>sn</td>
<td>sn</td>
<td>User's Surname. Single-valued.</td>
<td>User's Surname. Single-valued.</td>
Line 70: Line 78:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:cn</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:cn</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:2.5.4.3</nowiki></code></td>
<td>cn</td>
<td>cn</td>
<td>User's Registered Name. Single-valued.</td>
<td>User's Registered Name. Single-valued.</td>
Line 77: Line 85:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:displayName</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:displayName</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:2.16.840.1.113730.3.1.241</nowiki></code></td>
<td>displayName</td>
<td>displayName</td>
<td>User's Display Name. Single-valued.</td>
<td>User's Display Name. Single-valued.</td>
<td></td>
<td>3</td>
</tr>
</tr>


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:title</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:title</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:2.5.4.12</nowiki></code></td>
<td>title</td>
<td>title</td>
<td>User's Roles. Multi-valued.</td>
<td>User's Roles. Multi-valued.</td>
<td></td>
<td>3</td>
</tr>
</tr>


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:ou</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:ou</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:2.5.4.11</nowiki></code></td>
<td>ou</td>
<td>ou</td>
<td>The institutions to which the user belongs. Multi-valued.</td>
<td>The institutions to which the user belongs. Multi-valued.</td>
Line 98: Line 106:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:oid:1.3.6.1.4.1.6822.1.1.5</td>
<td>'''SAML1 and SAML2:''' <code><nowiki>urn:oid:1.3.6.1.4.1.6822.1.1.5</nowiki></code></td>
<td>instID</td>
<td>instID</td>
<td>The 'Inst ID's of the institutions to which the user belongs. Note that this may not be in the same order as the values of ou. Multi-valued.</td>
<td>The 'Inst ID's of the institutions to which the user belongs. Note that this may not be in the same order as the values of ou. Multi-valued.</td>
Line 105: Line 113:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:oid:1.3.6.1.4.1.6822.1.1.30</td>
<td>'''SAML1 and SAML2:''' <code><nowiki>urn:oid:1.3.6.1.4.1.6822.1.1.30</nowiki></code></td>
<td>jdInst</td>
<td>jdInst</td>
<td>The 'Inst ID' of the user's primary institution as shown in the Computing Service's Jackdaw database. Single-valued.</td>
<td>The 'Inst ID' of the user's primary institution as shown in University Information Services' Jackdaw database. Single-valued.</td>
<td>1</td>
<td>1</td>
</tr>
</tr>


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:telephoneNumber</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:telephoneNumber</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:2.5.4.20</nowiki></code></td>
<td>telephoneNumber</td>
<td>telephoneNumber</td>
<td>User's Telephone Numbers. Multi-valued.</td>
<td>User's Telephone Numbers. Multi-valued.</td>
<td></td>
<td>3</td>
</tr>
</tr>


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:mail</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:mail</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:0.9.2342.19200300.100.1.3</nowiki></code></td>
<td>mail</td>
<td>mail</td>
<td>User's preferred email address. Single valued.</td>
<td>User's preferred email address. Single valued.</td>
<td></td>
<td>3</td>
</tr>
</tr>


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:oid:1.3.6.1.4.1.6822.1.1.11</td>
<td>'''SAML1 and SAML2:''' <code><nowiki>urn:oid:1.3.6.1.4.1.6822.1.1.11</nowiki></code></td>
<td>mailAlternative</td>
<td>mailAlternative</td>
<td>User's other mail addresses. Multi-valued.</td>
<td>User's other mail addresses. Multi-valued.</td>
<td>1</td>
<td>1,3</td>
</tr>
</tr>


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:oid:1.3.6.1.4.1.6822.1.1.38</td>
<td>'''SAML1 and SAML2:''' <code><nowiki>urn:oid:1.3.6.1.4.1.6822.1.1.38</nowiki></code></td>
<td>misAffiliation</td>
<td>misAffiliation</td>
<td>User's 'status' within the University. Possible values are <tt>staff</tt> and/or <tt>student</tt>. New values may be added over time - applications relying on this attribute should ignore unrecognised values. Note: the coverage of this attribute is known to be incomplete - anyone with the value <tt>student</tt> probably is a student (for some definition thereof); anyone without this may or may not be. Ditto for 'staff'. Multi-valued.</td>
<td>User's 'status' within the University. Possible values are <tt>staff</tt> and/or <tt>student</tt>. New values may be added over time - applications relying on this attribute should ignore unrecognised values. Note: the coverage of this attribute is known to be incomplete - anyone with the value <tt>student</tt> probably is a student (for some definition thereof); anyone without this may or may not be. Ditto for 'staff'. Multi-valued.</td>
Line 140: Line 148:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:oid:1.3.6.1.4.1.6822.1.1.22</td>
<td>'''SAML1 and SAML2:''' <code><nowiki>urn:oid:1.3.6.1.4.1.6822.1.1.22</nowiki></code></td>
<td>groupTitle</td>
<td>groupTitle</td>
<td>The names of the lookup groups to which the user belongs. Multi-valued. Note the availability of this attribute is subject to both the user's choice of suppression and the group administrator's.</td>
<td>The names of the lookup groups to which the user belongs. Multi-valued. Note the availability of this attribute is subject to both the user's choice of suppression and the group administrator's.</td>
Line 147: Line 155:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:oid:1.3.6.1.4.1.6822.1.1.22</td>
<td>'''SAML1 and SAML2:''' <code><nowiki>urn:oid:1.3.6.1.4.1.6822.1.1.22</nowiki></code></td>
<td>groupID</td>
<td>groupID</td>
<td>The groupID of the lookup groups to which the user belongs. Multi-valued. Note the availability of this attribute is subject to both the user's choice of suppression and the group administrator's. Note that this may not be in the same order as the values of groupTitle.</td>
<td>The groupID of the lookup groups to which the user belongs. Multi-valued. Note the availability of this attribute is subject to both the user's choice of suppression and the group administrator's. Note that this may not be in the same order as the values of groupTitle.</td>
Line 154: Line 162:


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:oid:1.3.6.1.4.1.5923.1.1.1.10</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:uid</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:0.9.2342.19200300.100.1.1</nowiki></code></td>
<td>persistent-id</td>
<td>uid</td>
<td>An alternate form of a persistent, unique user identifier which is consistent for all accesses to a particular SP by a particular user but which will be different for different users and for different services (c.f. targeted-id above). See https://spaces.internet2.edu/display/SHIB2/NativeSPTargetedID for background to this duplication.</td>
<td>User's CRSid (centrally-managed University user ID). Consider using 'eppn' when accepting authentications from multiple IdPs.</td>
<td>1</td>
<td>2</td>
</tr>
 
</table>
 
==Selected other SPs==
 
Raven can additionally release the following information (mainly from Lookup) but will only do so to particular SPs by arrangement. Note that access to many of these values may be restricted in Lookup -- Raven can only release values that have at least 'University Wide' visibility. Note that much of the data in Lookup is under its subject's direct control and so should not be used for identification or authorisation purposes.
 
<table class="wikitable" cellpadding="5">
 
<tr align="left" valign="top">
<th>Name</th>
<th>Id</th>
<th>Description</th>
<th>Notes</th>
</tr>
</tr>


<tr align="left" valign="top">
<tr align="left" valign="top">
<td>urn:mace:dir:attribute-def:uid</td>
<td>'''SAML1:''' <code><nowiki>urn:mace:dir:attribute-def:initials</nowiki></code><br>'''SAML2:''' <code><nowiki>urn:oid:2.5.4.43</nowiki></code></td>
<td>uid</td>
<td>initials</td>
<td>User's CRSid (centrally-managed University user ID). Consider using 'eppn' when accepting authentications from multiple IdPs.</td>
<td>User's Initials. Single-valued. Extracted heuristically from 'Registered Name' on lookup and depends on that field being in the expected format, and on 'Registered Name' having a visibility of at least 'University'.</td>
<td>2</td>
<td></td>
</tr>
</tr>


</table>
</table>


Notes:
== Notes ==


1. Locally defined attribute - unlikely to be meaningful or trustworthy except when asserted by the Raven IdP.
1. Locally defined attribute - unlikely to be meaningful or trustworthy except when asserted by the Raven IdP.


2. Standardised attribute, but used for a specific local purpose. Could easily be used for a different or conflicting purpose by IdPs other than that provided by Raven.
2. Standardised attribute, but used for a specific local purpose. Could easily be used for a different or conflicting purpose by IdPs other than that provided by Raven.
3. User-managed attribute - do not use for identification or authorisation purposes.

Latest revision as of 11:42, 3 March 2020

We're working on improving Raven resources for developers and site operators.

Try out the new Raven documentation for size.

Following authentication, the IdP on Raven will release various attributes about the authenticated user. Most of these come from or are derived from lookup. An example attribute map is available for use by SPs within the University - this document assumes that this file is in use and that users are authenticating to the Raven IdP - other maps and other IdPs will behave differently. In particular, IdPs elsewhere in the UK federation are unlikely to release by default anything other than urn:mace:dir:attribute-def:eduPersonScopedAffiliation and urn:mace:dir:attribute-def:eduPersonTargetedID (and perhaps not even that).

Each of these attributes has a formal 'name' (which appears in the protocol messages on the wire) and this is mapped, by the attribute-map.xml file, into a more useful 'id' which in turn is used to make attribute values available to web sites. How this happens depends on platform. For Apache, the 'id's are used as the names of environment variables (with all occurrences of '-' converted to '_' and with multiple values separated by ';'). On IIS, the 'id's are used as the names of server variables.

There are two common sets of formal names in use: one with names starting urn:mace: and one with names starting urn:oid:. In line with recommendations from the UK Access Management Federation, the Raven IdP uses the urn:mace: format when available for responses delivered over SAMLv1, and the urn:oid: format otherwise.

Exactly what is released will differ depend on how the SP is registered with Raven. SP registration takes place by providing 'Metadata', which may appear either in the UK federation metadata file or in the local 'Ucam federation' one.

Common attribute definitions (including OIDs) are part of the eduPerson or inetOrgPerson object classes.

Registered, but with technical errors

No attributes are released. This is a common failure mode and suggests that Raven is finding metadata about the SP but that this doesn't match reality.

Registered SPs

Raven will release the following to any SP for which it has registration data:

Name Id Description
SAML1: urn:mace:dir:attribute-def:eduPersonPrincipalName
SAML2: urn:oid:1.3.6.1.4.1.5923.1.1.1.6
eppn A single persistent, unique user identifier which is consistent across all services. For a Raven user has the form <crsid>@cam.ac.uk. It is NOT an email address.
SAML1: urn:mace:dir:attribute-def:eduPersonScopedAffiliation
urn:oid:1.3.6.1.4.1.5923.1.1.1.9
SAML2: urn:oid:1.3.6.1.4.1.5923.1.1.1.9
affiliation One or more values indicating the authenticated user's relationship with the organisation operating the IdP. For a Raven user has the value member@cam.ac.uk for anyone who appears in lookup, and the value member@eresources.lib.ac.uk for anyone entitled to access the bulk of University Library-licensed electronic resources. New values may be added over time - applications relying on this attribute should ignore unrecognised values.
SAML1: urn:mace:dir:attribute-def:eduPersonEntitlement
SAML2: urn:oid:1.3.6.1.4.1.5923.1.1.1.7
entitlement One or more values indicating particular entitlements. Currently includes urn:mace:dir:entitlement:common-lib-terms on behalf of anyone entitled to access the general University Library electronic resource collection. New values may be added over time - applications relying on this attribute should ignore unrecognised values.
SAML1 as SAML1ScopedString: urn:mace:dir:attribute-def:eduPersonTargetedID
SAML1 as SAML1XMLObject: urn:oid:1.3.6.1.4.1.5923.1.1.1.10
SAML2 as SAML2XMLObject: urn:oid:1.3.6.1.4.1.5923.1.1.1.10
targeted-id A single persistent, unique user identifier which is consistent for all accesses to a particular SP by a particular user but which will be different for different users and for different services. The recommended attribute map returns this in the old, deprecated scoped format <opaque string>@cam.ac.uk. See https://spaces.internet2.edu/display/SHIB2/NativeSPTargetedID for discussion on this, and why it might be better to synthesise something in the persistent-id format (see below).

University SPs

Raven will additionally release the following information (mainly from Lookup) to any SP for which it has registration data and which it recognises as being operated by the University. Note that access to many of these values may be restricted in Lookup -- Raven can only release values that have at least 'University Wide' visibility.

Note that much of the data in Lookup is under its subject's direct control and so should not be used for identification or authorisation purposes.

Note that many of these are only defined locally and it is unlikely to make any sense to accept them from IdPs other than the one provided by Raven. Indeed it could be positively dangerous to do so - for example any IdP can assert any value it likes for 'uid' and to assume that this was a correctly established CRSid would be insecure. The default Shib SP configuration described elsewhere in these pages only configures the SP to trust the Raven IdP, so in that configuration all these values could be considered trustworthy. However more care should be taken should additional IdP's (such as those in the UK federation) be added as trusted.

Name Id Description Notes
SAML1: urn:mace:dir:attribute-def:sn
SAML2: urn:oid:2.5.4.4
sn User's Surname. Single-valued.
SAML1: urn:mace:dir:attribute-def:cn
SAML2: urn:oid:2.5.4.3
cn User's Registered Name. Single-valued.
SAML1: urn:mace:dir:attribute-def:displayName
SAML2: urn:oid:2.16.840.1.113730.3.1.241
displayName User's Display Name. Single-valued. 3
SAML1: urn:mace:dir:attribute-def:title
SAML2: urn:oid:2.5.4.12
title User's Roles. Multi-valued. 3
SAML1: urn:mace:dir:attribute-def:ou
SAML2: urn:oid:2.5.4.11
ou The institutions to which the user belongs. Multi-valued.
SAML1 and SAML2: urn:oid:1.3.6.1.4.1.6822.1.1.5 instID The 'Inst ID's of the institutions to which the user belongs. Note that this may not be in the same order as the values of ou. Multi-valued. 1
SAML1 and SAML2: urn:oid:1.3.6.1.4.1.6822.1.1.30 jdInst The 'Inst ID' of the user's primary institution as shown in University Information Services' Jackdaw database. Single-valued. 1
SAML1: urn:mace:dir:attribute-def:telephoneNumber
SAML2: urn:oid:2.5.4.20
telephoneNumber User's Telephone Numbers. Multi-valued. 3
SAML1: urn:mace:dir:attribute-def:mail
SAML2: urn:oid:0.9.2342.19200300.100.1.3
mail User's preferred email address. Single valued. 3
SAML1 and SAML2: urn:oid:1.3.6.1.4.1.6822.1.1.11 mailAlternative User's other mail addresses. Multi-valued. 1,3
SAML1 and SAML2: urn:oid:1.3.6.1.4.1.6822.1.1.38 misAffiliation User's 'status' within the University. Possible values are staff and/or student. New values may be added over time - applications relying on this attribute should ignore unrecognised values. Note: the coverage of this attribute is known to be incomplete - anyone with the value student probably is a student (for some definition thereof); anyone without this may or may not be. Ditto for 'staff'. Multi-valued. 1
SAML1 and SAML2: urn:oid:1.3.6.1.4.1.6822.1.1.22 groupTitle The names of the lookup groups to which the user belongs. Multi-valued. Note the availability of this attribute is subject to both the user's choice of suppression and the group administrator's. 1
SAML1 and SAML2: urn:oid:1.3.6.1.4.1.6822.1.1.22 groupID The groupID of the lookup groups to which the user belongs. Multi-valued. Note the availability of this attribute is subject to both the user's choice of suppression and the group administrator's. Note that this may not be in the same order as the values of groupTitle. 1
SAML1: urn:mace:dir:attribute-def:uid
SAML2: urn:oid:0.9.2342.19200300.100.1.1
uid User's CRSid (centrally-managed University user ID). Consider using 'eppn' when accepting authentications from multiple IdPs. 2

Selected other SPs

Raven can additionally release the following information (mainly from Lookup) but will only do so to particular SPs by arrangement. Note that access to many of these values may be restricted in Lookup -- Raven can only release values that have at least 'University Wide' visibility. Note that much of the data in Lookup is under its subject's direct control and so should not be used for identification or authorisation purposes.

Name Id Description Notes
SAML1: urn:mace:dir:attribute-def:initials
SAML2: urn:oid:2.5.4.43
initials User's Initials. Single-valued. Extracted heuristically from 'Registered Name' on lookup and depends on that field being in the expected format, and on 'Registered Name' having a visibility of at least 'University'.

Notes

1. Locally defined attribute - unlikely to be meaningful or trustworthy except when asserted by the Raven IdP.

2. Standardised attribute, but used for a specific local purpose. Could easily be used for a different or conflicting purpose by IdPs other than that provided by Raven.

3. User-managed attribute - do not use for identification or authorisation purposes.