the admin protocol section on user accounts should be discussed

[robertoostenveld]

There is now

8. Creating, Managing and Linking User Accounts

8.1. Creating and Managing User Accounts

8.2. Migrating User Accounts

with quite some details. I suggest that the protocol only (shortly) states that the admins must do this, but without providing details for which the implementation is not yet clear. We want the protocol to last for many years (without reviewing and re-approving by directors). Hence I suggest to shorten these sections and move the details it over to two FAQs for the admins elsewhere on the wiki.

[robertoostenveld]

I copied the section over from the protocol to the faq/other.md wiki documentation.

[hadrianswall]

I agree with respect to the creation of user accounts. That should go in the FAQs section.

Migrating authorisations to a new account, though, should remain part of this protocol. This has implications for the CMS. It must be possible for the research admin to obtain a list of all collections to in which some digital user has a role (i.e., the old digital identity of a user that moved to a different institution and obtained a new digital identity in the system). The research admin must then be able to migrate the rights associated with this old digital identity to the new one (possibly involving a downgrade of the authorization level).

@robertoostenveld what is your view?

[robertoostenveld]

the migration of accounts was also discussed in a recent email (between @hurngchunlee, @EricMaris and @robertoostenveld).

I think that this needs to be clarified outside of the protocols first. The sequence of actions in the most trivial use case would according to me consist of

• researcher makes account at institute 1
• researcher uses account at institute 1 in collections
• researcher contract ends at institute 1
• admin downgrades the researchers responsibility (for existing account)
• researcher starts at new institution
• researcher makes new RDM account using IdP of institute 2
• admin merges the two accounts, such that by using the new IdP the researcher can take his responsibilities for existing collections. Only one account remains.

in this case there are two actions at two separate moments that need to be reflected in the admin protocol.

How would this look like for a researcher that is employed at two institutions to start with (e.g. with a u and z number, or with a u and a mpi number) and whose contract does not end? I guess that the admin does not take any action in such a case (i.e. neither downgrading, nor merging is done).

How would this look like for a researcher whose contract ends, but who does not get employed by a new institution immediately? I guess the 2nd admin-action never happens.

How would this look like for a researcher whose contract ends, and who leaves academia? I guess the 2nd admin-action never happens.

[hurngchunlee]

I would like to point out that the described workflow involves admins from two different (very likely independent) institutions (i.e. organisational units). Perhaps we should clarify the responsibility of the two admins along the workflow.

To me it's not clear who is responsible for migrating user's account at institute 1 to the account at institute 2. Assuming it's the responsibility of the admin at institute 2, what would be the mean allowing admin at institute 2 to check the old account at institute 1 actually belonged to the same researcher.

[robertoostenveld]

Good question. To clarify the situation I outlined:

• institute 1 would be the Donders, and specifically a OU at the Donders.
• institute 2 would not be the Donders (If institute 2 were the Donders, then the IdP would not change). So only a single admin of the corresponding Donders OU is involved.

I think it would be good to enumerate all permutations of users switching between OUs and institutions.

[robertoostenveld]

we discussed this in person yesterday. Subsequently Eric wrote by email

---

Hi Robert (cc Hong),

I integrated the outcome of our meeting in the protocols. This required some restructuring in both protocols.

Could you have a look at

1. The protocol for researchers paragraph 6.
2. The protocol for research admins, paragraphs 5, 6 and 8.

We meet all 4 managing directors this week Friday, and there we will discuss the protocol for the research admins. Given the substantial changes, I would like to send them an email to reread the protocol prior to our meeting. But I would like you to check on my changes first.

best, Eric

---

I will now do some edits on those sections.

[robertoostenveld]

I suggest that in the protocols and end-user documentation we use the terminology "user profile" to refer to the account in the CMS and iRods system. See https://en.wikipedia.org/wiki/User_profile.

Compared to "account", the phrasing "user profile" gives more the impression that there is information linked to it (such as authorizations in our RDM) , whereas "account" is more strongly related to the login name and password (which are not part of the RDM system, but of the external IdP).

Note that they are not that different in the end and it all matters how you interpret them, but I expect that "user profile" will be interpreted in a more appropriate manner than "account".