Versions Compared

Old Version 11

changes.mady.by.user Daniela Pöhn

Saved on

compared with

New Version Current

changes.mady.by.user Daniela Pöhn

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Do you use a level of assurance? Which one?
  • Is the LoA self-asserted?
  • Is everything documented?
  • If not documented: which costs would that be?
  • Internal audits?
  • External audits?
  • If no audits: costs for that?
  • How many users need a (higher) level of assurance?
  • Identity Management Practise Statement?

 

Results

Survey

IdPs

Excel

Participants:

  • 3x DFN-AAI
  • 1x RENATER
  • 1x фEDUrus, Kalmar, SIR, UKfederation, InCommon, IDEM, Tuakiri, AAF, Surfconext, edugain, SAFIRE
  • 1x - (GEANT IdP)
  • 5x Small amount of manpower
  • 1x Small to medium amount of manpower
  • 4x < 50 000 user
  • 1x < 10 000
  • 1x < 100

1.Identity/account concept

  • Account for an individual person (i.e. there are no shared accounts)?
    • 5x Already implemented
    • 1x Could implement with significant manpower.
  • If individual account: traceable? Are identifiers persistent?
    • 4x Already implemented
    • 1x Could implement with significant manpower.
  • Which unique identifier?

    • uid for CASsified applications, eppn for shib applications

    • ePPN, ePTID
    • CN
    • persistentID

2.Registration and proof of identity

  • Identity vetting process?
    • 3x Already implemented
    • 1x Could implement with significant manpower.
    • 1x Would not get approval to make this change: significant manpower needed
  • What identity vetting process?

    • by student department for student, by human resources department for staff

    • Implementation for students (Student Administration) and regular employees (Personal Administration). Not for short- or longterm guests, external doctorstudents, etc.

    • with use of the identity card of the person
  • Documented?
    • 3x Already implemented
    • 2x Could implement with small amount of manpower.
    • 1x Could implement with significant manpower.
  • Different validation between student, staff or faculty members? How?
    • All besides of one IdP

    • students: Student Administration, regular employees: Personal Administration

    • Students are vetted on enrollment, Staff is introduced in person.
    • We have guest lectures from all over the world. For them it's not possible to identify personally with their identity card. Here we accept other forms of identification.
    • 1x no ID check at all

3.Online authentication

  • Passwords with quality guarantees?
    • 4x Already implemented
    • 2x Could implement with significant manpower.
  • What kind of guarantees?

    • [password_quality]  policies = builtin:minimum-length builtin:character-class builtin:external-check   min_length = 8   min_classes = 2    external_program = /usr/bin/heimdal-strength

    • Minimum length 14 characters.
    • Special production rules on password reset. Passwort resetting mandatory.
    • Passwords must be 8-14 chars, containing at least chars from three of the following four groups: uppercase, lowercase, numeral, punctuation. A dictionary check must be passed (cracklib). Introduction of password expiration date, password history and two-factor-authentication is planned.

    • minimum length, use of minimum number of 2 special characters forced

  • Two factor authentication?
    • 3x Could implement with high-cost system changes.
    • 2x Could implement with significant manpower.
    • 1x Could implement with low-cost system changes.

4.Freshness of user data

  • Are accounts closed as an individual departs?
    • 4x Already implemented
    • 2x Could implement with small amount of manpower.
  • How promptly?
    • 2x >= 6 months
    • 2x < 6 months (1x DFN-AAI, 1x GEANT IdP)
    • 1x < 2 months (DFN-AAI)
    • 1x < 4 weeks (DFN-AAI)
  • Is the eduPersonAffiliation value updated as an individual departs?
    • 4x Already implemented
    • 2x Could implement with small amount of manpower.
  • How promptly?
    • 2x >= 6 months
    • 2x < 6 months (1x DFN-AAI, 1x GEANT IdP)
    • 2x < 2 weeks (DFN-AAI)

5.Step-up authentication

Step-up authentication means that the user first authenticates with a password, and subsequently with a second factor (such as by an one-time password delivered to his/her cellphone)

  • Would you like to have GÉANT/your NREN to run such a service (if it costs/if it doesn't cost)?
    • 2x Yes, but only if it costs no money at all
    • 1x Yes, but only if costs little money
    • 1x Yes, even if it costs
    • 2x No, because we have no use case for it
  • How many users would need such a service?
    • 5x >500
    • 1x <= 100 (1x Yes, even if it costs)

6. Provenance and level of assurance

  • Do you use a level of assurance?
    • 5x Could implement with significant manpower.
    • 1x Could implement with high-cost system changes.
  • Is everything documented?
    • 2x Already implemented (thank you DFN-AAI)
    • 1x Could implement with small amount of manpower. (also DFN-AAI)
    • 3x Could implement with significant manpower.
  • Identity Management Practise Statement?
    • 1x Already implemented
    • 2x Could implement with small amount of manpower.
    • 3x Could implement with significant manpower.
  • Incident Response Process?
    • 1x Already implemented
    • 3x Could implement with small amount of manpower.
    • 2x Could implement with significant manpower.
  • Audits?
    • 1x Already implemented - internal audits
    • 1x Could implement with small amount of manpower.
    • 4x Could implement with significant manpower.

IGTF

  1. Identity/account concept

    • Account for an individual person (i.e. there are no shared accounts)? - There are no shared credentials or accounts by policy - although the policies allow for specific "machine-to-machine" authentication credentials ("Robots"). For these Robot certificates, they are either uniquely tied to a named individual person (effectively giving that person a secondary credential); linked to a named networked entity (by FQDN); or assigned to group of people with compensatory controls: one named person must act as the applicant and responsible person, but the credential may be used by an identified group in possession of a shared email contact address, but any messages to this address must be responded to within one business day.
    • If shared: possible to distinguish between individual and shared accounts? - The machine-to-machine credentials are identified by the substring "Robot " in their subject name, and a specific policy OID (attribute) in the credential
    • If individual account: traceable? Are identifiers persistent? - one entity may have more than one ID but an ID cannot be reassigned to a different entity (this also holds throughout the IGTF federation globally, using scoped identifiers)
    • Which unique identifier? - the subject name of the credential is used (for PKI). Depending on the assurance level, it will contain also the real name of the person involved.
  2. Registration and proof of identity
    • What identity vetting process? Face-to-face or different? - The IGTF supports differentiated assurance. For the 'conventional' assurance levels (designated ASPEN, BIRCH and CEDAR), a face-to-face identity vetting or equivalent is required. F2F is supported in-person with official photo-ID; supported by notary public attestations and video conference; or by exceeding Kantara LoA-2. For the identifier-only ('lower') assurance level ("DOGWOOD"), only enough information needs to be collected to ensure uniqueness - there is no F2F requirement there.
    • Documented? - All vetting processes and possibilities are document at each IdP, and meet or exceed central federation requirements.
    • Different validation between student, staff or faculty members? How? - All members are validated equally
  3. Online authentication
    • Passwords? - in the PKI infrastructure certificates have to be issued, so these do qualify as 2-factor authentication. This statement has to be qualified slightly: since the key pair is controlled by the user, a pass phrase on the credential cannot be fully technically enforced. Policy requirements, user induction, and software support strive towards having strong pass phrases, making it a two-factor secured system. In some cases, especially for identified based on other (federated) IdM systems ("MICS, SLCS, IOTA"), the second factor/certificate is obtained based on a username-password authentication (GEANT TCS, DFN SLCS, CILogon, HPCI)
    • Passwords with quality guarantees? What kind of guarantees? - By policy, end-user pass phrases must be at least 12 characters - this  is not technical enforceable, but is technically stimulated (it is hard to not have a pass phrase). Key pair is usually a software token (file-based)
    • Two factor authentication? -  Yes, by default 2 factor. It is to note that the 2-factor authentication is partially there for convenience in (non-web-sso) authentication scenarios and to anchor attribute certificates to it. When in use, a (kerberos-ticket-like) proxy credential with short (~12hr) validity is created based on the credential. The other advantage because of which 2FA certs were chosen is that these are self-contained and thus resilient to any (network) failures -- there is no single point of failure in the PKI - esp. since also the revocation data (CRLs) are cached by the relying parties and services. The relying parties (SPs) do not now have an opinion yet as to whether this 2-factor auth would be a hard requirement for most of their use cases.
    • If yes, which second factor? Is the eID used? - a PKI certified asymmetric key pair, usually held in software (file). eID is not used
    • If no two factor authentication: How big would be the cost to provide two factor authentication? - There is no incremental cost to provide the second factor (cert), although there is some cost to generate the certificates (people time needed for issuance). Cost would increase if the second factor would be on a hardware security token. Given software limitations, the cost of NOT providing two-factor has been high until now.
    • how widely Home Orgs use government IDs i.e. strong authentication the governments use for authenticating citizens - For the conventional assurance levels (with F2F vetting) validation is based on official govt. photo ID checking at application time. No other Govt (database) authentication is used.
  4. Freshness of user data
    • Are accounts closed as an individual departs? How promptly? - If data changes credentials must be revoked, but this relies on the users taking an action. But in all cases, at most after 400 days the credential expires. The credential contains only authentication/identity data, and does not in itself contain other attributes that may become invalid. It is very unlikely that the user will ever depart from the user (and the passprase should be lost when the user dies, rendering the credential unusable). Ability to obtain new credentials is based on ability to be vetted or on verified ongoing relationship with the issuing authority.
    • Is the eduPersonAffiliation value updated as an individual departs? How promptly? - ePersonAffilition is out of scope. No data beyond identity data is necessarily collected. Organisations may not even be named in the credential (real name and unique identifier only)

  5. Step-up authentication

...