User Account Management

(1)

User Account Management

IAA Policies and Procedures: Identity, Authentication, Authorization

Christian Isnard, Emmanuel Ormancey, Paolo Tedesco, Alexey Tselishchev – CERN - IT/OIS

Executive Summary

The new User Account management project aims at designing a generic, maintainable solution, simplifying the account management tools and concepts, and handling the lifecycle of accounts and associated computing resources for the whole community of system and service managers.

The overall concept is based on IAA Policies: Identity, Authentication and Authorization.

• Identity is provided by the user, answering the question “Who are you?” with some public assertion (username, email). This is managed by GS/AIS in the Foundation HR database for the personal information and by IT/OIS for the account (username) information.

• Authentication is also provided by the user, answering the question “Ok, how can you prove it?” with some private secret response (password, private keys, pins). This is handled by Active Directory (IT/OIS) through a set of standards (Kerberos, LDAP, SSO, etc.).

• Authorization is handled by the system, answering the question “What can I do?” by checking a token or ticket against an access control list. This is maintained by the use of E-Groups to manage access control lists (each application should have a dedicated E-Group containing the list of authorized users).

Eligible Users (depending on their status in HR database) are entitled for a Primary account, whereas non-Eligible users can only request External accounts with restricted permissions (e.g. limited to accessing their personal administrative records like payslips).

Account Policy:

The Primary account is automatically created when the user’s status becomes Eligible. The associated username is automatically generated by an algorithm based on first name and last name information.

The user must enable his Primary account by calling the service desk to obtain a password. Then he can create Secondary accounts belonging to him (deleted when he leaves CERN) and/or Service accounts assigned to him (automatically reassigned to his Supervisor when he leaves CERN).

External accounts will have different levels of trust: the default is email address verification only, guaranteed External accounts will have a CERN user as guarantor of the identity, and Grid verified External accounts will be mapped to a digital certificate trusted by the EuGridPMA trust organisation (Grid).

A CERN Mailbox for the Primary account is created automatically for Personnel users, and on request for non-Personnel users (e.g. contractors who should use their home company email). A user has one main email address and several aliases.

Mail Policy:

A Web interface will be provided, for the end user, the Service Desk and the Security Team to manage every aspect of the accounts. The primary goals of the system are to empower the end-user and to maximize the self service features.

(2)

Introduction

The goal of the CERN Identity Management project is to simplify the account and group management tools and concepts, designing a generic solution for the whole community.

To make the system generic, maintainable and easy to support, the implementation will be based on a commercial solution, using out-of-the-box features whenever possible, thus minimizing custom coding.

A set of tools addressing the needs of the CERN community will be provided. Specific needs will be reviewed to fit in the generic tools, or application owners will be helped to implement their own set of specific tools when needed.

This document describes the Identity, Authentication and Authorization (IAA) concepts, defines their policies in the CERN Identity Management context and provides concrete objectives.

1 Definitions

The definitions, concepts and conventions used in the rest of the document are defined in this paragraph. IAA stands for Identity, Authentication and Authorization:

• Identity: A user (typically you) wants to access a system. Because the system doesn’t know you yet, you need to make a declaration of who you are. Your answer to the question “Who are you?” is the first thing you present to a system when you want to use it. Some common examples of identity are user IDs, digital certificates and credit cards. A notable characteristic of identity is that it is public, and it has to be this way: identity is your claim about yourself, and you make that claim using something that is publicly available.

• Authentication: This is the answer to the question “OK, how can you prove it?” When you present your identity to a system, the system wants you to prove that it is indeed you and not someone else. The system will challenge you, and you must respond in some way. Common authenticators include passwords, private keys, and PINs. Whereas identity is public, authentication is private: it is a secret known (presumably) only by you. In some cases, like passwords, the system also knows the secret. In other cases, like PKI, the system doesn’t need to possess the secret, but can validate its authenticity. Your possession of this secret is what proves that you are who you claim to be.

• Authorization: Once you have successfully authenticated yourself to a system, the system controls which resources you are allowed to access. Typically this is done through the use of a token or ticket mechanism checked against an access control list maintained by the system administrators.

Provided by Answer the questions: Attributes

Identity user “Who are you?” Public assertion

Authentication user “OK, how can you prove it?” Secret response Authorization system “What can I do?” Token or ticket

Access control Table 1: IAA summary

1.1 Identity

Identities are defined in HR databases which contain the personal information about the people at CERN. Based on that information are created accounts that represent these Identities in the CERN computing environment.

(3)

1.1.1 Accounts

An account is a login and password credential pair, with some attributes. The login is used to answer the question “Who are you?” and the password is the secret response to “OK, how can you prove it?” (See Table 1: IAA summary).

Several account types are available:

• Primary account: the main account of a user. It is automatically created.

• Secondary account: a test or administrative account, belonging and attached to a user.

• Service account: an account representing a service, assigned to a user (the service manager). Service accounts can be re-assigned to another user.

• External account: standalone account (not necessarily linked to a person in the HR database), obtained via a self-service registration based on email address. External accounts have restricted permissions (e.g. payslips & tax certificates access only). Several levels of trust are available (see

section 2.6).

Reminder: Accounts usage is governed by Operational Circular nº 5. Operational Circular nº 5 requires that users comply with specific rules applicable to services that they use. Users must follow the operational procedures that are in force and the instructions of the service managers. Service managers may withdraw right of access to their service in order to resolve operational problems or in case of failure to comply with

these subsidiary rules

1.1.2 User status

• Personnel: a user with a CERN contract (staff, fellows, project associates, etc.) or registered as a CERN User.

• Non-Personnel: a user not member of the CERN personnel (e.g. employees of a CERN contractor, consultants, etc.).

See the Table 2: CERN Class in section 1.1.5.

1.1.3 Eligible users

• Eligible users are entitled for a Primary account.

• Non-eligible users can only request an External account, e.g. to access their personal administrative records (payslips etc.).

See the Table 2: CERN Class in section 1.1.5.

1.1.4 Mail addresses

• Mail address: main email address of the user. • Alias: convenience alternate email address.

1.1.5 CERN Class

The Table 2: CERN Class shows all the possible values for a person’s class in the Foundation database (maintained by HR).

• The CERN Class column shows all the possible CERN Class values in Foundation database. • The # column shows the number of entries for each CERN Class in Foundation database.

• The Eligible column shows which user classes represent eligible users according to the definition in

section 1.1.3.

• The Personnel column shows which user classes represent users belonging to the CERN personnel according to the definition in section 1.1.2.

(4)

CERN Class # Description “Eligible” “Personnel”

EXMP 66350 Ex-Member of Personnel N N

USER 9280 User (“CERN User”) Y Y

ENTC 3021 Employee of a CERN

contractor Y N

RETR 2683 Retired N N

STAF 2379 Staff Member Y Y

UPAS 453 Unpaid Associate Y Y

FELL 369 Fellow Y Y

PJAS 147 Project Associate Y Y

DOCT 118 Doctoral Student Y Y

TECH 94 Technical Student Y Y

USAS 78 Unpaid Associate with

Subsistence Y Y

COMT 66 Committee Member N N

PDAS 59 Paid Associate Y Y

TEMC 35 Temporary Labour for CERN Y Y

APPR 24 Apprentice Y Y

FTMP 20 Future Member of the

Personnel Y Y

CASS 11 Corresponding Associate Y Y

CNST 7 Consultant Y N

ADMI 6 Administrative Stagiaire Y Y

CHIL 3 Child Staff Y Y

PART 2 Participant to an experiment N N

Table 2: CERN Class

1.1.6 Account enabling, blocking, unblocking

• Enabling an account: set the account state to “enable” and assign a new password (first account use). • Blocking an account: Reset the password and set the account state to “disabled” to prevent

alternative authentication methods.

• Unblocking an account: set the account state to “enable” and assign a new password.

1.2 Authentication

Authentication is the answer to the question “OK, how can you prove it?” (see Table 1: IAA summary). When an identity is presented to a system, the system will challenge the user who must respond in some way. CERN authenticators include for example passwords and private keys with Digital Certificates through a variety of authentication systems like Kerberos, Single Sign-On or SSH.

1.3 Authorization

Authorization is the answer to the question “What can I do?” (see Table 1: IAA summary). Once successfully authenticated to a system, the system controls which resources a user is allowed to access, usually through the use of a token or ticket mechanism checked against an access control list maintained by the system administrators.

A wide range of CERN applications use E-Groups to maintain these access control lists: the token or ticket mechanism contains the list of the Groups the user is member of. The application simply compares the E-Group membership list with the access control list and the user is given access if a match is found.

(5)

1.4 Generalities

Unless specifically mentioned, all operations are available to the end-user in self-service via the dedicated Web

Portal

for security reasons.

2 Policies

2.1 Accounts

Only Eligible users are entitled for a Primary account (see section 1.1.3):

• The creation of Primary accounts is automatic. The events triggering the creation of a Primary account are:

o The insertion, in Foundation HR database, of a new record having a CERN Class identifying

the user as an Eligible user (see Table 2: CERN Class in section 1.1.5). This happens when a new user joins CERN.

o The transition, in Foundation HR database, of an existing record from a CERN Class

identifying the user as a Non-Eligible user to a CERN Class identifying the user as an Eligible user. This happens for example when an ex-employee gets a new contract.

• An eligible user can create Secondary accounts:

o A Primary account is required to create a Secondary account.

o The Secondary accounts are owned by the Primary account of the user. o Ownership of Secondary accounts cannot be transferred.

• An eligible user can create Service accounts:

o A Primary account is required to create or own a Service account. o Ownership of Service accounts can be transferred.

o A Service account is always assigned to a Primary account, it can never be stand-alone.

2.1.1 Account activation

On the start day, the user shall contact the ServiceDesk by phone to enable his Primary account (see section 1.1.6) and obtain his login and a new password. In addition, the user’s supervisor is also allowed to enable his Primary account, for the first account use.

2.1.2 Default account names (login)

The maximum length for account names is 8 characters. Characters are normalized (removing all diacritic marks); spaces and non-alphanumeric characters are removed.

The default account name for a new primary account is chosen as the first available proposal among the following, with a reduction to 8 characters when needed:

1) First letter of the first name + last name

2) First letter of the first name + first letter of the middle name if present, + last name. 3) Last name + first letter of the first name

4) First name + first letter of the last name

5) A number is added to proposal 1 until a unique value is generated.

First name Last name Account names

John Doe jdoe

(no middle name, case 2 does not apply) doej

johnd jdoe2

(6)

jdoe3 Jane Mary Doe jdoe

jmdoe Johannes Müller jmuller Table 3: Account name generation samples

2.1.3 Primary account name change

It is possible to change the primary account name (login) during the first week after the contract start date.

2.2 Password policy

Primary, Secondary and Service accounts follow the same password policy: the password must be changed every year. Failure to comply will result in account blocking. Multiple reminders will be sent before the year expires and the account gets blocked.

2.3 Mail policies

Every account has one main mail address and a number of aliases. Depending on the CERN mailbox existence the mail messages are either delivered to the CERN mailbox or redirected to another external mail address.

• Only the main address is valid for authentication.

• Aliases must be in the cern.ch domain (i.e. something@cern.ch).

• Each account has mandatory aliases <login>@mail.cern.ch and <login>@cern.ch for technical reasons

o Linux batch system, backward compatibility with many existing applications building

addresses on the fly by adding @mail.cern.ch to the current login.

2.3.1 Mail policy for primary accounts

• A CERN mailbox is created automatically for Personnel users (see section 1.1.2)

o Main mail address <firstname.lastname>@cern.ch

o Aliases <primary-login>@mail.cern.ch and <primary-login>@cern.ch

 Additional aliases can be added.

• No CERN mailbox is created for Non-Personnel users (e.g. contractors use their home company email)

o Main mail address is external <something@domain.ext> (provided by the user upon arrival) o Aliases <primary-login>@mail.cern.ch and <primary-login>@cern.ch

 Additional aliases can be added. • It is possible to create or delete the CERN mailbox:

o Non-Personnel users (e.g. contractors, see section 1.1.2) are allowed to create a CERN

mailbox if needed (e.g. ServiceDesk people).

o Personnel users are allowed to delete their CERN mailbox and register an external primary

email address instead. In this case the previous primary email address (<firstname.lastname>@cern.ch) will be kept as an alias to ensure mail messages forwarding continuity to the new address.

2.3.2 Mail policy for secondary accounts

• Secondary accounts have no CERN mailbox and cannot create one. • Main mail address is <secondary-login>@cern.ch

• Alias is <secondary-login>@mail.cern.ch

• Main mail address cannot be changed, no alias can be added.

• All mail messages sent to the Secondary account are routed to the owner’s Primary account main mail address.

(7)

2.3.3 Mail policy for service accounts

• A CERN mailbox is created, configured by default to forward all messages to the owner’s Primary account mail address

o Reason: to avoid messages accumulating in the service mailbox and ensure communication

to the owner.

• Main mail address <service-login>@cern.ch

o The user will have the possibility to specify a different address when the account is being

created.

• Alias <service-login>@mail.cern.ch

o Additional aliases can be added.

2.4 Acceptance of Computing Rules

• Every user must follow the Security Quiz and sign the acceptance of computing rules document on the

SIR portal (Safety Information Registration

enabling (start of the contract).

• If computing rules are not signed within that delay, all the user’s accounts are blocked:

o The account owner must call the ServiceDesk to have the account(s) re-enabled. o After that, the user has 3 additional days to sign the acceptance document.

2.5 User departure

Two months before a user’s contract with CERN terminates: • The user and his supervisor are notified via mail:

o Of the accounts owned by the user o Of the E-Groups the user is member of

 The user can contact the responsible of the E-Groups he is member of in case he wishes to be still member of them after his departure.

When a user’s contract with CERN terminates:

• Their Primary account is moved into a ‘Recycle Bin’. • All their static E-Groups membership are deleted.

• All their Secondary accounts are moved into a ‘Recycle Bin’. • All their Service accounts are transferred to the user’s supervisor.

• A new External account, with the external email address of the user is created. Existing @cern.ch aliases are moved from the Primary account to this new External account.

After a grace period of 6 months:

• Their Primary account is deleted. • All their Secondary accounts are deleted.

• The grace period allows recovery if the user gets a new contract (e.g. affiliation renewal).

2.6 External accounts

As defined in section 1.1.1, an External account is a standalone account registered manually and based on an email address (not in the cern.ch domain). By default the only verified information of an External account is the email address used for registration which must be valid and functional.

2.6.1 Standard External account

The only verified information of a Standard External account is the email address used for registration which must be valid and functional.

A specific E-Group lists all the External accounts and can be used for Authorization.

(8)

2.6.2 Guaranteed External accounts

• External accounts can have a guarantor

o Any CERN Primary account holder can be the guarantor of an External account

• A specific E-Group will list all the guaranteed External accounts and will be used for Authorization. • When the guarantor leaves CERN

o Guaranteed accounts are reclassified as Standard External accounts. o A notification email is sent to the External account email.

o A Specific “guaranteed accounts” page will be provided through the Accounts portal

• Guaranteed accounts will have to change password every year; failure to comply will result in account suspension and eventual deletion.

o Password expiration will be enforced to 1 year

2.6.3 Grid Verified External accounts

• A valid certificate can be mapped to the External account assuming:

o The Grid certificate was issued by a trusted member of the EUGridPMA

o The email address specified in the certificate matches the registered email address of the

external account

• If the checks above are successful the External account is marked as verified: a Grid certificate can only be issued after mandatory identity face to face verifications (following strict EUGridPMA rules). • A specific E-Group will list all the Grid Verified External accounts and will be used for Authorization.

3 Interfaces and administrative tools

A Web Portal

for the end user, the ServiceDesk but also the Computer Security Team. Various user rights will be managed using E-Groups.

(9)

3.1 Standard Access

Eligible users are granted access to the Web Portal allowing them to: • View the details about themselves

• Create and manage their Secondary and Service accounts • Re-assign the Service accounts they manage to another user

o The new owner will have to approve the decision

• Manage their passwords

Figure 2: Account management

(10)

Figure 4: Services Management

The Web Self Service Portal will present a global view of the computing resources owned by a user, the list of services he has subscribed to, and the available options for each of them. Service managers are encouraged to join the central system to ensure a consistent management perspective.

3.2 ServiceDesk Access

Members of specific ServiceDesk E-Groups are granted additional rights to the identity management service through the Web Portal allowing them to:

• View the details of all the users

o Necessary for identity verification

• Reset a user’s password • Enable a user’s account

3.3 Computer Security team Access

Members of specific Security Team E-Groups are granted additional rights to the identity management service through the Web Portal allowing them to:

• View the details of all the users • Block and unblock an account

4 Authorization management

Authorization Management is handled through E-Groups. Granting access to a specific resource is done by adding a user to a specific E-Group designed for this purpose.

As an example: John Doe builds an application called “ApplicationName” and wants to restrict access to this application to a set of operators. He can simply create a dedicated E-Group “ApplicationName-Authorized-Users” filled with the accounts of the allowed operators. Then when accessing the “ApplicationName” application, the operators will authenticate and their E-Group membership will be verified by the application, allowing access only to the dedicated E-Group “ApplicationName-Authorized-Users” members.

(11)

In addition, each application should also use another specific E-Group to deny access to a list of users (e.g. “ApplicationName-Denied-Users”) to allow granularity when blocking access to resources for an account (for security reasons, when a user changes status, etc.).

Integration to the central Web Interface for Service Management is proposed to Application owners to provide a consistent End-User interface: see Figure 4: Services Management in section 3.1.

4.1 Roles

There is no specific role concept and/or dedicated application in the new IAA Policy. A role is simply obtained by adding a user to a specific E-Group. Adding “operator1” to the E-Group “ApplicationName-Authorized-Users” (see example above) creates a specific authorization role for the application “ApplicationName”.

4.2 Groups for AFS

AFS can handle only a limited number of groups, with a limited number of characters for the group name, and a limited number of group memberships is allowed per user.

It is proposed to address these restrictions allowing AFS to use the central E-Groups system in the following way:

• A specific E-Group will be created: e.g. “AFS-Published-Groups”, managed by the AFS team. • This E-Group will be populated (only) with the E-Groups that will be available in AFS.

• AFS system will synchronize the user memberships and the list of E-Groups only for those listed in this specific “AFS-Published-Groups” E-Group.

4.3 Exceptions

Some services might not be able to use the central E-Groups system to manage Authorizations; those services will have to continue using their internal Authorization systems with their own management tools.

5 Migration

5.1 Accounts

• Data will be migrated to the new Identity Management Service from:

o HR database (Foundation) o Active Directory

• The migration process will not enforce compliancy to the policies described in this document. Non-compliant cases will be addressed manually.

• Policies will be enforced on resources created through the new Identity Management Service. • Existing service provider accounts will be assigned to a primary account after the migration process.

5.2 Computing groups

• Computing groups will be migrated to E-Groups.

o An email will be sent to the computing group owners, indicating that the new computing

group management interface is the E-Groups interface.

• The aim is to remove the unused computing groups if possible, but also to merge, simplify and enhance the use of computing groups by using the centralized standard E-Group system.

5.3 Service Transition

Currently, the services provisioned by the legacy system are AFS, AIS, EDMS, MAILSERV, MISS, NICE, ORACLEDB, PARC, PLUS, REMEDY, TELECONF. Most of them are already based on Active Directory so the change will be transparent. Some like EDMS do not even need account provisioning anymore, following the

(12)

new model. Others like ORACLE will require a specific solution either transparent or with some minor adaptations.

(13)