# IdP Operational Requirements

## Purpose of this document

This document defines identity management and system operation requirements and recommendations for Identity Providers joining the HREF Federation.

Throughout this document the interpretation of terms **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT** are defined as:

* **MUST** (or **SHALL**, **REQUIRED**): the definition is an absolute requirement of the specification in order to build and keep trust in the federation.
* **MUST NOT**: the definition is an absolute prohibition of the specification
* **SHOULD** (or **RECOMMENDED**): there may be valid reasons for ignoring the definition, however, the divergence from the specification **MUST** be documented
* **SHOULD NOT** (or **NOT RECOMMENDED**): there may be valid reasons for the particular behaviour to be acceptable, however, the divergence from the specification **MUST** be documented

## Identity management

1. The organisation operating the Identity Provider **MUST** document its privacy policy and make it available to its users.
1. The organisation **MUST** define the sources, the maintenance procedures and approximate quality of the data about its users, and supply this documentation to the Federation.
1. Uniqueness of the usernames **MUST** be guaranteed.
1. One individual **SHOULD NOT** have more than one user accounts.
1. Role accounts (such as 'director', 'secretary') **SHOULD NOT** be used.
1. Use of attributes:
	1. Attribute implementations **MUST** follow the Attribute Specification.
	1. The Identity Provider **MUST** implement the following attributes:
		* eduPersonTargetedID
		* eduPersonScopedAffiliation
		* schacHomeOrganizationType
		* eduPersonPrincipalName
	1. The Identity Provider **SHOULD** implement the following attributes:
		* displayName
		* mail
		* eduPersonEntitlement
	1. The IdP **MUST** ensure that eduPersonTargetedID and eduPersonPrincipalName are not re-assignable.
1. Limitation of test accounts:
	1. all test accounts **MUST** be identified and documented along with the individual who is responsible for the test account
	1. real transactions **MUST NOT** be initiated by test accounts
	1. test accounts **SHOULD** be distinguished with appropriate homeOrganizationType value.
1. User credentials (i.e. passwords) **MUST NOT** be transmitted over public network in unencrypted form.
1. If initial user passwords are distributed, it **SHOULD** be done through non-electronic form
1. Changes in the users' affiliation to the institution **MUST** be populated to the IdP database within *7 days*
	1. If the authoritative source of user information is an external database (i.e. student information system), then the above timeframe starts from the time of the change in the primary system.
	1. Students may use 'alum' affiliation after leaving the organisation. Values 'student' or 'member' **MUST NOT** be used afterwards.
	1. For faculty members and employees, affiliation values 'staff', 'employee', 'faculty' and 'member' **MUST** be revoked.

## Service management

1. The organisation **MUST** develop a role responsible for liaison with the Federation Operator.
1. The organisation operating the Identity Provider **MUST** provide end-user support for its affiliated users and have them informed about the availability of the support.
1. The organisation **MUST** provide the following data to the Federation Operator as anonymous daily statistics about the Identity Provider usage:
	* number of unique users;
	* number of transactions initiated to each federation service;
	* total number of logins.

## Operational issues

1. Any transaction including personal data **MUST** be logged and log files **SHALL** be kept for at least *30 days*.
	1. The log files above **MUST** be treated in accordance with the applicable data protection laws.
1. Cryptographic keys of the Identity Provider **MUST** be at least *2048 bits* long.
	1. Private keys **MUST** be protected.
	1. In case of a key compromise, the Federation Operator **MUST** be notified within 24 hours.
	1. Use of self-signed certificates with a long expiration time is **RECOMMENDED**.
1. Use of SAML:
	1. The Identity Provider **MUST** comply with the *Interoperable SAML 2.0 Web Browser SSO Deployment Profile* ([http://saml2int.org](http://saml2int.org))
	1. It is **RECOMMENDED** to support *SAML2 Web Browser SSO Profile* over HTTP Artifact Binding.
	1. It is **RECOMMENDED** to support *SAML2 Single Logout Profile* over HTTP Redirect and SOAP Bindings.
1. All SAML endpoints of the Identity Provider **SHALL** be protected by HTTPS.
1. All SAML endpoints of the Identity Provider **MUST** be under a DNS domain which is possessed by the operating organisation.
1. All scopes used by the Identity Provider **MUST** be under a DNS domain which is possessed by the operating organisation.