...
| Tip |
|---|
...
subject-id
...
| ||
The MyAccessID IAM Service supports the Research and Scholarship (R&S) Entity Category. As such, MyAccessID expects |
...
to receive the R&S attribute bundle |
...
from IdPs in eduGAIN supporting the R&S Entity Category. |
| Tip | ||
|---|---|---|
| ||
As a service that meets the requirements for and supports the entity category of Code of Conduct, the |
...
service specifically declares the attributes it requires. |
| Attribute Type | Attribute | Requirement | Explanation |
|---|---|---|---|
| User Identifier |
| Mandatory (at least one) | MyAccessID and the services connected through MyAccessID require to uniquely identify users. Without a unique identifier, it is not possible to distinguish two different users between each other |
. As a service that supports Sirtfi, it is required that it is able to uniquely identify users. |
pairwise-id
eduPersonPrincipalName1
eduPersonTargetedID
eduPersonUniqueId
Level of Assurance information will become mandatory in 2022
Access to services connected to PUHURI is allowed only with use of identities that fulfill certain identity assurance criteria.
To express the required assurance levels, the REFEDS Assurance suite https://wiki.refeds.org/display/ASS is used.
Requirements are defined for two aspects of identity assurance:
- Identifier uniqueness to ensure unambiguous identification of users;
- Identity proofing and credential issuance, renewal, and replacement to ensure that identity trustworthy represents right natural person.
Level of assurance for an identity issued to a user is expressed at the time of user authentication by the IdP sending eduPersonAssurance attribute with following values:
1 The i) the IdP supports the R&S Enitity Category, ii) the |
iii) the federation in which the IdP has registered has a policy that prohibits the reassignment of the value of the | |||
| |||
| |||
| |||
| |||
| Level of Assurance | eduPersonAssurance | Will become mandatory (date TBD) | Access to the services connected through MyAccessID will be dominantly supported by identities coming from the IdPs from the R&E sector and |
eduGAIN. See Level of Assurance Requirements for more information. | |
Name |
|
| Mandatory (at least one |
| ) | MyAccessID and the services connected through MyAccessID expect to receive the name of the user. For example, when a user applies for a new project or for membership membership to an existing project, the managers need to be able to recognise who the applicant |
is |
. |
As a service that meets the requirements for and supports the entity category of Code of Conduct, the service specifically declares the attributes required to use the service
displayName | ||
| ||
| Mandatory |
MyAccessID needs to be able to contact the user regarding the status of their account. |
As a service that meets the requirements for and supports the entity category of R&S, it is expected to receive the R&S attribute bundle, which includes the mail.
As a service that meets the requirements for and supports the entity category of Code of Conduct, it specifically declares the attributes required to use the service. As a service that supports Sirtfi, it is required that it is able to contact users.In addition, many of the services connected through MyAccessID expect the email of the user in order to be able contact the user about service related matters. |
| Affiliation |
| Mandatory | Access to many of the |
services connected through MyAccessID |
relies on authorising their member users based on |
affiliation |
with their home organisation. |
As a service that meets the requirements for and supports the entity category of R&S, it is expected to receive the R&S attribute bundle, which includes the eduPersonScopedAffiliation.
As a service that meets the requirements for and supports the entity category of Code of Conduct, the service specifically declares the attributes required to use the service| Organization | schacHomeOrganization | Optional | Access to many of the |
services connected through MyAccessID |
relies on authorising users based on their home organisation. |
As a service that meets the requirements for and supports the entity category of Code of Conduct, the service specifically declares the attributes required to use the service.
Depending on which protocol the IdP is using, SAML or OIDC, attributes need to be released in the following format, respectively.:
- SAML Attribute Names
SAML Attributes MUST be sent using urn:oasis:names:tc:SAML:2.0:attrname-format:uri NameFormat. Below is the list of the canonical names of the SAML attributes:
| SAML Attribute Name | SAML Attribute Friendly Name |
|---|---|
urn:oasis:names:tc:SAML:attribute:subject-id | subject-id |
urn:oasis:names:tc:SAML:attribute:pairwise-id | pairwise-id |
urn:oid:0.9.2342.19200300.100.1.3 | |
urn:oid:1.3.6.1.4.1.25178.1.2.9 | schacHomeOrganization |
urn:oid:1.3.6.1.4.1. |
5923. |
1.1. |
1 |
.6 |
| eduPersonPrincipalName | |
|
|
eduPersonScopedAffiliation |
urn:oid:1.3.6.1.4.1.5923.1.1.1. |
10 |
eduPersonTargetedID |
urn:oid:1.3.6.1.4.1.5923.1.1.1. |
11 |
| eduPersonAssurance |
urn:oid:1.3.6.1.4.1.5923.1.1.1. |
13 |
| eduPersonUniqueId |
|
|
| eduPersonOrcid | |
urn:oid:2.5.4.3 | cn |
urn:oid:2.5.4.4 | surname |
urn:oid:2.5.4.42 | givenName |
- OIDC
...
- Claims and Scopes
| OIDC Claim | Scope |
|---|---|
| subject-id |
| openid |
| name | profile |
| given_name | profile |
| family_name | profile |
| voperson_id | aarc |
| eduperson_entitlement | aarc |
eduperson_scoped_affiliation | aarc |
| voperson_external_affiliation | aarc |
| eduperson_assurance | aarc |
| schac_home_organization |