As a user, you will face Dream User management when logging in to the system and using the services with different roles and permissions, or when modifying your personal preferences in the Profile. In these situations, Dream user database and authentication systems work under the hood to enable you correct access rights to correct information.
Dream User Database (UserDB, DUD) is the central place for user account information and permission management. Each user has so called Dream ID which is used in all services connected to the User Database.
User identity wise there are two sides in the system. The Identity Provider, or IdP which acts as a source of user identity. And the Service Provider, or SP. This terminology comes from SAML and Shibboleth world.
The Dream UserDB provides 3rd party services way to identify, authenticate and authorize users in the Dream platform.
Each service can register service specific permissions to the Dream UserDB. These permissions are then provided to the service when user logs in to the system.
Services in use can be selected per organisation, and services see only those users they are allowed to see. This is handled by Dream UserDB. It is the responsibility of the service to check if the user should have access to the service or not, and what actions the user can do inside the service.
The service can use the data provided back in authentication requests as attributes. Or the service can request access to the Dream UserDB API to query data directly from the database.
User provisioning should be automatic when the user logs in to the service for the first time. It is each services responsibility to handle this the way the service sees best.
User identity wise there are two sides in the system. The Identity Provider, or IdP which acts as a source of user identity. And the Service Provider, or SP. This terminology comes from SAML and Shibboleth world.
Dream User API (v1) gives services access to all data in the database. The API can also be used for provision and for synchronizing users and other data from external systems to the database.
API includes: User, Group, Organisation, Role and Permission. These enable for example following use case:
User Teppo belongs to organisation kasavuori and has role teacher in that organisation. The role teacher, in kasavuori, has been given permission to dscms.article.create_article. Now Teppo has permission to add new articles in the CMS service to kasavuori website.
Update your browser to view this website correctly.