Subject

this memo is about what should happen when a User from collab1 ( collab.humanbrainproject.eu ) try to login with his user MitreId to Iam

Case 1 : User have an account in MitreId but not in IAM

Case 1.1 : User has a personal email ( not institutional ) such as gmail.com

When he attemps to loggin on an existing service from the new collab, lets take https://wiki.ebrains.eu

Nothing happen, Iam reject it, this username is unknow from IAM, and we don't look for it in MitreId because it's an unauthorized email

Possible action : You should Register by Getting Access or ask the support to create you exceptionnaly an account with personal email

Case 1.2 : User has an institutional email such as epfl.ch

Case 1.2.1 : User is accredited SGA2 in the collab v1

If the user is accredited SGA2 in the collab1, he will be able to login to iam, but he will have to verify is email

Case 1.2.2 : User is not accredited SGA2 in the collab v1

The user will be created in IAM, but he won't have the access to xwiki or other service related to the collaboratory.

He will see this page

Possible action :

• Get SGA2 accreditation in collab1 and try to login again
• in iam, put the user in his institution group or add manually to the user the role collaboratory_member

Case 2 : User have an account in MitreId and in IAM or just in IAM

At this point, it doesn't matter if the user have an account in MitreId, and if he is or not accredited.

We already have some users with personnal email for historic reason ( auto import of accredited SGA2 users from collab1 )

Theses users all belong to the unit call imported, this unit has for now ( exceptionally ) the role collaboratory_member so they can access wiki.ebrains.eu, they will just have to verify there email. After testing, it appears that personnal email receive well the verification email so it works !

There is no possible scenario currently for users with personnal email to not be in the imported group, so they should all have access to wiki, except for those handmade created after a support request. Users created from a support request should be put in the appropriate unit with the appropriate access case by case.