Specifies the person's affiliation within a particular security domain in broad categories such as |
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 for member
.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 those affiliate
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.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, otherwise staff
and/or employee
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:
member
" with those to keep things simple.