Page History
...
Since the ESI won't be available in the exact format required by the ESI specification we'll provide examples that dynamically generate the ESI based on the uid attribute (coming from the id="myLDAP" DataConnector). In this example the uid attribute is expected to have values of the form "x<MATRIKELNR>" where <MATRIKELNR> is the student's Austrian immatriculation number so that we can extract a useable form of the immatriculation number from the uid attribute using regular expressions. Any other values not matching the given pattern will lead to an empty ESI attribute which will ultimetely not be released by the IDP:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<AttributeDefinition id="schacPersonalUniqueCode" xsi:type="Mapped">
<InputDataConnector ref="myLDAP" attributeNames="uid" />
<DisplayName xml:lang="de">Europäische Studierendenkennung (ESI)</DisplayName>
<DisplayName xml:lang="en">European Student Identifier (ESI)</DisplayName>
<ValueMap>
<ReturnValue>urn:schac:personalUniqueCode:int:esi:at:$1</ReturnValue>
<SourceValue>^x([0-9]{8,})$</SourceValue>
</ValueMap>
<AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.25178.1.2.14" friendlyName="schacPersonalUniqueCode" encodeType="false" />
</AttributeDefinition> |
...
In case you have the immatriculation number available in its own attribute already (i.e., no regular expression matching is needed to extract it from other data; below we'll assume use of a ficticious matrikelnummer attribute looked up from LDAP) you could use a "Template" attribute definition instead of the "Mapped" one above:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<AttributeDefinition id="schacPersonalUniqueCode" xsi:type="Template">
<InputDataConnector ref="myLDAP" attributeNames="matrikelnummer" />
<DisplayName xml:lang="de">Europäische Studierendenkennung (ESI)</DisplayName>
<DisplayName xml:lang="en">European Student Identifier (ESI)</DisplayName>
<Template>urn:schac:personalUniqueCode:int:esi:at:${matrikelnummer}</Template>
<AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.25178.1.2.14" friendlyName="schacPersonalUniqueCode" encodeType="false" />
</AttributeDefinition> |
Finally, institutions that do not manage immatriculation numbers for their students but that still need to provide the ESI attribute can use the following example to dynamically generate ESI values from any other locally available identifier (below again assuming use of the uid attribute), combining it with the canonical DNS Domain of the institution (cf. the Attribute-"Scope" for all eduID.at IDPs):
| Code Block | ||||
|---|---|---|---|---|
| ||||
<AttributeDefinition id="schacPersonalUniqueCode" xsi:type="Template">
<InputDataConnector ref="myLDAP" attributeNames="uid" />
<DisplayName xml:lang="de">Europäische Studierendenkennung (ESI)</DisplayName>
<DisplayName xml:lang="en">European Student Identifier (ESI)</DisplayName>
<Template>urn:schac:personalUniqueCode:int:esi:%{idp.scope}:${uid}</Template>
<AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.25178.1.2.14" friendlyName="schacPersonalUniqueCode" encodeType="false" />
</AttributeDefinition> |
...
eduPersonEntitlement is a container for all kinds of values and data, usually only with clearly defined values within specific communities. One notable exception is its global use for location-independent, off-campus authorisation to Library Services. Here's a simple example that should work for most deployments, giving all subjects you have declared to have an eduPersonAffilliation of member earlier (see above) or of library-walk-in (someone physically present in library premises) the common-lib-terms entitlement, thereby stating that these all are entitled to access licensed resources on behalf of your organisation, according to the "common library licensing terms" (again, see Library Services for details):
| Code Block | ||||
|---|---|---|---|---|
| ||||
<AttributeDefinition id="eduPersonEntitlement" xsi:type="Mapped">
<InputAttributeDefinition ref="eduPersonAffiliation" />
<ValueMap>
<ReturnValue>urn:mace:dir:entitlement:common-lib-terms</ReturnValue>
<SourceValue>member</SourceValue>
<SourceValue>library-walk-in</SourceValue>
</ValueMap>
</AttributeDefinition> |
...
We can amend the previous example above to do both: Assign the common-lib-terms entitlement to all members and library-walk-in users, and also assert that all your subjects with the an affiliation of faculty have had their identity sufficiently verified that they can all request personal certificates via TCS. You'll need to adapt that second part as needed, depending on what parts of your community you intend to offer the TCS personal service to. I.e., for TCS we just add the second ValueMap to the above config, resulting in this example:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<AttributeDefinition id="eduPersonEntitlement" xsi:type="Mapped">
<InputAttributeDefinition ref="eduPersonAffiliation" />
<ValueMap>
<ReturnValue>urn:mace:dir:entitlement:common-lib-terms</ReturnValue>
<SourceValue>member</SourceValue>
<SourceValue>library-walk-in</SourceValue>
</ValueMap>
<ValueMap>
<ReturnValue>urn:mace:terena.org:tcs:personal-user</ReturnValue>
<SourceValue>faculty</SourceValue>
</ValueMap>
<ValueMap>
<ReturnValue>https://acomarket.ac.at/academic-ai</ReturnValue>
<SourceValue>member</SourceValue>
</ValueMap>
</AttributeDefinition> |
...
Overview
Content Tools
Tasks