For eduID.at members we recommend the following mapping to eduPerson-standardised values:
faculty
: wissenschaftliches Personalstaff
: allgemeines Personal, oder sämtliches Personal, wenn wissenschaftliches Personal nicht existiert oder nicht unterschieden werden kannemployee
: sämtliche/s Angestellten/Personalstudent
: Studierendemember
: if the subject has any (i.e., at least one) of the above affiliations, plus possibly other subjects that fit the eduPerson-defined criteria formember
.alum
: for alumnæ/alumni (former graduates), if available in the same Identity Management systems your IDP accesses.affiliate
: only if none of the above are applicable but you still need to express some kind of defined relationship with the organisation, i.e.affiliate
should not be assigned if the subject has any of the above affiliations. Note that it's perfectly fine to not assign any affiliation value, though, so often no value will be sufficient (and is semantically equivalent to "none of the defined values") and therefore preferable over ma(r)king thoseaffiliate
gratuitously.library-walk-in
: Special case only relevant for IDPs that need to support "patrons" of their public libraries (and where the accessed resources rely solely on SAML attributes for authorisation puposes, which is still very rare). That may include subjects with (only) a library card, or subjects physically present in a library location, e.g. based on IP address.
Don't use this for authorisation to licensed content if the provider can also accept the common-lib-terms entitlement instead, c.f. Library Services. And of course you don't need to worry about this at all if accessed resources allow authorisation based on location (IP address ranges), as the physical library location itself will already be sufficient to allow access. Also if proxies, tunnels or VPNs are in use (to make remote subjects appear to be coming from the local data network) this affiliation – and SAML attributes and WebSSO itself – usually does not matter at all.
Out of those 8 affiliations only a few are common or useful in inter-institiutional (i.e., federated) contexts. All eduID.at IDPs should be able to create at least the following affiliation values for their relevant communities:
student
faculty
, if possible/applicable, otherwisestaff
and/oremployee
member
Covering more affiliations certainly will not hurt and maybe you have other (non-federation or not even SAML-related) local use-cases for more values and clear assignment rules for all the different kinds of communities you have to cater for. But there is no need to cover all of the values for some of them to be useful to the services that rely on them.
Before relying on affiliation values for federated authorisation take into account the findings from the REFEDS whitepaper on eduPersonAffiliation use on what values to use or avoid, especially in cross-/international contexts and projects/services spanning cultures and/or federations.
Examples:
- Our IDP 3 Attribute resolution documentaton shows how to create and populate this attribute.
- In eduID.at the popular u:book services rely on eduPersonScopedAffiliation (ePSA) for authorization purposes, and also offers certain privileges (e.g. payment methods) only to some affiliations
- Some Library Services don't support the standard "common-lib-terms" entitlement and instead authorize subjects based on ePSA. Use only "
member
" with those to keep things simple. - USI Wien (the University Sports Institute) uses ePSA for the determination of the price someone has to pay for a course, in combination with an eduPersonEntitlement attribute value (stating that the subject is eligible for student discount based on her age).