XperienCentral has a flexible component for maintaining backend users (casual users, editors, developers, and application managers) and their privileges. The authorizations are assigned at the role level (type of responsibility). The roles determine which websites (or parts thereof) a user may maintain, which functionalities may be used, and which content elements the user may work with. To access the Authorization panel, navigate to Configuration > Authorization.
User authentication can also be accomplished by developing a plugin that implements the XperienCentral Credentials Service Provider. This Java class makes it possible to use a credentials provider that is external to XperienCentral. Click here for more information.
Beginning in XperienCentral 10.18, some parts of user management have been changed from previous XperienCentral versions. Expand the section below that corresponds with your version of XperienCentral.
In This TopicComponentsThe authorizations within XperienCentral are divided into two types:
In the Workspace environment, authorization management has been further divided into the following components:
Another related functionality is Workflow. Workflows control the allowed transition from one state to another for content items before they are allowed to be published on the web. The website administrator defines these states and configures their behavior. The states are then linked to user roles, which gives actual shape to the workflow. This XperienCentral functionality is based on the standards defined by the Workflow Management Coalition (WfMC). Role Based Access Control (RBAC)Many RBAC models exist, but XperienCentral uses the Core RBAC and Hierarchical RBAC models. These models conform to the standard RBAC specification developed by ANSI/INCITS. Roles and permissionsRole Based Access Control (RBAC) avoids the need to assign permissions to each user individually. Instead, permissions are assigned to roles. A role is a functional or organizational job description in which users sharing the same role share the same tasks. These roles then are assigned to users. The permissions of a role determine which operations a user may perform. RBAC is considerably less labor intensive than assigning permissions to each user individually. A user may have more than one role. An example of a permission is "Edit pages", which grants the permission to modify a page. In the example above:
XperienCentral comes with a default set of roles and permissions. Permission groupsNevertheless, defining proper permissions for each role may be a quite laborious operation. For this reason permission groups are introduced. A permission group is a default set of permissions which can be assigned to a role at once. A permission group assigned to a role will implicitly assign all permissions contained by that permission group to that role.
XperienCentral comes with a standard set of permission groups, see Default Authorizations for more information. Permission inheritancePermissions can be assigned in two ways: directly and by means of permission groups. To make things even more flexible, a third way has been introduced: permission inheritance. With permission inheritance, a role has assigned another role to it from which it inherits all permissions which means a child role gets all permissions from its parent role, irrespective of how these permissions have been assigned to the parent role.
XperienCentral comes with a standard set of roles that inherit from each other, see Default Authorizations for more information. Default AuthorizationsXperienCentral comes standard with the users, roles and permission groups listed below.
Developers are treated differently than all other users. Unlike all other users, developers are able to:
Basic set of permission groups by categoryXperienCentral comes with five standard permission groups. In the "Roles" tab of the Authorization anel you can see which permissions each role has or can be assigned. Maintaining RolesSelecting and Viewing a RoleTo select and view a role:
|
For security reasons, if you create/modify a user's password, the first time that they log in to XperienCentral after the modification, they must change their password. The only exception to this rule is when you change your own password. |
This option is only available if the option |
The ability to define system users was introduced in XperienCentral R28. |
In XperienCentral, a special designation of system user is required for automating the content item Import/Export functionality. Import/Export automation executes import/export jobs on a scheduled basis and requires access to XperienCentral at the system user level. To designate a user a system user, select "Is system user":
All users designated a system user can be selected from the user drop-down lists in the Import/Export configuration. The rest of the configuration for the system user is the same as for a normal user. In general, a system user account is not meant to be used for purposes other than executing the import/export jobs. GX recommends that you give system users the role of Application Manager and that you use an application key if possible. See Import/Export Configuration.
To modify a user's details, follow the steps below. You cannot modify a user's details when they are in an inactive state.
Modify the user's details.
Click [Apply].
For security reasons, if you modify a user's password, the first time that they log in to XperienCentral after the modification, they must change their password. The only exception to this rule is when you change your own password in the Authorization Management panel. |
In order to have access to XperienCentral, every user must have at least one role. You can assign users and roles to one another in two ways:
To assign a role to a user:
You can separate roles and users from one another in two ways:
To remove a role from a user:
Beginning in XperienCentral version 10.18, users can no longer be deleted from XperienCentral but only made inactive. |
Users in XperienCentral have a state which is either "active" or "inactive". Active users are able to log in and work in XperienCentral. Inactive users are not allowed to log in to XperienCentral. When an inactive user tries to log in, they will receive an error message which states that their username and/or password are invalid. To change the state of a user, click the "Active" or "Inactive" button in the "State" column next to the user's name. For example:
The state will change to the opposite of what it currently is. When you change a user from the inactive state to the active state, they will once again be allowed to log in to XperienCentral. The last password that they used is their valid password.
|
To allow users of another website (channel) to access to the current website, their user data can be imported. Imported users maintain the same user name and password. Different websites, however, can have different permissions assigned to their roles.
To import users:
An external application can log in to XperienCentral via the REST API. This makes it possible for external applications to access XperienCentral content. In order to be able to do so, you have to generate an application key for a user.
An application key is tied to a user, which means that the application key used by an external application inherits the role and permissions from the user for whom the application key is generated. For this reason, be sure that you generate an application key with sufficient permission(s) in order for the external application to be able to perform the task(s) for which it is designed. When performing REST calls, the application key should be placed in the custom X-GX-AppKey HTTP
header.
To generate an application key for a user, follow these steps:
X-GX-AppKey HTTP
header.In This TopicComponentsThe authorizations within XperienCentral are divided into two types:
In the Workspace environment, authorization management has been further divided into the following components:
Another related functionality is Workflow. Workflows control the allowed transition from one state to another for content items before they are allowed to be published on the web. The website administrator defines these states and configures their behavior. The states are then linked to user roles, which gives actual shape to the workflow. This XperienCentral functionality is based on the standards defined by the Workflow Management Coalition (WfMC). Role Based Access Control (RBAC)Many RBAC models exist, but XperienCentral uses the Core RBAC and Hierarchical RBAC models. These models conform to the standard RBAC specification developed by ANSI/INCITS. Roles and permissionsRole Based Access Control (RBAC) avoids the need to assign permissions to each user individually. Instead, permissions are assigned to roles. A role is a functional or organizational job description in which users sharing the same role share the same tasks. These roles then are assigned to users. The permissions of a role determine which operations a user may perform. RBAC is considerably less labor intensive than assigning permissions to each user individually. A user may have more than one role. An example of a permission is "Edit pages", which grants the permission to modify a page. In the example above:
XperienCentral comes with a default set of roles and permissions Permission groupsNevertheless, defining proper permissions for each role may be a quite laborious operation. For this reason permission groups are introduced. A permission group is a default set of permissions which can be assigned to a role at once. A permission group assigned to a role will implicitly assign all permissions contained by that permission group to that role.
XperienCentral comes with a standard set of permission groups, see Default Authorizations for more information. Permission inheritancePermissions can be assigned in two ways: directly and by means of permission groups. To make things even more flexible, a third way has been introduced: permission inheritance. With permission inheritance, a role has assigned another role to it from which it inherits all permissions which means a child role gets all permissions from its parent role, irrespective of how these permissions have been assigned to the parent role.
XperienCentral comes with a standard set of roles that inherit from each other, see Default Authorizations for more information. Default AuthorizationsXperienCentral comes standard with the users, roles and permission groups listed below.
Developers are treated differently than all other users. Unlike all other users, developers are able to:
Basic set of permission groups by categoryXperienCentral comes with five standard permission groups. In the "Roles" tab of the Authorization anel you can see which permissions each role has or can be assigned. Maintaining RolesSelecting and Viewing a RoleTo select and view a role:
|
For security reasons, if you create/modify a user's password, the first time that they log in to XperienCentral after the modification, they must change their password. The only exception to this rule is when you change your own password. |
Container-based access — The user many log in from a backend container-based application.
This option is only available if the option |
To modify a user's details, follow these steps:
For security reasons, if you modify a user's password, the first time that they log in to XperienCentral after the modification, they must change their password. The only exception to this rule is when you change your own password. |
In order to have access to XperienCentral, every user must have at least one role. You can assign users and roles to one another in two ways:
To assign a role to a user:
You can separate roles and users from one another in two ways:
To remove a role from a user:
To delete a user:
To allow users of another website (channel) to access to this website, their user data can be imported. Imported users maintain the same user name and password. Different websites, however, can have different permissions assigned to their roles.
To import users:
An external application can log in to XperienCentral via the REST API. This makes it possible for external applications to access XperienCentral content. In order to be able to do so, you have to generate an application key for a user.
An application key is tied to a user, which means that the application key used by an external application inherits the role and permissions from the user for whom the application key is generated. For this reason, be sure that you generate an application key with sufficient permission(s) in order for the external application to be able to perform the task(s) for which it is designed. When performing REST calls, the application key should be placed in the custom X-GX-AppKey HTTP
header.
To generate an application key for a user, follow these steps:
X-GX-AppKey HTTP
header.