USER PERSPECTIVE ON CHANGES FOR OPENID Draft 2 December 3, 2015 This brief document explains our current thinking for how the integration of OpenID would work in the EBMS and, hopefully, other Drupal based systems. By "user" we mean both board member users who now use eDir authentication, and OCPL staff who register or modify user accounts. Draft 2 incorporates changes based on feedback from users and other developers, and on things we have learned in our further work on, and further thinking about, the Federated Login project. Currently, Google is the only choice offered for OpenID logins. There may (or may not) be other offerings in the future. If there are others, there may be some expansion of what is written below. Hopefully, very few or no modifications will be required. A user who logs in with OpenID will only be able to login that way. Accounts can be converted from one login type to another and, if other sources besides Google are available in the future, from one OpenID provider to another, but no user will be able to login in two different ways. Gathering OpenID Information for Existing Users ----------------------------------------------- The first step would be for OCPL staff to gather Google account email addresses from board members. Each board member would be asked to provide an email address that Google recognizes as an account identifier. This might be a gmail address but could be any email address that a user has used when creating a Google account. This may or may not be an email address used by the member for any other purpose. Those users without Google accounts would each have to create one in order to have a login. The Google account email address (which need not be a GMail address) will not become a permanent part of the EBMS. The programmers will provide a spreadsheet containing, for each active user, columns for the internal Drupal user ID number, the user name, and an empty column for Google account email addresses. Staff members would need to fill out the spreadsheet by asking board members to provide their Google account email addresses. They should not provide passwords, just the email address. When all email addresses (or as many as can be hoped for) are collected, we would install the OpenID logins. Installing the OpenID Logins ---------------------------- ODDC and CBIIT staff will run a script to install the new email addresses in the system, and install new software to use. The system would be down, probably for an hour or more, for the installation, and probably be closed to outside users until testing shows that everything is okay. New Login Behavior ------------------ Depending upon what cookies may be on the user's machine, when the system comes up, the login behavior would be changed as follows: A user enters the system URL, https://ebms.nci.nih.gov. If the user is not automatically recognized by the system (in which case he'll be taken directly to the home page), he will be taken to a new login screen, not the same as the current one. The new screen will tell the user that he has reached EBMS and give any information or instructions that will be useful about logins. OCPL staff will prepare the material to be displayed on this screen. The user will then click a link or button that takes him to the same NIH "iTrustGateway" page, similar to what NIH SSO users currently see. The user will be given an Account Type selection with two choices: HHS Staff Social Login/OpenID Internal staff would most likely use HHS Staff. Board members would most likely use OpenID. For OpenID users, a new menu would appear. At the current time the only available selection is "Google". The user will enter his email address and password and authentication will take place at Google, NIH, and in the EBMS, leading the user to his EBMS landing page. The first time the user does this, Google will tell the user that NIH is asking for permission to retrieve basic account information identifiers and ask the user whether that is acceptable. The user must grant that permission in order to utilize Google as an OpenID authentication provider. The existing eDir based authentication will be gone. Adding New Users ---------------- The spreadsheet conversion would only be for a mass, one-time conversion of users from eDir to OpenID. From then on, new users would be created by an OCPL staff member with the authority to "administer people" in the EBMS. The staff member would have two options for creating a new user: + Add NIH SSO user + Add user The option of creating a new eDir user will be removed. To create a new OpenID user, the OCPL staffer would choose "Add NIH SSO user", fill in a user name and other fields, and a field for the Google account email address. There might be a required prefix to the address such as "mail:", "mailto:", or perhaps "M:" to make clear to the software that the initial link from the user to his OpenID account is via an email address. This is for future expansion if and when we support other OpenID providers who may have some different form of identification. An example entry might be: Username -------------------------- |John Smith | -------------------------- User NIH SSO Username -------------------------- | | -------------------------- User OpenID User Identification -------------------------- |M:jsmith17@gmail.com | -------------------------- The staff member would fill out either the NIH SSO username, or the OpenID User Identification, not both. The OpenID User Identification will not be permanently stored in the EBMS database. Once a user has logged in for the first time, NIH will provide us with an NIH specific OpenID identifier that looks something like this: "google_123456789012345678901@nih.gov" That's what will appear if someone calls up the record to edit it after the user has already logged in for the first time. Converting Users from One Type to Another ----------------------------------------- The current method for editing users will be essentially the same as before except that no option will be needed for eDir data entry. Converting a user from NIH to OpenID can be done simply by deleting the text in one of the above user identification fields and entering text in the other. Editing an OpenID User's Record ------------------------------- If a user wishes to change his OpenID identification, for example from one Google account to a new one, he will need to communicate the new account identifier to a board manager who will type in the new email address into User Identification field, replacing whatever is there, for example replacing: "google_123456789012345678901@nih.gov" with: "M:johnny.smith@umd.edu" However we think (we'll know for certain after we try it) that if a user keeps his Google account but just changes his email address, no change whatever should be needed at the NCI or NIH ends. Similarly he can change his Google password without notifying us. We will not permanently store his email address and will never have his password at all.