Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | Identity in the Collaboratory 2.0 is provided by the identity and authentication management (IAM) service at https:~/~/iam.ebrains.eu. The IAM server provides a single-sign-on (SSO) across all integrated tools. It also provides a mechanism for services to connect to each other on behalf of a user. This document provides an overview of the protocol used, Collaboratory IAM service, EBRAINS user directory and instructions on using the IAM service to set up an application or run a service. The objective of this document is to help the reader setup a secure service within the HBP ecosystem. | ||
| 2 | |||
| 3 | This document is technical and aimed at developers setting up a service, or technical project managers planning to do so. Background knowledge of fundamental issues on security and software development are expected from the audience. It is still necessary for the developers to follow up on the main concepts of authentication, authorization and OIDC in order to build a secure application. | ||
| 4 | |||
| 5 | == Introduction to OIDC == | ||
| 6 | |||
| 7 | === Terminology and Background Material === | ||
| 8 | |||
| 9 | First, authentication and authorization are two different concepts. Authentication is the process of verifying your identity. Authorization is the act of granting or denying the right of a user to complete an action. Here is an example: if you show up to a secure building and you show your identity card to a guard, the guard is //authenticating// you. Next, when the guard looks up your name in a list of guests, he is checking whether you have //authorization// to enter the builing. | ||
| 10 | |||
| 11 | In the HBP, we use the [[OpenID Connect>>url:https://openid.net/connect/]] (OIDC) protocol for authentication, and the [[OAuth 2.0>>url:https://tools.ietf.org/html/rfc6749#section-1]] framework for authorization. OIDC is built on top of OAuth to provide an identity layer. OIDC and OAuth 2.0 are specifications of a protocol. A protocol is like a code: if I say “Palm tree”, let me in, if I say “Coconut”, turn on the lights. In order to use a protocol, you need an implementation: a program that takes care of reacting to each request based on the protocol. We use KeyCloak as our IAM server. | ||
| 12 | |||
| 13 | As mentioned above, KeyCloak is a program that uses OIDC to identify you and do authorization. Sometimes, like when you go to the theatre, you can be //authorized// to enter without proving your identity, simply by presenting a ticket. OAuth 2.0 allows a service (a special type of program) to obtain a ticket on your behalf from our IAM server. This ticket then allows the service to connect to other services on your behalf. These tickets usually contain information about your identity as well as some hints about authorization. | ||
| 14 | |||
| 15 | You can find the detailed terminology for the OIDC protocol [[here>>url:https://openid.net/specs/openid-connect-core-1_0.html#Terminology]], and I have summarised and explained a few key terms here: | ||
| 16 | |||
| 17 | //OpenID Provider (OP)//: This is the service that tracks user identities and implements the OIDC protocol. In our case, it can: [[https:~~/~~/iam.ebrains.eu/auth/realms/hbp>>url:https://iam.ebrains.eu/auth/realms/hbp]]. | ||
| 18 | |||
| 19 | //Relying Party (RP)//: This is an app that uses the OP to authenticate or authorize a user. Examples in our case are the Lab at [[https:~~/~~/lab.ebrains.eu>>url:https://lab.ebrains.eu/]], and the Drive at [[https:~~/~~/drive.ebrains.eu>>url:https://drive.ebrains.eu/]]. | ||
| 20 | |||
| 21 | //Service Provider (SP)//: This is not strictly speaking a term in the OAuth or OIDC or OAuth vocabulary, but from another procotol called SAML. It is SAML’s equivalent to the //relying party// described above. | ||
| 22 | |||
| 23 | //Identity Provider (IdP)//: An identity provider is once again not from the OIDC vocabulary, but from SAML. It is the equivalent of the //OIDC Provider//. | ||
| 24 | |||
| 25 | //Client//: A client is app that can connect to a protected resource on behalf of the user. This is true of any RP. A client must be registered on the OP. This means that, if you want to create an app for users, you must register a client with IAM. | ||
| 26 | |||
| 27 | //Scopes//: Scopes are used to authorize a client to access certain resources on behalf of the user. If a user Alice connects to an RP such as the Lab, and she wants to access files from the drive, she must agree to let the client (Lab) to access files on the drive by granting the scope. This happens when she authenticates with the OP, our IAM server. The scopes Alice grants are stored by IAM and passed in the token (like a ticket) which Lab receives. The Lab can then use this token to connect to Drive and download Alice’s files. | ||
| 28 | |||
| 29 | //token//: A string that has special meaning for authorization or identification. | ||
| 30 | |||
| 31 | //Claims//: These are data that are embedded in the token, providing identify or authorization information, for example: email. | ||
| 32 | |||
| 33 | == Authorization, Roles and HBP Units, Groups, and Teams == | ||
| 34 | |||
| 35 | This section outlines the HBP structure, and the workflow we suggest for validating identity and managing authorization. We provide an OIDC provider in our IAM service. We manage user accounts, and users which have an official capacity in HBP, partnering projects and the governance are placed in **units** according to their role in the project. Users also are placed within an institution, which is part of a country. We suggest that service providers create groups and assign them to units, other groups or individual users to manage permissions within their app. | ||
| 36 | |||
| 37 | Users should sign up with their institutional email which is regularly validated. They are then placed in a unit corresponding to the institution they belong to as well as the country it belongs in. This is all information about the user’s identity. We also provide the possibility to manage groups. | ||
| 38 | |||
| 39 | These **groups** can be used to assign a role to a user or unit. You can give Alice and all Work Package 3 members (/all/projects/hbp/consortium/SGA3/WP3/) a role called my-‘brain-team-viewer’. These units groups are available to services that have created and OIDC client. They can be used to manage permissions within your service. | ||
| 40 | |||
| 41 | === Units: the Organistational Structure === | ||
| 42 | |||
| 43 | Units represent the organisation structure of HBP, EBRAINS and partners. SGA2 accreditations are imported from the Collaboratory 1. For SGA3, accreditations are requested by asking to join a task. The task leader and work package managers can approve the user’s request. By accepting the request, the responsible person is granting an accreditation. The accreditor is responsible for removing the person from the unit upon departure. | ||
| 44 | |||
| 45 | The structure of units is the following: | ||
| 46 | |||
| 47 | * [[all>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all]] | ||
| 48 | ** [[projects>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects]] | ||
| 49 | *** [[hbp>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp]] | ||
| 50 | **** [[consortium>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium]] | ||
| 51 | ***** [[SGA2>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA2]] | ||
| 52 | ****** [[SP01>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA2:SP01]] | ||
| 53 | ****** … | ||
| 54 | ****** [[SP12>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA2:SP12]] | ||
| 55 | ***** [[SGA3>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA3]] | ||
| 56 | ****** [[WP1>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA3:WP1]] | ||
| 57 | ******* [[leader>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA3:WP1:leader]] | ||
| 58 | ******* [[coleader>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA3:WP1:coleader]] | ||
| 59 | ******* [[manager>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA3:WP1:manager]] | ||
| 60 | ******* [[T1_01>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA3:WP1:T1_01]] | ||
| 61 | ******** [[leader>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA3:WP1:T1_01:leader]] | ||
| 62 | ******* … | ||
| 63 | ******* T1_N | ||
| 64 | ******** leader | ||
| 65 | ****** … | ||
| 66 | ****** [[WP9>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:consortium:SGA3:WP9]] | ||
| 67 | **** [[governance>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:governance]] | ||
| 68 | ***** [[SIB>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:governance:SIB]] | ||
| 69 | ***** [[SIAB>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:governance:SIAB]] | ||
| 70 | ***** [[DIR>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:governance:DIR]] | ||
| 71 | ***** [[SB>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:governance:SB]] | ||
| 72 | ***** [[EAB>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:projects:hbp:governance:EAB]] | ||
| 73 | *** [[hbp_pp>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:hbp_pp]] | ||
| 74 | **** … | ||
| 75 | ** [[institutions>>url:https://wiki.ebrains.eu/bin/view/Identity/#/units/all:institutions]] | ||
| 76 | *** //country// | ||
| 77 | **** //institutions…// | ||
| 78 | *** … | ||
| 79 | |||
| 80 | Users' units under /all/projects/hbp/consortium/SGA3 are validated by the Work Package managers and task leaders. Institutions are validated by veryfing the users' access to their official email. | ||
| 81 | |||
| 82 | === Groups: User managed === | ||
| 83 | |||
| 84 | Users can request a special permission to be able to create groups. User managed groups can be [[searched for in the identity app>>url:https://wiki.ebrains.eu/bin/view/Identity/#/groups]]. The list of groups a user belongs to can be found by querying the [[userinfo>>url:file:///home/villemai/projects/hbp/documentation/oidc/oidc.html#userinfo]] endpoint with the user’s access token. | ||
| 85 | |||
| 86 | === Teams === | ||
| 87 | |||
| 88 | Teams are special groups associated with a Collab. A team has Each collab has three gro | ||
| 89 | |||
| 90 | TODO: Can client holders create client roles? | ||
| 91 | |||
| 92 | == For Service Providers == | ||
| 93 | |||
| 94 | If you wish to create a service or an application that integrates into the Collaboratory, this section explains how to proceed. | ||
| 95 | |||
| 96 | === Registering a Client === | ||
| 97 | |||
| 98 | To register a client, [[follow the instructions here>>url:https://wiki.ebrains.eu/bin/view/Collabs/collaboratory-community-apps/Community%20App%20Developer%20Guide/1.%20Registering%20an%20OIDC%20client/]]. | ||
| 99 | |||
| 100 | === ID, Access & Refresh Tokens === | ||
| 101 | |||
| 102 | === OIDC Endpoints === | ||
| 103 | |||
| 104 | ==== Userinfo ==== | ||
| 105 | |||
| 106 | === Connecting to a Protected Backend Service === | ||
| 107 | |||
| 108 | == For Users == | ||
| 109 | |||
| 110 | === Scopes === | ||
| 111 | |||
| 112 | The Collaboratory 2.0’s IAM server tracks the authorization that a user has granted to services. These are the OAuth scopes. It will be explained in more details below. The IAM server also tracks information about the users which can be relevant for authorization within a service. | ||
| 113 | |||
| 114 | |||
| 115 | == Community App in Collabs == |