Or dependent on which model your federation follows, into your national IdP's metadata. The following metadata needs to be imported:
2. Provide your own federation metadata or metadata set to portal operations
- eduPersonPrincipalName. This eduPersonPrincipalName needs to contain a globally unique persistent tag. Typically examples are 'email@example.com' or 'firstname.lastname@example.org'. This is not a mail address. The '@university.country' takes care of global uniqueness; the text in the first part might be a username or an administration number. Persistence means that once a particular principalName has ever been used for a person, it must not ever be used for another person. If you can not fulfill that requirement in your federation (for instance due to the way you construct your NetID), you may tell portal-operations to bootstrap your federation with another attribute for the unique identifier, such as eduPersonTargetedID. You must communicate that in the beginning, at least before any certificates have been issued to members of your constituency, because otherwise the namespace will be in flux, which is unacceptable.
- eduPersonEntitlement, containing urn:mace:terena.org:tcs:escience-user and/or urn:mace:terena.org:tcs:personal-user. Note: this value must only be set for users that are guaranteed to have a passport-verified identity! People need not be re-authenticated using passport if that was done earlier. Test identities are strictly forbidden, as are pseudonyms.
- Additionally, for the NREN and Subscriber admins, the values urn:mace:terena.org:tcs:escience-admin/urn:mace:terena.org:tcs:personal-admin are required.
- schacHomeOrganization OR eduPersonOrgDN identifying the institution/subscriber of the person within the NREN. E.g. for schacHomeOrganization "uvt.nl", or for eduPersonOrgDN "o=Hogwarts, dc=hsww, dc=wiz". It is also possible to use the scope from the ePPN as an organizational identifier, if you do not have multi-domain institutions or the IdP's entityID if there is a one to one relationship between subscribers and IdPs
- some representation of the full name (e.g.: 'cn', but can be differently named attribute). This full name will be the Common Name of the issued certificate. Examples of a Common Name: "S. Kramer" or "Thijs Nijssen".
- the user's email address (e.g.: attribute 'mail', but can be a differently named attribute). Email addresses end up in the certificate. On a per NREN base, the portal can be configured to support more than one mail address.
A scary, lengthy, verbose form will appear. Don't panic, most of it is rather self-explaining. However, the first two steps are rather involved. In the section "Attribute name", enter the subscriber name as it is exported by the subscriber's IdP.
Next, you want to determine the organization name as it will go into the DN. That is really the string that will follow after the /O=... part of the certificate's subjectDN. Enter a more or less arbitrary value here, but think wisely before choosing it. Any change of the name will result in revocation of all certificates that were issued with that org-name. So you should choose a name for the subscriber that can stay stable over a longer period of time. In the eScience portal, that name will also be subject to Grid restrictions. I.e. it will only be allowed to contain ASCII characters and its length will be limited to 62 characters: