„IdP Operational Requirements” változatai közötti eltérés

Innen: KIFÜ Wiki
(Purpose of this document)
(finalise changes)
8. sor: 8. sor:
 
:* '''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
 
:* '''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
  
== Identitás-menedzsment ==
+
== Identity management ==
# The organization operating the Identity Provider '''MUST''' document its privacy policy and make it available to its users.
+
# The organisation operating the Identity Provider '''MUST''' document its privacy policy and make it available to its users.
# The organization '''MUST''' define the sources, the maintenance procedures and approximate quality of the data about its users, and supply this documentation to the Federation.
+
# 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.
 
# Uniqueness of the usernames '''MUST''' be guaranteed.
 
# Uniqueness of the usernames '''MUST''' be guaranteed.
 
# One individual '''SHOULD NOT''' have more than one user accounts.
 
# One individual '''SHOULD NOT''' have more than one user accounts.
# Role accounts '''SHOULD NOT''' be used.
+
# Role accounts (such as 'director', 'secretary') '''SHOULD NOT''' be used.
 
# Use of attributes:
 
# Use of attributes:
## Attribute implementations '''MUST''' follow the Attribute Specification
+
## Attribute implementations '''MUST''' follow the Attribute Specification.
 
## The Identity Provider '''MUST''' implement the following attributes:
 
## The Identity Provider '''MUST''' implement the following attributes:
 
##* eduPersonTargetedID
 
##* eduPersonTargetedID
30. sor: 30. sor:
 
## real transactions '''MUST NOT''' be initiated by test accounts
 
## real transactions '''MUST NOT''' be initiated by test accounts
 
## test accounts '''SHOULD''' be distinguished with appropriate homeOrganizationType value.
 
## test accounts '''SHOULD''' be distinguished with appropriate homeOrganizationType value.
# User credentials (i.e. passwords) '''MUST NOT''' be transmitted on public network in unencrypted form.
+
# User credentials (i.e. passwords) '''MUST NOT''' be transmitted over public network in unencrypted form.
# Initial user passwords '''SHOULD''' be distributed through non-electronic form
+
# If initial user passwords are distributed, it '''SHOULD''' be done through non-electronic form
 
# Changes in the users' affiliation to the institution '''MUST''' be populated to the IdP database within ''7 days''
 
# Changes in the users' affiliation to the institution '''MUST''' be populated to the IdP database within ''7 days''
## If the authoritative source of user information is an external database (i.e. studenti information system), then the above limit starts from the time of the change in the primary system.
+
## 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.
## Students may use 'alum' affiliation after leaving the organization. Values 'student' or 'member' '''MUST NOT''' be used afterwards.
+
## Students may use 'alum' affiliation after leaving the organisation. Values 'student' or 'member' '''MUST NOT''' be used afterwards.
 
## For faculty members and employees, affiliation values 'staff', 'employee', 'faculty' and 'member' '''MUST''' be revoked.
 
## For faculty members and employees, affiliation values 'staff', 'employee', 'faculty' and 'member' '''MUST''' be revoked.
  
 
== Service management ==
 
== Service management ==
# The organization '''MUST''' develop a role responsible for liaison with the Federation Operator.
+
# The organisation '''MUST''' develop a role responsible for liaison with the Federation Operator.
# The organization operating the Identity Provider '''MUST''' provide end-user support for its affiliated users and have them informed about the availability of the support.
+
# 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.
# The organization '''MUST''' provide the following data to the Federation Operator as anonymous daily statistics about the Identity Provider usage:
+
# 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 unique users;
 
#* number of transactions initiated to each federation service;
 
#* number of transactions initiated to each federation service;
46. sor: 46. sor:
  
 
== Operational issues ==
 
== Operational issues ==
# Any transaction including personal data '''MUST''' be logged and log files '''SHALL''' be kept for at least 30 days.
+
# Any transaction including personal data '''MUST''' be logged and log files '''SHALL''' be kept for at least ''30 days''.
 
## The log files above '''MUST''' be treated in accordance with the applicable data protection laws.
 
## The log files above '''MUST''' be treated in accordance with the applicable data protection laws.
# Cryptographic keys of the Identity Provider '''MUST''' be at least 2048 bit long.
+
# Cryptographic keys of the Identity Provider '''MUST''' be at least ''2048 bits'' long.
 
## Private keys '''MUST''' be protected.
 
## Private keys '''MUST''' be protected.
 
## In case of a key compromise, the Federation Operator '''MUST''' be notified within 24 hours.
 
## In case of a key compromise, the Federation Operator '''MUST''' be notified within 24 hours.

A lap 2011. szeptember 27., 16:21-kori változata

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.
  2. 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.
  3. Uniqueness of the usernames MUST be guaranteed.
  4. One individual SHOULD NOT have more than one user accounts.
  5. Role accounts (such as 'director', 'secretary') SHOULD NOT be used.
  6. Use of attributes:
    1. Attribute implementations MUST follow the Attribute Specification.
    2. The Identity Provider MUST implement the following attributes:
      • eduPersonTargetedID
      • eduPersonScopedAffiliation
      • schacHomeOrganizationType
      • eduPersonPrincipalName
    3. The Identity Provider SHOULD implement the following attributes:
      • displayName
      • mail
      • eduPersonEntitlement
    4. The IdP MUST ensure that eduPersonTargetedID and eduPersonPrincipalName are not re-assignable.
  7. Limitation of test accounts:
    1. all test accounts MUST be identified and documented along with the individual who is responsible for the test account
    2. real transactions MUST NOT be initiated by test accounts
    3. test accounts SHOULD be distinguished with appropriate homeOrganizationType value.
  8. User credentials (i.e. passwords) MUST NOT be transmitted over public network in unencrypted form.
  9. If initial user passwords are distributed, it SHOULD be done through non-electronic form
  10. 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.
    2. Students may use 'alum' affiliation after leaving the organisation. Values 'student' or 'member' MUST NOT be used afterwards.
    3. 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.
  2. 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.
  3. 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.
  2. Cryptographic keys of the Identity Provider MUST be at least 2048 bits long.
    1. Private keys MUST be protected.
    2. In case of a key compromise, the Federation Operator MUST be notified within 24 hours.
    3. Use of self-signed certificates with a long expiration time is RECOMMENDED.
  3. Use of SAML:
    1. The Identity Provider MUST comply with the Interoperable SAML 2.0 Web Browser SSO Deployment Profile (http://saml2int.org)
    2. It is RECOMMENDED to support SAML2 Web Browser SSO Profile over HTTP Artifact Binding.
    3. It is RECOMMENDED to support SAML2 Single Logout Profile over HTTP Redirect and SOAP Bindings.
  4. All SAML endpoints of the Identity Provider SHALL be protected by HTTPS.
  5. All SAML endpoints of the Identity Provider MUST be under a DNS domain which is possessed by the operating organisation.
  6. All scopes used by the Identity Provider MUST be under a DNS domain which is possessed by the operating organisation.