Pegasi Wiki

This wiki acts as a memo for our own work so why not share them? Feel free to browse and use out notes and leave a note while at it.

eduPersonAssurance attribute

Overview

Attribute “eduPersonAssurance” is used in federated SAML2 authentication to manage risk that is involved in allowing access to a service provider. Using this attribute the service provider can limit access by the reliability of the identity provider and user account. This article gives a simple explanation and usage example with Shibboleth IDP identity provider.

Roughly put this attribute describes the following properties of the requesting user:

We also have two named attribute values that define all of the above in two different levels: Cappuccino and Espresso. Example follows later.

Shibboleth IDP V4 static example

A medium level university example added to attribute-resolver.xml (source HAKA federation).

<AttributeDefinition xsi:type="Simple" id="eduPersonAssurance">
    <InputDataConnector ref="staticAttributes" allAttributes="true" />
</AttributeDefinition>
 
 
<DataConnector id="staticAttributes" xsi:type="Static">
    <Attribute id="eduPersonAssurance">
        <Value>https://refeds.org/assurance/ID/eppn-unique-no-reassign</Value>
        <Value>https://refeds.org/assurance/ATP/ePA-1m</Value>
        <Value>https://refeds.org/assurance/IAP/medium</Value>
        <Value>https://refeds.org/assurance/IAP/low</Value>
        <Value>https://refeds.org/assurance</Value>
        <Value>https://refeds.org/assurance/profile/cappuccino</Value>
    </Attribute>
</DataConnector>

General criteria

These requirements must be met in all of the cases below. Organization is not allowed to provide assurance data without meeting the requirements stated below.

Refeds requirements

  • The Identity Provider is operated with organizational-level authority
  • The Identity Provider is trusted enough that it is (or it could be) used to access the organization’s own systems
  • Generally-accepted security practices are applied to the Identity Provider
  • Federation metadata is accurate, complete, and includes at least one of the following: support, technical, admin, or security contacts

IGTF general requirements

  • Long term commitment on identity providing
  • Secure credential processing
  • IT systems security
  • Credential strength
  • Site security
  • Auditing
  • Privacy and confidentiality

Identifier uniqueness

This describes how certain we are that this login represents this a single natural person.

Uniqueness statements

For uniqueness we have four statements that are used to define the level of uniqueness

  • Unique-1 : This login represents a single natural person
  • Unique-2 : The identity provider is able to contact this natural person if necessary (phone, email, home address etc)
  • Unique-3 : This login is never re-assigned to another party, this login belongs to this person permanently
  • Unique-4 : This user has a unique identifier that can be one of the following
    • eduPersonUniqueId
    • SAML 2.0 persistent name identifier (OASIS SAML)
    • Subject-id or pairwise-id (OASIS SIA)
    • OpenID Connect sub: public or pairwise

Levels of uniqueness

We have three levels of uniqueness which are defined using the statements above as follows

    • All of the statements from Unique-1 to Unique-4 are fullfilled
    • This login is unique permanently, no other instances of this user from this organization are expected
    • This login is identified by an unique identifier such as national id, persistent id or other similar means
    • Statements from Unique-1 to Unique-3 are fullfilled
    • This login is unique permanently, no other instances of this user from this organization are expected
    • Statements from Unique-1 to Unique-2 are fullfilled
    • This login may be reassigned to another natural person after one year of user expiration
    • This login should be removed from service provider system after one year of inactivity

Identity authenticity

This describes how certain we are that this user is who he/she claims to be.

Identity authentity statements

  • Identity proofing : How well is the user identified by the identity provider
  • Credential issuance : How sure we are that the login is given to the right natural person, how mature is the process of producing the login data to the user
  • Renewal : How mature is the user login renewal process
  • Replacement : How user can get new login to replaced the old / revoked one

Identity authenticity levels

These encapsulate the level of authentity of a user. Please look IGTF and Kantara descriptions below.

Low

https://refeds.org/assurance/IAP/low

  • sections 5.1.2-5.1.2.9 and section 5.1.3 of Kantara assurance level 1 [Kantara SAC]
  • IGTF level DOGWOOD [IGTF]
  • IGTF level ASPEN [IGTF]

Examples:

  • Self registered login with verified e-mail address, no photo ID nor face check

Medium

https://refeds.org/assurance/IAP/medium

  
* sections 5.2.2-5.2.2.9, section 5.2.2.12 and section 5.2.3 of Kantara assurance level 2 [Kantara SAC]
* IGTF level BIRCH [IGTF]
* IGTF level CEDAR [IGTF]
* section 2.1.2, section 2.2.2 and section 2.2.4 of eIDAS assurance level low [eIDAS LoA]

Examples:

  • Copy of photo ID presented to identity provider organisation with additional remote video conversation

High

https://refeds.org/assurance/IAP/high

  • section 5.3.2-5.3.2.9, section 5.3.2.12 and 5.3.3 of Kantara assurance level 3 [Kantara SAC]
  • section 2.1.2, section 2.2.2 and section 2.2.4 of eIDAS assurance level substantial [eIDAS LoA]

Examples:

  • Face to face conversation, verified genuine photo ID with all possible means to minimize the risk of stolen or invalid document

IGTF levels

IGTF levels cut thru organisation to provide requirements for multiple aspects of the identity provider organisation.

Please look at the original article for details.

Base requirements

Base requirements comply with the common sense practises of IT administration and include

  • Long term commitment on identity providing
  • Secure credential processing
  • IT systems security
  • Credential strength
  • Site security
  • Auditing
  • Privacy and confidentiality

Aspen

  • The natural person behind the login must be recorded and backtraceable up to one year after login expiration
    • For non-person logins the person in charge must be backtraceable by secure means
    • For host or service entries the FQDN must be associated with an owner person who is authorised to register this login
    • Login must be revoked if backtraceability is lost
  • Identity provider organisation must have a documented process of identity provisioning and validation
  • Login must have a permanent identifier representing the login, such as eppn
    • For non-human accounts the owner permanent identifier must be available
  • Password or credential lifetime maximum of one year
  • Site security
    • Must not knowingly rely on inaccurate or false data providing third parties involved in identity operations
    • Recommended to use third parties with insident response capability
  • Auditing
    • Must have auditable evidence (logs) on retaining the same identity over time
    • Must perform operational audits of the staff and systems involved once a year to verify the compliance to organisation rules
    • Must maintain a list of personnel critical to identity processes
    • Recommended that connected systems (including IDM) self audit regularly with auditable logs

Birch

  • The natural person behind the login must be recorded and backtraceable up to one year after login expiration
    • For non-person logins the person in charge must be backtraceable by secure means
    • For host or service entries the FQDN must be associated with an owner person who is authorised to register this login
    • Login must be revoked if backtraceability is lost
    • All issued credentials must be revoked if backtraceability is lost
  • The first time identity check should include face-to-face meeting and valid, reliable photo identification documents such as passport id ID card
  • Further identifying should be done with one of the following means
    • In person with a trusted agent and reliable photo ID
    • Existing credentials such as username-password, shared secret, TOTP
  • Login must have a permanent identifier representing the login, such as eppn
    • For non-human accounts the owner permanent identifier must be available
  • Password or credential lifetime
    • Maximum of 400 days if stored in a file protected with a single authentication
    • Without expiration with renewal times of 400 days if using two factor authentication of which one is hardware / biometric based
    • 1200 days without renewal for network and service entities with domain name ownership validated
  • Site security
    • Must not knowingly rely on inaccurate or false data providing third parties involved in identity operations
    • Recommended to use third parties with insident response capability
  • Auditing
    • Must have auditable evidence (logs) on retaining the same identity over time
    • Must perform operational audits of the staff and systems involved once a year to verify the compliance to organisation rules
    • Must maintain a list of personnel critical to identity processes
    • Recommended that connected systems (including IDM) self audit regularly with auditable logs

Cedar

  • The natural person behind the login must be recorded and backtraceable up to one year after login expiration
    • For non-person logins the person in charge must be backtraceable by secure means
    • For host or service entries the FQDN must be associated with an owner person who is authorised to register this login
    • Login must be revoked if backtraceability is lost
    • All issued credentials must be revoked if backtraceability is lost
  • The first time identity check should include face-to-face meeting and valid, reliable photo identification documents such as passport id ID card
  • Further identifying should be done with one of the following means
    • In person with a trusted agent and reliable photo ID
    • Existing credentials such as username-password, shared secret, TOTP
  • Identity provider organisation must keep user initial identifation records for a minimum of two years after login expiration
  • Login must have a permanent identifier representing the login, such as eppn
    • For non-human accounts the owner permanent identifier must be available
  • Password or credential lifetime
    • Maximum of 400 days if stored in a file protected with a single authentication
    • Without expiration with renewal times of 400 days if using two factor authentication of which one is hardware / biometric based
    • 1200 days without renewal for network and service entities with domain name ownership validated
  • Auditing
    • Must have auditable evidence (logs) on retaining the same identity over time
    • Must perform operational audits of the staff and systems involved once a year to verify the compliance to organisation rules
    • Must maintain a list of personnel critical to identity processes
    • Recommended that connected systems (including IDM) self audit regularly with auditable logs

Dogwood

  • User login must be unique, it must not be re-allocated to another natural person later
  • Permanent, non-public association to natural user
  • Backtracing to natural person only with IDP organisation co-operation
    • Login must be revoked if backtraceability is lost
  • Recommended to be used with additional stronger (SP based) authentication to proof identity
  • Login must have a unique identifier which identifies the source organisation and is backtraceable to the natural person by the issuing organisation
  • Password or credential lifetime maximum of 400 days
  • Site security
    • Must not knowingly rely on inaccurate or false data providing third parties involved in identity operations
    • Recommended to use third parties with insident response capability
  • Auditing
    • Must perform operational audits of the staff and systems involved once a year to verify the compliance to organisation rules
    • Must maintain a list of personnel critical to identity processes

Certainty of attribute data

Kantara used to provided means to measure attribute data reliability but now also includes measurements for other assurance views.

Please also look at the Kantara service assessment documents for details.

Kantara assurance levels

Kantara gives us multiple levels of attribute assurance.

  • Level 1 : Little or no confidence in the attribute data
  • Level 2 : Some confidence in the attribute data
  • Level 3 : High confidence in the attribute data
  • Level 4 : Very high confidence in the attribute data

Level One

Minimal confidence on attribute correctness. The attribute data is given by an individual without release of data is given back. Examples: payment transactions, web forms, self registered ID based operations.

No cryptographic methods required. Use this level if faulty data does not result in negative outcome.

5.1.1 Credential Operating Environment

  • Password entropy minimum of 14 bits
  • Repeated authentication attempts must be handled with a temporary login disable, timeout or similar
  • Consider and assess potential security threats
  • Organization must prepare for following threats
    • Malicious code injects
    • Human security threats, revealed / paper written passwords or similar
    • Out of band attacks
    • Password spoofing trojans or similar
  • Limiting access to stored administrational passwords
    • Only active administration people
    • Encrypted storage such as Keepass
    • No plaintext passwords sent over unsecured or public networks

5.1.2 Credential issuing

  • Identity must be proofed on credential delivery and evidence must exist of this
  • Identity must be verified with
    • In-person proofing using valid photo ID
    • Remote identity verification using telephone number or email
  • Further use with organization credentials
  • On suspicious activities the organization must do additional verification of identity and halt completion while verification not finished
  • Keep records of identity proofing
  • Provide means for user to update user-definable attribute data, such as personal email address
  • Create credentials only when user identity is proofed
  • Login must be unique and may be selectable by user
  • Provide this unique login information to service providers
  • AUthentication must be used from one of the following methods
    • If password is used, the entropy must be minimum of 14 bits
    • If challenge-response questions are use they must be created by user, answers must not be null
    • If challenge-response questions are not created by user they must be selected from a list of at least five questions, answers must not be null

5.1.3 Credential renewal

  • Password change must be allowed using old password or other authentication to proof their identity

5.1.4 Credential revocation

  • Credential revocation must be done over a secured communication

5.1.5 Credential status management

  • Organization must have valid status information of logins
  • Status information availability must be 95%

5.1.6 Credential verification / authentication

  • Identity provider must service service providers with authentication and identity assertion which is protected from hacking
  • Each identity assertion must be signed and unique to a single transaction
  • Identity provider must deny revoked logins
  • Identity provider must limit failed authentication a
  • Limit failed authentication attempts to maximum of 100 in any 30 day period
  • Expire assertions
    • In 12 hours for users coming from address that is within same internet domain
    • In 5 minutes for users coming from address that is outside internet domain
  • Assurance attribute describes the initial authentication of the user
  • Identity assertion requirement is one of the following
    • Assertion is signed
    • Assertion is encrypted using a shared secret key
    • Assertion has min 64 bits entropy
    • Assertion is sent over a protected, mutually authenticated session

Level Two

Some confidence on attribute correctness. Some risk involved with faulty data.

Single factor authentication is recommended. Gotchas or similar are required to prevent spamming / guessing.

5.1.1 Credential Operating Environment

  • Password entropy minimum of 14 bits
  • Repeated authentication attempts must be handled with a temporary login disable, timeout or similar
  • Consider and assess potential security threats
  • Organization must prepare for following threats
    • Malicious code injects
    • Human security threats, revealed / paper written passwords or similar
    • Out of band attacks
    • Password spoofing trojans or similar
  • Limiting access to stored administrational passwords
    • Only active administration people
    • Encrypted storage such as Keepass
    • No plaintext passwords sent over unsecured or public networks

5.1.2 Credential issuing

  • Identity must be proofed on credential delivery and evidence must exist of this
  • Identity must be verified with
    • In-person proofing using valid photo ID
    • Remote identity verification using telephone number or email
  • Further use with organization credentials
  • On suspicious activities the organization must do additional verification of identity and halt completion while verification not finished
  • Keep records of identity proofing
  • Provide means for user to update user-definable attribute data, such as personal email address
  • Create credentials only when user identity is proofed
  • Login must be unique and may be selectable by user
  • Provide this unique login information to service providers
  • AUthentication must be used from one of the following methods
    • If password is used, the entropy must be minimum of 14 bits
    • If challenge-response questions are use they must be created by user, answers must not be null
    • If challenge-response questions are not created by user they must be selected from a list of at least five questions, answers must not be null

5.1.3 Credential renewal

  • Password change must be allowed using old password or other authentication to proof their identity

5.1.4 Credential revocation

  • Credential revocation must be done over a secured communication

5.1.5 Credential status management

  • Organization must have valid status information of logins
  • Status information availability must be 95%

5.1.6 Credential verification / authentication

  • Identity provider must service service providers with authentication and identity assertion which is protected from hacking
  • Each identity assertion must be signed and unique to a single transaction
  • Identity provider must deny revoked logins
  • Identity provider must limit failed authentication a
  • Limit failed authentication attempts to maximum of 100 in any 30 day period
  • Expire assertions
    • In 12 hours for users coming from address that is within same internet domain
    • In 5 minutes for users coming from address that is outside internet domain
  • Assurance attribute describes the initial authentication of the user
  • Identity assertion requirement is one of the following
    • Assertion is signed
    • Assertion is encrypted using a shared secret key
    • Assertion has min 64 bits entropy
    • Assertion is sent over a protected, mutually authenticated session

Level Three

High confidence on attribute correctness. Substantial risk involved with faulty data.

Multi factor authentication is required. Identity proofing require photographic ID / passport / similar verification. Authentication must be based on a password or a key though a cryptographic protocol. Usage of soft-, hard- or OTP device tokens.

Level Four

Very high confidence on attribute correctness. Critical risk involved with faulty data.

Multi factor authentication is required. Identity proofing require photographic ID / passport / similar verification. Authentication must be based on a password or a key though a cryptographic protocol using hardware device tokens. High levels of cryptographic assurance required for all elements of credential and token management.

Freshness

To assure the freshness of the eduPersonAffiliation, eduPersonScopedAffiliation and eduPersonPrimaryAffiliation attributes the following statements can be used.

Assurance profiles

There exists two assurance profiles that encapsulate the requirements above into a simple common name.

Cappuccino

  • Uniqueness: Unique-1
  • Identity authenticity level: low AND medium

Comments

All comments and corrections are welcome.

 stars  from 0 votes

Leave a comment

Enter your comment:
S T E R P
 

  //check if we are running within the DokuWiki environment if (!defined("DOKU_INC")){ die(); } //place the needed HTML source codes BELOW this line