User Accounts

As a user (administrator, partner, backend user) I want to use my existing accounts from an OAuth Provider like LinkedIn, Google, Facebook, or especially login.ez.no. By using these providers, I use my username and password from this providers to login to local eZ installation. The access rights for my account are still managed in the User Database of eZ as this is the only place that is aware about the access rights that a certain roll should have.

Roles

The above implies that there is still a full user account in the DB of eZ as all access rights to the eZ Platform installation can only be managed there as this us specific to each installation. To bridge the gap between user account (sign in right linked via OAuth to a trusted external service – short “OAuth Account”) a role management is needed. Each OAuth Account has at least one role that is linking the OAuth Account to set of access rights in the ez Platform installation.

Service Roles

In addition to existing useful sets of access rights like “Administrator”, “Editor”, “User” there are new default rolls that support certain special setups. E.g. a role for “Implementation Partner”, “eZ Services”, “eZ Support”. The roles are mapped to a certain set of rights that support e.g. the implementation partner to do whatever the customer wants to allow the partner to do in an installation. The advantage for the partner would be to use always the preferred login provider to login to all his customer installations. The administrator of the customer could restrict the access to the parts that the partner should be able to access.
Another use case is a special role like eZ Services that would have access to all parts but only with read only to do an audit without getting a full administrative access which us usually the case today. By handing over the login.ez.no account name to the customer, the admin could assign this user name to the role “eZ Support” without the need to do any unsecure password transmission and the consultant or support person just need to login with the login.ez.no credentials.

Login to eZ Services

Login to an eZ Service is different but uses basically the same mechanism of roles assigned to external authentication. The eZ Service login is not linked to a single user in the first step (can be changed later when a higher integration between login.ez.no and a eZ Installation is intended e.g. in a cloud environment). The access would be limited to users who have assigned to a certain role in the eZ Platform installation of the customer. There should be for example two roles for eZ Personalization. One for administrators with full access and another one for read only and see statistics and settings. The local eZ Platform installation (Client) (see https://alexbilbie.com/guide-to-oauth-2-grants/ for more information) only need to provide the two roles and the local user accounts that have credentials from matching an account in login.ez.no (Authorization server) should have a credential for this user (Resource owner) that is recognized be the an can give tokens to access the eZ Personalization service (Resource server).

Screen representation of eZ Services

This is part of another Epic (see reference) and covered in more detail there but to understand the usage of the credentials and the access to it is covered here.
The backend user of eZ Platform/Studio will navigate in the backend (see attached screens) and access the service tab. When he opens the service tab he will see the navigation of this service that is natively integrated into the eZ backend. The screens for each page of the navigation element are dynamically build based on the response from the REST API results provided by the eZ services (e.g. for eZ personalization this would be statistical graphs on the first screen). If the authentication can’t start because there are no “user credentials” (credentials to ask login.ez.no for a token to access the API as described above) as the user has not “booked” an access yet an alternative URL is called a registration page is presented to the user. Here he can swipe his credit card and book the access to eZ Personalization. Alternative ways to register eg. with an existing subscription contract of eZ Studio users can be implemented without any impact on the local eZ installation has everything is handled on the server side. As a result of such a registration there need to be an “return URL” that can store the user credentials in the local installation and grant the access of this user the eZ Personalization Admin role.