Onboarding
Onboarding of users is done according their role (what they will have access to). Broadly there are two types of onboarding tasks, ones we handle in-team and ones that need to be done by external groups, primarily Institute IT staff.
Internal Onboarding
...
Digital Collections site
Users: All
Action: Developer or Systems Admin should make a new user.This : Create new user account
Method: Any user with "Admin" level permission can make a new user on Production and/or Staging. When logged in, select "Users" from the Admin menu on the left-hand side. Select "Add New User" and complete fields for "Email" and "Name." If user will have "Admin" privileges, check box for "Admin." Click "Create User."
Once user has been created, click "Send password reset" button next to their name. The user will receive an email with instructions for resetting their password, which effectively activates their account. Please note that accounts created in Production do not automatically sync to Staging and vice versa. To create a new user account on both sites, repeat the process described above.
...
Note: Legacy process for creating new users is described at Application administration (Obsolete) → "Create new users".
Amazon Web Services
Users: Systems, Developers, Managers
Action: Ask Systems Admin to add user to Amazon Web Services. Go to the IAM (Identity and Access Management) page. Select users, add a user. Current permissions options are Billing (for managers), or AdministratorAccess for Developers or Systems Admins. Other permissions can be added as needed. AdministratorAccess is full access to all systems.
Server Access
Users: Systems, Developers
Action: Ask systems admin to have user provide link to their github public keys. Add that link and the username to the ansible-vault file group_vars/all in our repo. Commit the changes to staging, make sure the user is now on staging, then have a pull request to add that user to production as well. Current process requires user has their github account set up, though it does not need to be in our group when we do this.
Digitization and Selection Queue
Users: All
Action: Share link to Google Doc (anyone with link can access/edit): https://docs.google.com/spreadsheets/d/1PdwOTmLMxxprL7k6Z53ntE0XC2i-tappC5VzBPBCeG4/edit?usp=sharing
External Onboarding
Access to the following platforms are managed by Institute IT staff, who will initiate onboarding procedures. In general, access to these platforms should be specified on HR Onboarding documentation or a help desk ticket.
Platforms managed by Institute IT:
Slack (Users: ALL; Action: Create account; add user to "digital-general," "digital-random," and "digital-technical" channels as appropriate).
- Note: Non-IT staff can request invitations to the Science History Institute workspace for new staff through Slack itself. Invitations issued to @sciencehistory.org emails are automatically approved. Once user accepts the invitation, non-IT staff can add them to appropriate channels.
GitHub (Users: ALL; Action: Create account and forward username to IT; Add new collaborator under "Settings" -→ "Collaborators and Team")
...
Past Perfect (Users: Metadata; Action: Create account)
Other resources managed by Institute IT:
M Drive (Users: ALL; Action: Add to list of authorized users for root and all sub-folders)
P:\Special Collections (Users: Metadata; Digitization; Action: Add to list of authorized users for root and all sub-folders)
Offboarding
Offboarding of users is done according their role (what they have access to), though it is key to check all of the following options in case special access was given or exceptions were made.
Broadly there are two types of offboarding changes, ones we handle in-team and ones that need to be done by external groups, primarily Institute IT staff.
Internal Offboarding
...
Digital Collections site
Users: ALL
Actions: Lock the user's account
Method: Have Developers or System Admin follow the instructions in Application administration Any user with "Admin" level permission can lock user accounts on Production and/or Staging. When logged in, select "Users" from the Admin menu on the left-hand side. Click "Edit" next to the appropriate user account. Check box for "Locked out" and click "Update User."
Please note that locking an account in Production does not automatically lock the account in Staging and vice versa. To lock an account on both sites, repeat the process described above.
...
Note: Legacy procedure for locking accounts is described in Application administration (Obsolete)→ Lock out User
ArchivesSpace
Users: Systems
Action: Log in and either delete the user or scramble their password. The second is the preferred method for now.
Simple Method: Log in and go to Systems→ Manage Users, Edit the user you want to edit. Under password generate and type a random string. Requires no server access
Preferred method: Connect to MySQL on the archivesspace server. Set account to be locked until the end of time.
Amazon Web Services
Users: Systems, Developers, Managers
...
Method: Log into AWS, this must be done by someone with full access. Go to IAM (Under Security, Identity, & Compliance). Select Users. Select the user and press Delete User. This is irreversible.
Side note: We should later also add a key rotation for all keys that the user could have had access to.
Server Access
Users: Systems, Developers
Action: Remove personal ssh keys from servers
Method: Currently either rebuild boxes or go into them and delete keys.
External Offboarding
Access to the following platforms are managed by Institute IT staff, who will initiate offboarding procedures. In general, team members are not expected to follow up with IT to confirm that these tasks have been executed, but can submit a help desk ticket for legacy accounts that may not have been deactivated.
Platforms managed by Institute IT:
Slack (Users: ALL; Action: Remove/block account)
...