Kentico 8.1 - Kentico 10 Documentation

Kentico 8.1 - Kentico 10 Documentation
Kentico 8.1
1. Managing users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Security model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 User management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Impersonating a different user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Managing my profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Role management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Membership management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Configuring the application dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Configuring permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1 Configuring page permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1.1 Permissions for all content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1.2 Permissions for page types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1.3 Page-level permissions (ACLs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1.4 Hiding pages in the content tree based on permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.2 Configuring design permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 User registration and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1 Configuring forms authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.1 Using the Registration form and Custom registration form web parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2 New user registration approval and e-mail confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.3 Customizing user registration e-mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2 Configuring multi-factor authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.3 Configuring Windows AD authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.3.1 Securing a website section using Windows authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.3.2 Configuring mixed-mode authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.4 Claims-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.5 Windows Live ID authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.5.1 Registering your application to Windows Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.5.2 Configuring Windows Live ID authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.5.3 Web parts available for Windows Live ID authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.6 OpenID authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.6.1 Web parts available for OpenID authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.7 Facebook authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.7.1 Loading user information from Facebook profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.8 LinkedIn authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.8.1 Creating your LinkedIn application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.8.2 Web parts available for LinkedIn authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.9 Managing users coming through a third-party authentication service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.10 Configuring autocomplete for user names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.11 Sharing user accounts between sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.12 Configuring single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.13 Logon troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8 Customizing the format of usernames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.9 Monitoring on-line users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.9.1 Enabling monitoring of on-line users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.9.2 Managing on-line users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10 UI Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.1 Example - UI personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.11 Allowing users to change the information they share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.12 Sending e-mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.13 Displaying personalized content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
8
9
9
11
13
15
17
17
18
19
21
22
23
24
24
26
27
28
30
33
35
36
40
41
42
43
43
45
46
48
49
50
51
52
52
53
53
55
55
56
57
57
58
59
60
63
64
Managing users
User management
Manage the users who work with the system and assign them to sites. Manage the actions that the user performs on the site by
assigning the user to roles.
Role management
Map permissions to reusable user groups, such as editors or designers, to which you then assign specific users.
Permissions
Control the sections of the system that, pages and custom tables that users can access.
User registration
Allow visitors set up their own accounts on your site. Provide a way for visitors with existing Live ID, OpenID, Facebook or LinkedIn
accounts to sign in on your site.
UI Personalization
Set up the interface for various users in the system. This enables you to tailor the experience users have when working with Kentico
based on their roles.
Community features
Features that you can use to enhance the experience of users on your site. Allow users to identify themselves, communicate and form a
community.
Security model overview
Kentico provides a flexible security model that allows you to configure granular access permissions for pages and applications in the
administration interface.
The security model consists of:
users (shared among websites)
roles (defined for websites or globally for all sites in the system)
memberships (collections of roles that can be assigned to users)
module permissions (permissions for specific features in Kentico)
page permissions (ACLs, content and page type permissions)
UI personalization (hiding components of the user interface)
Relationships between users, roles and permissions
The following figure shows how users are assigned to roles and how permissions for pages and applications are granted to users and roles:
Users can be members of any number of roles. Permissions for particular pages can be granted to users directly. If you want to grant module
permissions to a user, you need to make the user a member of a role, and grant the permissions to the role.
Each user has a privilege level that controls access to the administration interface, and can override permission requirements (for
administrator levels).
Roles in Kentico are fully customizable. You are not limited to a predefined set of roles. Instead, you can define your own roles with custom
sets of permissions.
If a user is a member of multiple roles, their permissions for modules are calculated as a sum of all permissions granted to all roles.
If permissions for pages in Kentico repository are granted to both a user and their roles, page permissions are calculated as a sum of all
permissions granted to the user and to all roles. If you deny a page permission for a user or one of their roles, then the result is always
"denied" for the given permission, even if some of the roles are allowed to perform the action.
User management
A user can be a member of any number of roles and can be assigned to any number of websites.
Each user account has a Privilege level:
Privilege level
Description
None
The user cannot access the system's administration interface.
Ability to view pages and perform actions on the live site depends
on the site's security options and the roles assigned to the user.
Editor
The user can access the administration interface and on-site
editing mode for all sites assigned on the Sites tab.
The Editor privilege level does not grant any permissions — it only
differentiates between site editors and registered users who are
limited to the live website. To allow editors to access applications
and perform actions, you need to assign roles.
Administrator
The user has unrestricted access to non-global applications for all
sites in the system (administrators skip permission and UI
personalization checks).
However, administrators CANNOT:
Use global applications that affect the entire system
Perform certain actions restricted only to global administrators
Upgrade the privilege level to global administrator for their own
account
Grant users the administrator privilege level
Edit the user accounts of other administrators
Global administrator
_________________
Default user accounts
The user has full access to all parts of the system for all sites, and
can perform any operations (regardless of permissions or other
settings). Global administrators are the only users who can work
with global applications.
The following default user accounts are available:
Administrator - global administrator user with full permissions.
Public - user that represents an anonymous visitor of the site.
Creating a new user
New user accounts are typically created when a user goes through registration on the live site. However, you can also create accounts
manually in the Users application. Click New user and configure the properties.
User name
The user's user name (login). By default, it must be unique across
all websites in the system.
Full name
User's full name (first name, middle name and last name).
E-mail
User's e-mail address.
Enabled
Indicates if the user account is enabled and the user can sign in.
Privilege level
Sets the user's privilege level (see the privilege level table).
Password
User's password.
Confirm password
User's password again for confirmation.
User passwords
It is highly recommended to set a safe password for every user account to ensure the security of your website. Global
administrators can monitor the list of users for accounts that have empty passwords, which are marked with a warning icon (
).
You can add a password manually by editing the given users on the Password tab.
The system can be configured to require users to enter passwords matching specific strength requirements. For more information,
see Password strength policy and its enforcement.
Editing user properties
To edit user properties, open the Users application. Click Edit (
) next to the required user.
General properties
You can set the following properties on the General tab:
User name
The name used to log in to websites and the system's
administration interface. By default, user names must be unique
across all sites in the system.
Full name
User's full name (first name, middle name and last name).
First name
User's first name.
Middle name
User's middle name.
Last name
User's last name.
E-mail
User's e-mail address.
Enabled
Indicates if the user account is enabled and the user can sign in.
Privilege level
Indicates if the user is allowed to access the administration
interface, and affects how the system checks permissions.
See the privilege level table for details.
Is external user
This attribute is used when you are using an integration with an
external user database.
Is domain user
Indicates if the user was imported from Active Directory. See Impor
ting users and roles from Active Directory for instructions.
Is hidden
If true, the user is not visible on the site (e.g. on-line user
monitoring, repeaters displaying users, etc.).
Preferred content culture
Preferred culture in which the content is displayed to the user.
Preferred user interface culture
Preferred culture in which the users wants to see the administration
interface.
Created
Date and time when the user account was created.
Multi-factor authentication is required
Indicates if the Multi-factor authentication is enabled for the
particular user, if the Enable multi-factor authentication is
SELECTED and the Multi-factor authentication is required
globally is CLEARED.
Reset token ID
Resets the user's token ID, which is used to pair the user account
with the mobile application.
Last logon
Date and time when the user last logged in.
Last logon information
Information about the IP address and browser user agent of the
user's last logon.
Invalid logon attempts
The number of unsuccessful attempts to log in with a wrong
password. You can reset the value to zero and unlock the user's
account by clicking the Reset & enable button.
Password expires in
The number of days left until the user's password expires. You can
reset the validity to the maximum value by clicking Extend validity
& enable.
Starting alias path
Allows you to limit the user to a specific section of the content tree
when using the Pages application. If you set a value, the user
cannot see other parts of the website in the content tree.
Note: This feature is only intended for better usability and does not
ensure security control. If you need to establish access rights for a
given user, grant appropriate page permissions on the Properties
-> Security tab.
Password
Here you can change the user's password:
Password - user's password.
Confirm password - user's password again for confirmation.
You can either enter a new password directly, or have the system generate a new one. The tab also provides the option to send an automatic
notification email to the given user containing the new password.
This tab is hidden if the edited user is authenticated using either an external user database or Active Directory, i.e., if the user has the Is
external user property enabled on the General tab of the user editing interface or if Is domain user is enabled and the application is
configured to use Windows authentication.
Settings
On the Settings tab, you can edit the following properties of the user:
User nick name
Nick name of the user used in website forums, on the user's profile,
etc.
User picture
User's avatar image. The image appears in forums and on the
user's profile. You can either upload an image or select a
pre-defined avatar.
User signature
User's signature that will be used below the user's forum posts.
Description
Optional text describing the user.
URL referrer
URL from that the user came to the site when they performed
registration.
Campaign
If the given user arrived on the website through a campaign before
registering, this field will store the name of that campaign. See Trac
king campaigns for details.
Messaging notification e-mail
Notifications about new messages received in the messaging
application will be sent to this e-mail address.
Time zone
User's time zone; if set, this time zone will be used where
applicable instead of the site time zone.
Badge
User's badge; depends on the number of gained activity points.
User activity points
Number of user's activity points; these points are gained for forum
posts, message board posts, blog posts and blog post comments.
Live ID
User's Live ID token; this is a hexadecimal number that the user is
identified by when logging-in via Windows Live ID.
Facebook user ID
User's Facebook user ID; it is used when the user is logging in via
Facebook Connect.
OpenID
User's OpenID; it is used when the user is logging in via OpenID.
LinkedIn ID
User's LinkedIn ID; it is used when the user is logging in via
LinkedIn authentication.
Activation date
Date of the user's account activation.
Activated by user
User who activated this user's account.
Registration info
User's IP and browser agent detected on registration.
Gender
User's gender.
Date of birth
User's date of birth.
Skype account
User's Skype account.
Instant messenger
User's instant messenger; format of values of the field is not strictly
required, you may use any string of characters according to your
specific needs (e.g. ICQ: 123456789).
Phone number
User's phone number; the number may be entered in any format,
no validation is applied.
Log activities
Indicates if the system logs on-line marketing activities for the user.
Waiting for approval
If checked, the user account is not active yet and is waiting for an
administrator's approval.
Show welcome tile
Indicates whether the application dashboard displays the welcome
tile that introduces the basics of the administration interface to new
users.
Forum posts
Number of user's forum posts.
Forum comments
Number of user's forum comments.
Blog comments
Number of user's blog comments.
Message board posts
Number of user's message board posts.
Custom Fields
Here you can edit the values of custom user fields. The custom fields can be defined in Modules -> Membership -> Classes -> User ->
Fields.
Sites
Here you can specify the sites that the user can work with in the administration interface. To assign the user to a site, click Add sites, check
the appropriate boxes in the displayed dialog and click Select.
The sites assigned here only limit access to the system's administration interface. Logging in on the live site is possible even for
users who are not assigned to the given site.
This is intended to allow the separation of access privileges for content editors responsible for different websites.
Roles
Here you can manage the roles to which the edited user is assigned. Depending on the permissions available for individual roles, the user
will be authorized to perform various actions on the website or in the administration interface. Refer to Role management for further
information about roles.
Departments
Here you can specify the E-commerce departments in which the user is authorized to manage products.
Notifications
On this tab, you can see a list of all notification subscriptions of the currently edited user. You can Delete (
unsubscribes the user from receiving notifications.
) subscriptions in the list, which
Categories
This tab displays a list of the user's custom categories. Categories are topic-related groups to which pages can be assigned. By clicking New
category, you can create new categories.
Friends
On this tab, you can manage the currently edited user's friends.
Subscriptions
On this tab, you can manage the user's subscriptions to newsletters, blog posts (comment notifications), message boards, forums and
reports.
Languages
On this tab, you can specify which cultural versions of pages can be edited by the user. You have the following options:
User can edit all languages - if selected, the currently edited user can edit pages in all language versions of all sites in the system
User can edit following languages - if selected, you can specify which language versions can be edited by the user by checking
the check-boxes in the list of language versions; this can be set separately for each site in the system using the Select site drop-do
wn list
Memberships
Here you can manage special types of website membership assigned to the edited user. Each membership represents a collection of roles.
When a membership is assigned to a user, it automatically authorizes that user to perform any actions allowed for all contained roles. Refer
to Membership management to learn more.
Impersonating a different user
Users with the Global administrator privilege level can "impersonate" other users. Impersonation means logging in to the system as a
different user. This is useful, for example, when you are setting up the environment for different users and want to test the interface or actions
as the other users.
Impersonating other administrators is not possible.
Actions carried out while impersonating a user are logged in the Event log under a user name in format <user name> (<original
user name>), where the original user is the administrator using the impersonate function.
To impersonate a user:
1. Open the User menu in the top-right corner of the interface.
2. Click Impersonate. A Select user dialog opens.
3. Click on the user that you want to impersonate.
a. If impersonating an editor (a user with the Editor privilege level), you are redirected to the application dashboard in the
administration interface.
b. If impersonating a standard user, you are redirected to the title page of the live site.
You can now perform actions as the user that you impersonated.
Cancelling impersonation
There are two ways in which you can cancel impersonation:
Cancelling impersonation of a user with access to the administration interface
1. Open the User menu in the top-right corner of the interface.
2. Click Cancel impersonation.
The system logs you in under the original administrator account.
Cancelling impersonation of a user without access to the administration interface
1.
1. Sign out of the live site.
2. Log in under your original administrator account.
Managing my profile
You can manage your user profile in the My profile application. Using this application, you can:
Set basic details of your profile, like nickname, e-mail, avatar and other settings on the Details tab.
Set a new password on the Change password tab.
View and cancel content notifications on the Notifications tab.
View and cancel subscriptions to newsletters, blog posts, message boards, forums and reports on the Subscriptions tab.
Create and manage personal categories on the Categories tab.
Role management
Roles are objects that define authorization options for users, i.e. which actions they are allowed to perform on the website and within the
Kentico administration interface. Roles provide an interface that maps permissions to users in a way that can easily be reused. Each role can
be assigned to any amount of users and vice versa – a user can be a member of an unlimited number of roles.
Managing roles
You can find the management interface for roles in the Roles application.
Roles can either be assigned to a specific site or defined as global objects that are available for all sites. In the Roles application, you can
select the site context using the Site dropdown list at the top of the page. To access the list of all global roles in the system, choose the (glob
al) option. Using global roles can save a lot of time when working with a large number of sites that require similar types of authorization
options. Global roles may only be assigned by users with the Global administrator privilege level.
You can specify the following properties when adding a new role:
Role display name
Sets a name for the role displayed to users in the administration
interface.
Role code name
Sets a name that serves as an identifier for the role.
Role description
Can be used to enter an optional text description for the role.
Is domain role
Indicates if the role was imported from Active Directory.
Code names of global roles
Code names are only checked for uniqueness within the context of individual sites, which means that it is possible for a global role
to have the same code name as a sitespecific role.
If you need to specify a global role using its code name in your custom website code or via the API, you can add the period
character (".") as a prefix. This ensures that only the global role will be selected and any site roles with the same code name will be
ignored (for example .Content_admin).
Editing a role
There are four tabs available when editing a role:
General
On this tab you can edit the basic properties of the role.
Users
Here you can add or remove users to/from the currently edited role. These users will be authorized to perform actions according to the
permissions granted to the role on the Permissions tab. Roles can either be assigned to users permanently or only until a specified date and
time.
If you wish to add users, click the Add users button and check the boxes next to the appropriate users in the displayed selection dialog.
Only users who are assigned to the same site as the role can be chosen (global roles may be assigned to all users in the system). The Valid
to field at the bottom of the dialog can be used to assign users to the role for a limited time only. Using the Calendar ( ) you can easily
select the exact date and time when the role should expire for the user. If this field is left empty, the users will be assigned to the role for an
unlimited time period.
The Change validity ( ) action that is available for every listed user may be used to prolong or shorten the time interval for which the user
should be assigned to the role. This way you can set an expiration date or reactivate expired roles for users.
Memberships
On this tab you can which memberships to which this role is assigned.
Permissions
On this tab you can configure which permissions should be assigned to the given role. If you wish to add permissions, select the type of the
permission that you wish to assign using the two drop-down lists. The system displays individual permissions for the specified module or
page type, which you can enable by checking the corresponding boxes.
UI Personalization
On the two sub-tabs under this category, you can choose which parts of the administration interface will be displayed to the members of the
given role. You can also change the settings of the WYSIWYG Editor for this particular role.
Individual interface elements can be configured on the Dialogs subtab. This is where you can select a module from the Module drop-down
list and then enable or disable the visibility of individual dialogs by checking the corresponding boxes. Only dialogs that are checked will be
displayed to users assigned to the given role.
You can adjust the WYSIWYG Editor settings for the given role on the Editor tab. You can make adjustments in a similar way as with
dialogs.
For more information, see UI personalization.
Dashboard
The Dashboard tab allows you to configure which applications will the members of the role have on their application dashboard.
See Configuring the application dashboard for more information.
Membership management
The Membership application allows you to define special types of user membership for the website (or globally for all sites in the system).
Within the security model of Kentico, membership objects perform a function similar to roles. Users that belong to memberships are
authorized to perform certain actions on the website, access secured content or similar. However, memberships do not directly allow
individual permissions, but instead group together one or more existing roles. When a membership is assigned, it grants the given user the
sum of all permissions defined for the contained roles.
Typically, a membership will be associated with a certain product, which can then be purchased by users through the website's ecommerce
features. This will allow them to gain access to restricted sections of the website or other types of premium content for a specified amount of
time. For additional information about how you can offer various types of website membership as products, see Managing E-commerce
memberships.
Memberships versus roles
Memberships are mainly intended to be used in combination with ecommerce for live site users and customers, or for other specific
purposes where an additional security layer that groups together multiple roles is useful.
If you need to define authorization options for different types of users, such as content editors or administrators for specific
applications, it is recommended to do so directly using standard roles.
Managing memberships
You can manage memberships in the Membership application.
Memberships can either be assigned to a specific site or defined as global objects that are available for all sites. You can select the site
context using the Site dropdown list at the top of the page. Only the Global administrator can manage global objects.
You can specify the following properties when creating a new membership:
Membership name - sets a name for the membership which is displayed in the administration interface.
Membership code name - sets a name that serves as an identifier for the membership.
Membership description - can be used to enter an optional text description for the membership.
There are four tabs available when editing a membership:
General
On this tab you can edit the same properties that were specified when the membership was created.
Roles
On this tab you can define which roles which the membership should contain. When the membership is assigned to a user, it will grant all
permissions allowed by the specified roles until it expires.
To add roles, click the Add roles button and check the boxes next to the appropriate roles in the displayed selection dialog. Only roles that
belong under the same site as the membership can be chosen (global memberships may only contain global roles).
If you need to add a role under multiple memberships, you can do this more quickly in the Roles application by editing the given role on its M
emberships tab. There you may easily assign the role to any number of memberships using a single action.
Users
On this tab you can view which users are assigned to the currently edited membership. For as long as their membership is valid, the listed
users will be authorized to perform any actions allowed for the roles that the membership contains, as defined on the Roles tab.
Typically users will be added automatically when they purchase the membership as a product, so it is not necessary to manually assign them
one by one. The purpose of this tab is to allow administrators to monitor the membership and override its settings if necessary.
If you wish to add users, click the Add users button and check the boxes next to the appropriate users in the displayed selection dialog. Only
users who are assigned to the same site as the membership can be chosen (global memberships may be assigned to all users in the
system).
Using the Valid to field you can specify the exact date and time when the membership should expire for the given users. If this field is left
empty, the users will be assigned to the membership for an unlimited time period. If you set an expiration date for the membership, you can
also check the Send notification box to enable email reminders that will be sent to the selected users before the membership becomes
invalid.
Using the Change validity ( ) action you can prolong or shorten the time interval for which the user should be assigned to the
membership. This way you can set an expiration date or reactivate expired memberships for users.
Products
This tab displays a list of products with which the membership is associated, as well as additional details. When purchased, these products
assign the membership to the customer along with the authorization options that it provides. Membership as a type of product is described in
Managing E-commerce memberships.
Setting memberships for users
It is also possible to directly manage the memberships of individual users via the administration interface in the Users application.
When editing a user, switch to the Membership tab where you can add or remove memberships to/from the user. Note that global
memberships can only be assigned by users with the Global administrator privilege level. Using this approach, you can set an expiration date
for each of the memberships assigned to the user.
Displaying memberships on the live site
The My account web part from the Membership -> Logon & Registration category can be used to allow users to view a summary
of their current memberships on the live site. If its Other tabs -> Display my membership property is enabled, the web part will
display a list of all memberships assigned to the current user and their expiration dates.
The web part may also be configured using its Memberships -> Memberships page URL property to generate a link to a page
where users can buy new memberships for the website or renew existing ones.
Membership expiration reminders
To help users keep track of their memberships and ensure that they know when it is necessary to renew a paid membership, the application
includes an automatic notification feature.
There is a global scheduled task named Membership reminder that periodically checks memberships (once per day by default) and sends a
notification email to users whose membership will expire within the amount of days specified by the Settings -> Security & Membership ->
Send Membership reminder (days) field. You can configure this task and setting as needed.
These reminders are only sent for memberships that were assigned with the Send notification flag enabled and for those that were
purchased as a product with a limited duration. The content of the reminder emails is taken from the Membership - Expiration notification
email template, which can be edited via the Email templates application.
When editing this email template, you can use the {% MembershipsTable %} context macro to insert a list of all memberships that will soon
expire for the given user. This list must be formatted via a Text/ XML type transformation, which you can specify through the ApplyTransform
ation method, for example:
{%MembershipsTable.ApplyTransformation("Ecommerce.Transformations.Order_MembershipsTable")%}
In addition to this special macro, you can also use all other standard macro expressions in the templates.
Configuring the application dashboard
The application dashboard allows users to quickly access their favorite and most frequently used applications. Administrators can change
what users in a role can see on the dashboard by default. Note that users can also individually adjust the applications they see on the
dashboard.
To change which applications users in particular roles have on their dashboard, assign roles, and configure the dashboard settings of the
roles:
1. Open the Roles application.
2. Select the Site containing the role or the (global) option.
3. Edit ( ) the role.
4. Open the Dashboard tab.
5. Add or remove the applications assigned to the role.
The assigned applications appear on the dashboard of all users who belong to the given role. For users with multiple roles, the dashboard
displays a combination of all applications assigned to the given roles. The system automatically filters the application dashboard for each role
based on permissions and UI personalization settings.
The Welcome to Kentico tile helps first-time users navigate in the Kentico interface. If you close this tile, you can set it to appear again for
individual users:
1. Open the Users application.
2. Edit ( ) a user.
3. Open the Settings tab.
4. Select the Show welcome tile check-box.
The system displays this tile for the chosen user on the Dashboard.
Tip: You can adjust the application dashboard of the default administrator account through the CMS Global Administrator global
role. The role does not grant any permissions, its only purpose is to define the content of the application dashboard for the default
global administrator.
How are applications defined in the system?
The system uses UI elements to represent applications.
You can view the tree of elements that define the system's user interface in Modules -> edit a module -> User interface. To find the UI
elements of applications, open the CMS -> Administration section of the tree and expand individual category elements.
Global applications
Some of the UI elements representing applications have the Is global application flag enabled. Global applications can affect the
entire system, and are only accessible by users with the Global administrator privilege level. Other users cannot see global
applications, even if you assign them to the dashboard for the user's roles.
Configuring permissions
Permissions provide a way to control access to particular sections of the administration interface (applications), pages in the content tree and
custom tables.
Assigning permissions
You can assign permissions in the Permissions application. Permissions can be assigned only to roles, not to individual users.
In addition to global roles defined for all sites in the system, every website has its own set of roles. Permissions are assigned to these
roles, which means that every website can use a different configuration of role permissions as necessary.
Site
Using the Site drop-down list, select a site whose roles you want to configure the permissions for. After you select a site, the available roles
appear in a list below.
Permissions for
Using the first Permission for drop-down list, you can choose from the following three types of permissions:
Modules - permissions for actions related to specific Kentico features.
Page types - permissions applied to all documents of a particular type. These permissions represent one level of the three-level
page permissions hierarchy, as described in Configuring page permissions.
Custom tables - permissions for custom tables.
Then you can select the appropriate module, page type or custom table from the second drop-down list and grant the permissions to roles
using the check-boxes.
If you do not have the global administrator privilege level, you may come across grayed-out check boxes:
Selected grayed-out check-box - the permission is granted to the role, and only global administrators can change it.
Cleared grayed-out check-box - the permission is not granted to the role, and only global administrators can change it.
These grayed-out check-boxes are also accompanied by a warning icon (
can only be granted to roles by global administrators.
) in the header row of the table, indicating that the permission
Report for user
As permissions are assigned to roles, not directly to users, it is possible to display a permission report for each website user using the Repor
t for user drop-down list. The system displays a sum of all permissions granted to the user's roles highlighted in green color. Roles where
the selected user is a member are highlighted in yellow color.
If you enable the Show only this user's roles check-box, only the yellow roles will be displayed in the matrix.
Permission-related settings for users
When editing users in the Users application, you can set the Privilege level. The privilege level provides an additional security layer and
affects how the system checks permissions:
Privilege level
Description
None
The user cannot access the system's administration interface.
Ability to view pages and perform actions on the live site depends
on the site's security options and the roles assigned to the user.
Editor
The user can access the administration interface and on-site
editing mode for all sites assigned on the Sites tab.
The Editor privilege level does not grant any permissions — it only
differentiates between site editors and registered users who are
limited to the live website. To allow editors to access applications
and perform actions, you need to assign roles.
Administrator
The user has unrestricted access to non-global applications for all
sites in the system (administrators skip permission and UI
personalization checks).
However, administrators CANNOT:
Use global applications that affect the entire system
Perform certain actions restricted only to global administrators
Upgrade the privilege level to global administrator for their own
account
Grant users the administrator privilege level
Edit the user accounts of other administrators
Global administrator
_________________
The user has full access to all parts of the system for all sites, and
can perform any operations (regardless of permissions or other
settings). Global administrators are the only users who can work
with global applications.
Configuring page permissions
Permissions for access to Kentico pages can be configured at three levels of a three-level permissions hierarchy. Click the links in the Page
permission level column to learn more about each of them.
Page permission level
Granted to
Applied to
Configurable in
Permissions for all content
roles
all pages
Permissions application
Permissions for page types
roles
all pages of one particular page
type
Permissions application
Page-level permissions (ACLs)
roles or individual users
one particular page
Pages application -> Properties
-> Security
Permissions from these three levels are merged together when checking if a user is permitted to perform an action with a page. For example,
to read a CMS.News page, a user must have the Read permission on at least one of the three levels: either on the pages-level, or for the CM
S.News page type, or for all content.
There is also one special setting that allows hiding of pages in the content tree depending on page permissions granted to the current user.
See the Hiding pages in the content tree based on permissions for more information on this possibility.
Permissions for all content
In the Permissions application, you can find a special permission matrix for controlling access to all pages within the content tree (in the Pag
es application). To modify the permissions for access to the content tree:
1. Choose Module from the first Permissions for drop-down list.
2. Choose the Content from the second drop-down list.
The following global permissions can be granted to particular roles:
Browse tree
Allows members of the role to view the page content tree in the Pa
ges application (not necessarily the actual page content – that is
determined by the Read permission). For users without this
permission, the system blocks the entire Pages tab.
Users also need this permission to perform page management
actions through the On-site editing interface.
Read
Allows members of the role to view the content and settings of
pages in the content tree. Additionally, users require this
permission to access the on-site editing interface.
Modify
Allows members of the role to modify any page in the content tree.
Note that for for approving or rejecting pages within a workflow, the
Manage workflow permission is sufficient.
Check in any page
Authorizes members of the role to perform the Check-in and Undo
check-out actions on the Properties -> Versions tab of a page's
editing interface.
Create
Allows members of the role to create pages of any page type in the
content tree.
Delete
Allows members of the role to delete any page in the content tree.
Manage workflow
Allows members of the role to approve or reject any page at any
workflow step. Note that the Modify permission is not necessary
for approving or rejecting pages.
Destroy
Allows members of the role to destroy (delete without the Undo opti
on) any page.
Modify permissions
Allows members of the role to manage page-level permissions of
any page in Pages -> Properties -> Security.
Submit for translation
Allows members of the role to create new language versions of
pages using Translation services.
Permissions for page types
Page type permissions control the access to all pages of a particular page type. These permissions are assigned to roles in the Permissions
application.
To modify the permissions for a particular page type:
1. Choose Page type from the first Permissions for drop-down list.
2. Choose the required page type from the second drop-down list.
You can grant the following page type permissions to particular roles:
Read
Allows members of the role to view any page of this type.
Modify
Allows members of the role to edit any page of this type.
Create
Allows members of the role to create pages of this type. With this
permission, users must also have the Create page-level
permission on the parent page under which they want the new
page to be created.
Create anywhere
Allows members of the role to create pages of this type anywhere
in the content tree, without the need to have the Create page-level
permission on the parent page under which they want the new
page to be created.
Delete
Allows members of the role to delete any page of this type.
Destroy
Allows members of the role to destroy (delete without the Undo opti
on) any page of this type.
Browse tree
Allows members of the role to see pages found under pages of this
type in the content tree.
Modify permissions
Allows members of the role to manage page-level permissions of
all page of this type in Pages -> Properties -> Security.
Page-level permissions (ACLs)
You can manage page-level permissions (i.e., permissions for a particular page or a particular website section) in Pages application on the P
roperties -> Security tab. Select the appropriate user or role in the box and choose if the permissions are allowed or denied:
Allow - the action is allowed for the user or role.
Deny - the action is not allowed even if the user or role has the permission assigned on a global level — the Deny option overrides
settings for this permission on the other two levels.
The following permissions can be allowed or denied:
Full control
Allows the user or members of the role to perform any action with
this page.
Read
Allows the user or members of the role to view this page.
Create
Allows the user or members of the role to create new pages under
this page.
Modify
Allows the user or members of the role to edit this page.
Delete
Allows the user or members of the role to delete this page.
Destroy
Allows the user or members of the role to destroy (delete without
the Undo option) this page.
Browse tree
Allows the user or members of the role to see pages found under
this page in the content tree.
Modify permissions
Allows the user or members of the role to manage page-level
permissions of this page in Pages -> Properties -> Security.
Permission inheritance
You will typically need to set up permissions for site sections rather than for particular pages. In this case, you can grant permissions for the
section's parent page and inherit them by all child pages.
Example
Consider a website structure like this:
Root
Home
News
Products
Category 1
Category 2
You may want to grant the following permissions to the users:
JohnS
Marketing manager
John can manage all content.
MarkJ
Product manager
Mark can manage only the pages in the
/Products section.
Grant the Full control permission on the
root to the user or grant permissions for the
CMS Content module to some of this
user's roles.
Grant the Browse tree permission on the
root to the user so that they can browse the
Products section.
Grant the Read, Modify, Create, Delete, D
estroy and Browse tree permissions on
the /Products page to the user. These
permissions are inherited by all child pages
under the /Products section.
Note: if you click the /Products/Category 1
page, the Browse tree permission is grayed
and disabled. It means that this permissio
n is inherited and cannot be removed you can only deny the permission (unless
you break inheritance - see below).
AliceM
Copy writer
Alice can modify the copy of all pages, but
Mark prefers to manage the copy of the
/Products section by himself only.
Grant the Read, Modify, Create, Delete an
d Browse tree permissions for the root to
the user.
Go to the /Products page and deny the Mo
dify, Create, Delete permissions to the
user so that Alice cannot modify the copy in
the /Products section.
It's recommended that you configure local permissions for roles and then only assign users to the appropriate roles. In this
example, you would first create roles "Marketing manager", "Product manager" and "Copy writer" and then configure their
permissions.
Copying permissions along with pages
If you copy, move or link a page, its permissions can be transferred along with it. You only need to enable the Copy/Preserve page
permissions option in the Copy/move/link page dialog.
This applies only to permissions configured for the particular page - parent or inherited permissions are not transferred. If you leave the
option disabled, the copy will inherit permissions from its parent in the target location.
Changing permission inheritance
In case you need to break permission inheritance and configure different permissions for some site section, click Change permission
inheritance... link on the Security tab.
If permissions are inherited by the current page, the following two options will be offered:
Break inheritance and copy parent permissions - breaks inheritance and adds parent permissions to the page, while original
permissions configured for the page are preserved.
Break inheritance and remove parent permissions - breaks inheritance and removes all permissions inherited from the parent,
while additional permissions configured for the page are preserved.
If you decide to inherit the permissions from the parent again, click the Change permission inheritance... link again. This time, the following
two options will be offered:
Restore inheritance to parent page permissions (current page only) - makes the current page inherit permissions of the parent
page.
Recursively restore inheritance to parent page permissions (current and all child pages) - makes the current page and all its
child pages inherit permissions of the parent page, while only pages which do not inherit parent permissions are affected by this
action.
Hiding pages in the content tree based on permissions
If you enable the Check page permissions option in Settings -> Content -> Content management, each user will only be able to see the
pages for which they have the Read permission assigned on any of the three levels. This applies in the Pages application, in page listings
and in various dialogs where the content tree is displayed.
If a user has the Read permission for a child page but not for its parent, the child page is not displayed as well. In case that a user doesn't
have the Read permissions for any page at all, a message is displayed instead of the content tree, saying that you have insufficient
permissions to see the root page.
See Settings - Content management.
Configuring design permissions
The Design permission matrix is used to set up important permissions related to the design of page templates and their components.
To access the matrix in the Permissions application:
1. Choose Module in the first Permissions for drop-down list
2. Choose Design in the second drop-down list.
You can assign the following permissions to members of the specified roles:
Wireframing
Allows users to edit the content of wireframe schematics in the Pag
es application on the Wireframe tab and create new wireframe
pages. Users without this permission can view wireframes, but are
not allowed to make any modifications.
Design web site
Allows users to edit pages on the Design tab of the Pages applicat
ion. Note that even though the changes on the Design tab are
made on a specific website, this may also affect other sites in the
system if they use the same shared page template.
This permission also determines whether the given role is allowed
to configure the properties of web parts through the On-site
editing interface.
Edit ASCX code
Allows users to modify the ASCX code of page layouts and
transformations. This permission does not affect the ability to edit
the HTML versions of these objects.
This should be considered a highlevel permission, because it gives
users the option to add and execute inline code.
Edit SQL code
Allows users to create or modify query objects and edit other fields
containing SQL code, such as the WHERE condition properties of
web parts.
This should be considered a highlevel permission, because it gives
users the power to write and execute SQL queries against the
website's database.
Destroy transformations
Allows users to delete the version history of transformation objects.
Destroy CSS stylesheets
Allows users to delete the version history of CSS stylesheet
objects.
Destroy page layouts
Allows users to delete the version history of shared page layouts.
Destroy page templates
Allows users to delete the version history of page templates.
Destroy web part containers
Allows users to delete the version history of web part containers.
Destroy web part layouts
Allows users to delete the version history of web part layouts.
For security reasons, the Edit ASCX code and Edit SQL code permissions may only be assigned by users with the Global administrator priv
ilege level.
User registration and authentication
If you want to allow visitors to register and sign in to your website, you can choose from a number of authentication methods. Kentico
supports forms authentication, Windows AD authentication and third party authentication. You can use only one of these options or a mix of
them and let the users choose the one that is the most convenient for them.
Internal authentication
Configuring forms authentication
The forms authentication stores user names and passwords in the database and requires users to register to your site before they can
log in. This is the default option.
You can allow users to register and sign in to your site by using the Registration form web part. See Using the Registration form and
Custom registration form web parts.
Configuring multi-factor authentication
The multi-factor authentication uses a combination of forms authentication and one other security factor (mobile application, SMS,
e-mail, etc.). Utilize our out-of-the-box solution, which uses a mobile phone application generating a login code or implement your own
solution.
External authentication
Configuring Windows Active Directory authentication
The Windows AD authentication gets user identity from the network credentials and automatically creates a corresponding user in the
database, including the user’s roles (if they exist in the Kentico database). Users are not required to enter their user names and
passwords when logging in to Kentico.
Configuring mixed-mode authentication
You can also use the forms and Windows AD authentication at the same time in a mixed mode. The users will be able to choose which
authentication method they will use when registering/logging in to your website.
Claims-based authentication
Hand over the authentication process to an external service called identity provider and provide your users with the comfort of single
sign-on mechanism.
Third-party authentication services
Third-party authentication services provide an alternative way for users to log in and register to your site. This way, they do not need to
go through the registration process and create a new user name and password for your site. Instead, they can use the same user name
and password that they already use on some popular site (like Windows Live, Facebook, LinkedIn, Google, Yahoo!, etc.). Even new
users can log in to your site like this, in which case the system creates a new user account in the database for them. To learn how to
manage the data of imported users, see Managing users coming through a third-party authentication service.
Kentico supports the following authentication providers:
Windows Live ID
OpenID
Facebook Connect
LinkedIn
Configuring custom external authentication
If you want to retrieve user and role information from an external source (such as a custom database), you need to configure the system.
Kentico allows you to write a custom authentication provider. In this way, the submitted user name and password are checked against
an external user profile source/authentication source. If the user is successfully authenticated, the user account is automatically
created/updated in the Kentico database, without copying the user password.
You can integrate your custom authentication provider with Kentico by handling the system's security events.
Other related tasks
Sharing user accounts between sites - learn how to share user accounts among all sites running on one Kentico installation.
Configuring single sign-on - learn how to enable users to authenticate once and gain access to multiple websites, which are either running on
a single domain or on different domains.
Accessing current user data in code
When the user is authenticated, a UserInfo object representing the current user is stored in the session variable CMSCurrentUser and is
accessible through the CMS.Membership.MembershipContext.AuthenticatedUser property. All operations after authentication then use
the user profile and user roles assigned to this object.
// Gets the user name of the current user
string userName = CMS.Membership.MembershipContext.AuthenticatedUser.UserName;
Membership provider and ASP.NET 2.0 Membership support
Kentico contains an ASP.NET 2.0 Membership provider for its user database. This means you can use ASP.NET 2.0 Membership API and
controls, such as Login control. However, Kentico uses its own user information database instead of the ASP.NET 2.0 Membership tables.
Configuring forms authentication
The forms authentication stores user names and passwords in the database and requires users to register to your site before they can log in.
The forms authentication is set as the default option. To allow users to register and sign in to your site, you only need to include the Registra
tion form web part on your site. See Using the Registration form and Custom registration form web parts.
Configuring forms authentication for multiple web projects
The forms authentication uses standard ASP.NET forms authentication and its settings, which you can find in your application's web.config fi
le:
<system.web>
...
<authentication mode="Forms">
<forms loginUrl="CMSPages/logon.aspx" defaultUrl="Default.aspx"
name=".ASPXFORMSAUTH" timeout="60000" slidingExpiration="true" />
</authentication>
...
<system.web>
If you're running multiple web projects in virtual directories, and the projects have the same machine key defined, users logging in to one of
the websites will be automatically logged in to sites running on other projects. To prevent that, add the path parameter to the above code in
each project, as in the following example:
<authentication mode="Forms">
<forms loginUrl="CMSPages/logon.aspx" defaultUrl="Default.aspx"
name=".ASPXFORMSAUTH" timeout="60000" slidingExpiration="true" path="Kentico" />
</authentication>
Additional configuration options related to user passwords may also be defined in the system, as described in the Securing user accounts
and passwords.
Using the Registration form and Custom registration form web parts
You can allow visitors to register on your site using the following web parts:
Registration form
Custom registration form
Using the Registration form web part
The Registration form provides a basic ready-made registration form. You can place the web part onto any page without setting any
properties. Adjust the properties if you want to modify the default behavior of the registration form.
The password field in the form supports validation according to the password policy specified for the website and also calculates and displays
the relative strength of the currently entered password. To learn more about the security options, see the Password strength policy page.
Using the Custom registration form web part
Use the Custom registration form for situations where you want a different registration form than the one provided by the Registration
form web part. For example when you want users to provide different information during registration or if you wish to customize the form's
layout.
The following example demonstrates how to add a custom registration form to your site. You need to prepare the custom registration form as
an alternative form for user objects.
Creating an alternative form for the User system object
1. open the Modules application.
2. Edit ( ) the Membership module.
3. Open the Classes tab.
4.
5.
6.
7.
Edit ( ) the User (cms.user) class.
Switch to the Alternative forms tab.
Click Create new form above the list.
Fill in the following details:
Display name: My registration form
Make new fields hidden: yes (checked) - ensures that the alternative does not display new fields added to the object by
default.
Combine with user settings: yes (checked) - ensures that the form contains all data fields related to users, including user
settings.
8. Click Save.
The system creates the alternative form and opens the form's editing interface.
Defining the form fields and layout
1. Switch to the Fields tab of the alternative form's editing interface.
Here you can see the fields (database columns) that the system stores for User objects.
2. Select the UserName field in the list on the left, and select the Display field in the editing form check box.
3. Click Save to confirm the change.
4. Repeat the same for the following fields:
FirstName
Email
UserPassword
5. For the UserPassword field, choose the Password with confirmation option in the Form control selector.
6. Go through the remaining fields and uncheck Display field in the editing form.
Adjusting the form layout
To define the registration form's layout:
1. Switch to the Layout tab of the alternative form editing interface.
2. Select Use custom form layout.
3. Click Generate default layout. A default table layout appears in the editor. You can adjust the layout according to your
requirements.
4. Click Save when you are finished.
Placing the form on a page
1.
2.
3.
4.
5.
Open the Pages application.
Select or create a page where you want to add the registration form in the content tree.
Switch to the Design tab.
Add the Custom registration form web part onto the page.
Select My registration form (cms.user.MyRegistrationForm) as the value of the web part's Alternative form property.
If you switch to the live site and view the page, you can see the custom registration form that you created. You can now try to register using
the form and verify that the user has been created in Configuration -> Users.
New user registration approval and e-mail confirmation
By default, users can sign-in to the site immediately after successful registration. However, you can also use the Registration requires
e-mail confirmation and Registration requires administrator's approval options, which can be enabled in Settings -> Security &
Membership. By enabling these options, you can include additional steps in the registration procedure.
Registration requires e-mail confirmation
If this option is checked, newly registered users will receive a confirmation e-mail to the e-mail address specified during registration. This
e-mail contains a confirmation link that the user has to click, in order to activate the account. The e-mail is based on the Membership Registration confirmation email template.
After clicking the link, the user is redirected to the page specified in one of the following settings:
the Registration confirmation page path setting in Settings -> Security & Membership.
the E-mail confirmation page property of the web part used for registration.
The page must contain the Registration e-mail confirmation web part to work correctly.
By default, the ~/CMSPages/Dialogs/UserRegistration.aspx page is used.
Registration requires administrator's approval
If this option is enabled, users will not be able to sign-in immediately after registration. Their registration will have to be approved by the site
administrator. At this point, users will receive an e-mail based on the Membership - Registration waiting for approval e-mail template.
If the option is enabled, the Waiting for approval tab will be displayed in the Users application. On this tab, site administrators can Approve
(
) or Reject (
) a user's registration.
After the administrator's approval, users receive another e-mail, confirming that their account has been approved and can be used. The
e-mail is based on the Membership - Registration approved e-mail template.
Enabling both e-mail confirmation and administrator's approval
When both of the options mentioned above are enabled, the e-mail with the confirmation link is sent first. After the user's confirmation,
registration will have to be approved by the administrator.
Default redirection
If you have one or both of the options enabled, it is important to properly set the Redirect to URL property of the web part used for
registration. This means that users should not be redirected to any page displaying information about their user account (like the Members ->
Profile page on the sample Community Starter site), because the account will not be active yet (it is waiting for e-mail activation or approval).
Such a page would display an error message, which might be misleading for the users.
E-mail notification addresses
In case you wish to use notification e-mails to inform administrators about new user registrations that require approval, the target address
cannot be specified via the registration web part itself if the e-mail confirmation is also enabled.
Instead, it must be entered into the properties under the E-mail settings category of the Registration e-mail confirmation web part placed
on the used confirmation page.
Third party authentication issues
Using the e-mail confirmation or registration approval in combination with third-party authentication services (Windows Live ID, Facebook, Op
enID, LinkedIn) may cause certain problems for firsttime users. In these cases, new users are by default created without an e-mail address
when they log in for the first time. This means that they cannot activate their account via e-mail confirmation or receive notifications informing
that their account must be approved by an administrator.
These issues can be avoided by creating a Required user data page where users must enter an e-mail address for their account.
If using Facebook authentication, you can load the required data from the user's profile automatically.
Customizing user registration e-mails
In the E-mail templates application, you can find the E-mail templates used for the automatic email notifications related to user registration.
Messages based on the following templates are sent to users when they register, depending on the site configuration (see New user
registration approval and e-mail confirmation for more information):
Membership - Registration - sent to new users as a welcome email after they successfully register (if the used registration web part
is configured to do so).
Membership - Registration confirmation - sent to users after registration if email confirmation (double optin) is required.
Membership - Registration waiting for approval - sent to users after registration if an administrator's approval is needed to
activate the account.
Membership - Registration approved - informs users that their account has been approved by an administrator.
The templates below are used for notifications sent to administrators:
Membership - Notification - New registration - notifies administrators when a new user registers on the site.
Membership - Notification - Waiting for approval - lets administrators know that a new user is waiting for their approval.
Any of these templates can be edited as needed, so you may fully customize the content of the emails. You can use the following macro
expressions to include dynamic values in the template text.
Note: Some of the macros are only available in certain templates.
{% FirstName %} - the first name of the new user.
{% LastName %} - the last name of the new user.
{% Email %} - the e-mail address entered during registration by the user.
{% UserName %} - the user name of the new account. If you are using site prefixes for user names, all occurrences of this macro in
email templates should have the prefix trimmed out through the following method: {%TrimSitePrefix(UserName)%}
{% Password %} - the password specified for the new account.
{% ConfirmAddress %} - returns the URL of the page where the user can confirm their registration (intended for sites where double
optin is enabled).
{% HomePageURL %} - resolves into the URL of the site's home page. This is only available in the Registration approved template.
In addition to the expressions listed above, you can also use any other macros in the templates.
Configuring multi-factor authentication
Multi-factor authentication is a type of authentication which requires a user's identity to be verified by more than one method. This technique
adds another layer of security for the sign-ins to the system.
Kentico uses the combination of classical forms authentication with username and password and one other authentication factor. You can
either use the provided out-of-the-box solution, which uses a mobile phone application as the second authentication factor, or you can
implement your own customized solution:
Forms authentication with a mobile application
Forms authentication with a custom authentication factor (e-mail, SMS, etc.)
Security and limitations
The multi-factor authentication is:
Available only for the default forms authentication method.
Not compatible with the Autocomplete functionality.
For security reasons, it is recommended to set Maximum invalid logon attempts to a small value, for example 5. Because incorrectly
submitted passcodes count as invalid logon attempts, a potential attacker will not be able to guess a valid passcode in the specified number
of attempts.
If screen locking feature is enabled, entering passcode is also required when unlocking the screen.
Multi-factor authentication using forms and mobile application
The multi-factor authentication method provided by Kentico uses a mobile application, Kentico Authenticator, to generate a special
passcode, which the users type to a form when signing in to Kentico. When a passcode expires, the users can use the mobile application to
generate a new one. During the first sign-in, the users are required to pair the mobile application with their user profiles in the system using a
generated token ID.
When a user wants to sign in to the system, the multi-factor authentication mechanism is executed in the following way:
1.
2.
3.
4.
5.
6.
A user wants to sign in and enters username and password.
The system verifies the information, displays a token ID and requests a passcode.
The user opens the Kentico Authenticator application on the mobile phone and types the token ID in.
When the user submits the token ID, the application generates a passcode.
The user types the passcode into the authentication web form.
The system authenticates the user.
The next time the user wants to sign in to the system, the authentication token ID is not required any more. The user only uses the
application to generate a new passcode and types the passcode into the web form.
You can download the Kentico Authenticator application for Windows Phone, Android and iOS devices.
Resetting user's token ID
Users need to type the token ID generated during the first sign in after the registration into their Kentico Authenticator mobile application. If
they do not manage to do this, they will not be able to log in with their user profiles.
If such situation happens, you can reset their token ID in the Users application -> edit a user -> General tab using the Reset token ID button
.
Enabling multi-factor authentication and configuring the related settings
The multi-factor authentication settings have global effect. They cannot be configured for individual sites.
Enabling multi-factor authentication for only selected users
1. Enable the multi-factor authentication in Settings -> Security & Membership -> Authentication by selecting the Enable
multi-factor authentication option.
When you select this option, users will be able to choose if they want to use multi-factor authentication for signing in to your
website. They can set this behavior when they register on the site through the Registration form web part.
2. Set the Multi-factor authentication is required option on the Users application -> General tab of the selected users profiles.
Existing users with this option selected will be required to use multi-factor authentication for signing in to your websites.
Enabling multi-factor authentication for all users in the system
Before you enable the multi-factor authentication globally, make sure that you will still have administrator access to the Kentico interface –
note down the Token ID for your account.
To enforce using of an additional security level for authenticating all users in the system:
1. Enable the multi-factor authentication in Settings -> Security & Membership -> Authentication by selecting the Enable
multi-factor authentication option.
2. Select the Multi-factor authentication is required globally option.
All users will have to use multi-factor authentication for signing in to your websites.
The Multi-factor authentication is required option on the Users application -> General tab will now have no effect.
Recovering administrator access
If you enable multi-factor authentication globally and lose access to your administrator account (token ID is not displayed when
signing in or you did not note it down), you can gain the access back by inserting the CMSAdminEmergencyReset key to the app
Settings section of your web.config. For example:
<add key="CMSAdminEmergencyReset" value="admin;password;true" />
admin - this value specifies the user name of the new account.
password - this value specifies the password for the new account – you should change it to your own value.
The third parameter is optional and indicates whether you want to create a new user with the Global administrator privilege
level.
The key will be automatically deleted after you gain access to the user interface.
Notes
Keep the Display initialization token option selected, if you want to use the out-of-the-box option (combination of the forms authentication
and the mobile application). Clear the check-box, if you plan to implement your own customized solution.
See Settings - Authentication.
Allowing users to enable or disable multi-factor authentication in their profiles
When you or new users enable the multi-factor authentication for their profiles, they will not be able to change this setting. If you want to
allow them to disable the multi-factor authentication for their profiles:
1.
2.
3.
4.
Open the Modules application.
Edit Membership -> Classes tab -> edit User -> Alternative forms tab -> edit Edit profile -> Fields tab.
Select UserMFRequired field in the list.
Select Display field in the editing form check-box.
Users will now have an option to disable the multi-factor authentication.
Configuring Windows AD authentication
Kentico supports Windows integrated authentication. It means that when a user signs in to a Windows domain, Kentico automatically
recognizes their identity without requiring a user name and password.
Additionally, the system is able to automatically import authenticated users from the domain (Active Directory), including their roles.
Prerequisite
For Windows authentication to work, the application must be able to access the following attributes of user objects in Active
Directory (i.e. the attributes cannot be protected or confidential):
memberof
userAccountControl
Configuring Windows authentication
Before you configure your project for Windows authentication, you need to create a user account for your current domain name and grant this
user account administrator permissions. This will allow you to access all features as an administrator once you sign in using Windows
authentication.
1. Open the Users application.
2. Create a new user with the following values:
User name: your domain user name in format domain-username, for example: office-johns
Full name: your full name
3. Click Save.
4. On the General tab, set the following values:
Privilege level: Global administrator
Is external user: yes
Is domain user: yes
5. Click Save.
Now you can switch the application to Windows authentication mode.
1. Edit the web.config file of the web project.
2. Set the mode attribute of the <authentication> element in the <system.web> section to Windows:
2.
<authentication mode="Windows">
3. (Optional) You can also make Windows authentication required for access to the live site. To achieve this result, uncomment the
following <location> element in your web.config:
<location path="">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
If you want to require Windows authentication for only part of the live website, see Securing a website section using
Windows authentication.
4. Save the modified web.config file.
5. Close all browsers with Kentico and open the website in a new browser.
6. Try to go to <site domain>/admin to make sure you are recognized as a global administrator.
If you encounter the 401 error, continue to the Enabling Windows authentication in IIS section below.
With this configuration, when an authenticated user comes to the site, the system automatically creates a matching user account in the
Kentico database and also imports the user's domain groups as roles. Active Directory users and roles are not imported on a regular basis,
but only when users arrive on the Kentico website.
Sign out button missing with Windows authentication
When Windows authentication is enabled, the Sign out button in user menu in the top right corner of the administration interface is
not displayed. The same applies to the live site, where the sign out link is not displayed in all web parts that can be used to sign
out.
Enabling Windows authentication in IIS
If you are experiencing the 401 error with Windows authentication, you need to enable Windows authentication in your IIS:
1. Start the Internet Information Services (IIS) Manager.
2. Locate and select your site in the IIS tree.
3. Double-click the Authentication icon.
Windows Authentication missing in the list
If your IIS installation does not contain Windows Authentication by default, you need to install it:
a.
b.
c.
d.
Go to Control Panel -> Programs and Features -> Turn windows features on or off.
Expand Internet Information Services -> World Wide Web Services.
Under Security, select the Windows Authentication check box.
Click OK to finish the configuration.
Windows Authentication appears as an option in IIS website authentication settings.
4. Select Windows Authentication.
5. Click Enable in the Actions menu.
IIS now allows Windows authentication on your site.
Forbidden character replacement during Active Directory import
When importing users and roles, forbidden characters in the names are replaced by the character defined in Settings -> URLs and SEO ->
Forbidden characters replacement.
The default value is a dash "-" (domain-username instead of domain\username). If you are using a different character, please change the
entered user name accordingly.
You can override this setting by adding the following keys to the AppSettings section of your web.config file. In both cases, the value must be
exactly one character:
<add key="CMSForbiddenUserNameCharactersReplacement" value="-" />
<add key="CMSForbiddenRoleNameCharactersReplacement" value="-" />
If you want to achieve the same functionality as in older versions of Kentico (office\username), forbidden characters replacement can be
turned off completely using the following two keys. This may cause problems when using wildcard URLs with user names in the wildcard part
and is therefore not recommended.
<add key="CMSEnsureSafeUserNames" value="false" />
<add key="CMSEnsureSafeRoleNames" value="false" />
Securing a website section using Windows authentication
When you set up Windows authentication, you can use the authentication only for specific sections of the live website. This leads to the
following scenario:
The live website is accessible anonymously, except for the specified sections that require Windows authentication
Windows authentication is required for access to the Kentico administration interface
The site cannot contain other sections secured using standard Forms authentication
The following example demonstrates how to set Windows authentication for the Products section of the sample Corporate site:
Configuring IIS
1. Locate your web project on the disk (typically c:\Inetpub\wwwroot\<web project>).
2. Create a new directory in your web project's CMS folder, named according to the URL path of the site section that you want to
secure. In this case, the path is /Products, so create a folder named Products.
3. Open Internet Information Services (IIS) Manager.
4. Locate the new Products folder in the tree and select it.
5. Open the Authentication configuration.
Disable Anonymous Authentication for the folder
Make sure that Windows Authentication is enabled
Configuring the web.config file
1. Edit the web.config file of your web project.
2. Set the mode attribute of the <authentication> element in the <system.web> section to Windows:
<authentication mode="Windows">
3. Find the section marked with Windows authentication BEGIN and set the path parameter of the <location> element to the name
of the created directory (Products in the example):
<!-- Windows authentication BEGIN -->
<location path="Products">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
<!-- Windows authentication END -->
4. Save the web.config file.
The authentication is now configured. If you try to access any of the pages placed under the Products section, the system requires Window
s authentication.
If you also want the authentication to be required for the Products main page, you need to use the following workaround:
1. Create a child under the Products page with identical content (you can use the Copy ( ) action).
You may need to adjust the page nesting settings and the configuration of certain web parts to get the page to work
correctly.
2. Select the original Products page and open the Properties -> Navigation tab.
3. Select Redirect to first child in the Menu actions section.
4. Click Save.
Because the new page is located under the Products section, windows authentication is required to access it.
Configuring mixed-mode authentication
Mixed mode authentication enables users to sign in to your website using both Windows Active Directory authentication and standard forms
authentication.
Forms and AD user name conflicts
If an existing forms user has the same user name as a domain user that is logging in, the system signs in the forms user. As a
result, the system cannot create an account for the domain user. You can avoid this behavior by renaming the existing forms user.
Prerequisites
For mixed mode authentication to work:
Windows Authentication must be enabled for the site in IIS. See Enabling Windows authentication in IIS.
The application must be able to access the following attributes of user objects in Active Directory (i.e. the attributes cannot be
protected or confidential):
memberof
userAccountControl
Configuring mixed authentication
To enable mixed authentication mode:
1. Edit your application's web.config file.
2. Add the LDAP connection string of your Active Directory service into the configuration/connectionStrings section:
<connectionStrings>
...
<add name="CMSADConnectionString" connectionString="<LDAP connection
string>" />
</connectionStrings>
Replace the <LDAP connection string> text in the code above with the actual connection string. Enter it according to the
following format:
LDAP://mydomain.example.com/DC=mydomain,DC=example,DC=com
The first part is the full domain. In the second part, the same domain is divided into DC (domain component) units.
3. Modify the membership and roleManager elements under the configuration/system.web section according to the following:
3.
<membership defaultProvider="CMSProvider" userIsOnlineTimeWindow="30">
<providers>
<clear/>
<add name="CMSProvider" type="CMS.MembershipProvider.CMSMembershipProvider"
connectionStringName="CMSConnectionString" enablePasswordRetrieval="false"
enablePasswordReset="true" requiresQuestionAndAnswer="false"
requiresUniqueEmail="true" passwordFormat="Hashed"/>
<add name="CMSADProvider"
type="CMS.MembershipProvider.CMSADMembershipProvider"
connectionStringName="CMSADConnectionString" connectionUsername="username"
connectionPassword="password" />
</providers>
</membership>
<roleManager defaultProvider="CMSRoleProvider" enabled="true"
cacheRolesInCookie="true" cookieName=".ASPROLES" cookieTimeout="30"
cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true"
cookieProtection="All">
<providers>
<clear/>
<add name="CMSRoleProvider" type="CMS.MembershipProvider.CMSRoleProvider"
connectionStringName="CMSConnectionString" applicationName="SampleApplication"
writeExceptionsToEventLog="false"/>
<add name="CMSADRoleProvider"
type="CMS.MembershipProvider.CMSADRoleProvider"
connectionStringName="CMSADConnectionString" connectionUsername="username"
connectionPassword="password" />
</providers>
</roleManager>
Replace the following values:
username - your own active directory user name, including the fully qualified domain name. For example, office.ex
ample.com\johns
password - your active directory password
After this configuration, users can log in using their Active Directory user name (without the domain) and password, or using their standard
Kentico user name and password.
You can also allow users to sign in using their full Active Directory user name (e.g. [email protected]). For this to work, you
have to add the following key to the AppSettings section of your web.config file:
<add key="CMSADDefaultMapUserName" value="userPrincipalName" />
Claims-based authentication
Claims-based authentication is a mechanism which defines how applications acquire identity information about users. When a user tries to
access a restricted section of Kentico, for example the administration interface, the system redirects the user to a logon page of an Identity
provider. The identity provider authenticates the user and issues a security token provided by a Security Token Service (STS). This token
carries information about the authenticated user (the user's identity), which is referred to as claims. Based on the trust of the application to
the identity provider, the application then treats the user as authenticated. The application also authorizes the user to access features and
functionality according to the claims in the token.
This authentication model enables users to authenticate on one domain and gain access to all other domains that trust the same identity
provider (running on-premises or in the cloud). As a result, users do not need to create multiple accounts on different domains and provide
their credentials every time they want to access an application or service.
Lightweight explanation
To use an analogy, imagine you are riding a motorcycle. Police officers stop you and want to know who you are and whether you
are permitted to ride a motorcycle. You can show them a paper with your name and a statement that you are allowed to ride a
motorcycle. Or you can present them a driver's licence, which you have acquired from a government institution.
The police officers may or may not believe a piece of paper (this corresponds to the idea of authenticating users within the
application itself). However, we can assume that they will trust the government (an identity provider) and its assertion that the
name (claim) inscribed on the license (token) is valid and that the card holder really is allowed to ride a motorcycle (another claim).
The police officers do not care how the authentication occurred, because they trust the institution.
Basic glossary
Application - in this context, it is an application which uses claims-based authentication. Also referred to as the Relying party, because the
application relies on security tokens obtained from the identity provider.
Identity provider - a service that authenticates users and issues security tokens containing claims. For example, Active Directory Federation
Services or Microsoft Azure Access Control Service.
Security Token Service - a web service that packages claims into encrypted security tokens. For example, Active Directory Federation
Services (ADFS).
SAML - a standard data format, which is used for encoding security tokens. The format of SAML encoded messages is XML. SAML also
stands for protocols that use claims in SAML format.
Token - a message containing claims. In Kentico, the claims retrieved from the token are only the name and e-mail of the authenticated user.
Windows Identity Foundation (WIF) - a framework used for implementing claims-based authentication mechanisms in applications. It uses
the SAML message format and WS-Federation protocol. The claims-based authentication in Kentico is based on this framework.
For more extensive information, see the Glossary on MSDN.
You can find more information about this type of authentication in Microsoft's Guide to Claims-Based Identity and Access Control.
How claims-based authentication works in Kentico
When users try to access a restricted section of Kentico, they are redirected to a logon page of the identity provider. After logging in, users
can access all applications that rely on the same identity provider (the single sign-on principle).
When users log out of Kentico, they are logged out of all applications that rely on the same identity provider (the single sign-out principle).
Similarly, if the users log out of other applications, which rely on the same identity provider as your Kentico application, they are automatically
logged out of Kentico as well.
Session expiration
When using claims-based authentication, the session is established in the following way:
1.
1.
2.
3.
4.
A user authenticates using the identity provider.
A session is initiated for the user on the identity provider's side.
The user is redirected to the Kentico website.
Another session is initiated in Kentico, based on the forms authentication mechanisms (Kentico creates the authentication cookie).
When the user's session (authentication cookie) expires in Kentico, the session on the identity provider's side may still be active. In such
cases, the user is logged out of Kentico, but not out of other applications that trust the same identity provider.
Therefore, it is recommended to set the same session expiration interval for Kentico and the identity provider (see Web.config file settings)
.
Managing users and permissions
When a user signs into Kentico using claims-based authentication, the system creates a corresponding user in the system with the Is
external flag enabled. If you want to assign permissions to users, you have to assign the permissions to the user profiles created in Kentico.
The claims-based authentication implemented in Kentico handles only the authentication of users (uses only the name and e-mail of users
from the tokens), you have to configure the authorization of users (permissions and roles) in Kentico itself.
Configuring claims-based authentication
To start using claims-based authentication:
1.
2.
3.
4.
Establish an identity provider service (for example Active Directory Federation Services or Access Control Service).
Configure the service so that it accepts your Kentico application as a relying party.
Establish an administrator account in Kentico so that you do not lose access to the administration interface.
Enable and configure claims-based authentication.
Some features are not compatible with claims-based authentication
When you enable claims-based authentication, the system automatically disables the following features:
Screen locking
Password expiration
Password policies
Password reset
Invalid logon attempts
Banning IP addresses
We also do not support mixed authentication mode of claims-based and forms authentication.
Establishing an administrator account
Before you start configuring the claims-based authentication, first create a user account with administrator access. This will allow you to sign
in as an administrator after you enable the claims-based authentication.
1. Open the Users application.
2. Create a new user:
User name: a user name which you will also use to create a user in the identity provider
Full name: your full name
3. Click Save.
4. On the General tab, set the following values:
Privilege level: Global administrator
Is external user: yes
5. Click Save.
After you enable the claims-based authentication, sign in as this user to gain administrator permissions.
Disabling claims-based authentication without administrator access
If you have already enabled claims-based authentication and you do not have access to the Kentico administration interface, add
the CMSEnableWIF key to the web.config file and set it to false. This overwrites the settings in the user interface and disables
claims-based authentication.
<add key="CMSEnableWIF" value="false"/>
To enable the claims-based authentication again, remove the key or set it to true.
Enabling and configuring claims-based authentication
Note: You may need to set up SSL for your site to use certain identity providers.
1. Open the Settings application.
2. Navigate to the Security & Membership -> Authentication -> Claims-based authentication category.
3. Configure all of the settings in the category:
General
Enable WIF authentication
Enables claims-based authentication.
Users need to log in through the identity provider specified by
the settings below (for example Active Directory Federation
Services or Access Control Service). Disables the standard
authentication mechanisms in Kentico.
Identity provider URL
Specify the URL of your identity provider's WS-Federation
passive endpoint.
You can find the value in the provider's configuration interface
or WS-Federation metadata.
Examples:
https://adfs.net/adfs/ls
https://accesscontrolnamespace.accesscontrol.windows.n
et/v2/wsfederation
Security realm
Enter a URI that identifies your website or application. You can
use your website's domain name (and virtual directory if
applicable) in most cases.
The value must be exactly the same as in the relying party co
nfiguration of your identity provider, including letter case, any
trailing slashes and the protocol (http or https).
Allowed audience URIs
URIs of allowed audience for the identity provider, separated
by semicolons. The value must match the corresponding
relying party settings of your identity provider, including letter
case, any trailing slashes and the protocol (http or https).
To allow the authentication for all restricted sections of your
website and the Kentico administration interface, use the base
domain name of the website.
Trusted certificate thumbprint
Enter the thumbprint of the certificate used to secure the
communication between Kentico and the identity provider.
You can typically find the certificate thumbprint in the provider's
Key/Certificate configuration.
Certificate validator
_________________________
Sets the validation mode used for the X.509 certificate specifie
d in the Trusted certificate thumbprint setting.
Chain trust - accepts certificates whose chain of trust
leads to a trusted certification authority. The certificate
must be installed on the server hosting Kentico in the Loc
al Computer -> Trusted People certificate store.
Peer trust - accepts self-issued certificates. The
certificate must be installed on the server hosting Kentico
in the Local Computer -> Personal certificate store.
Peer or chain trust - accepts self-issued certificates, or
certificates with a chain that leads to a trusted certification
authority.
None - no validation of the certificate is done and the
system accepts any certificate with the given thumbprint.
See Working with Certificates.
4. Click Save.
The Kentico application now uses claims-based authentication and no longer has direct control over the user authentication process.
Creating custom login and logout actions in claims-based authentication
You can configure your own actions that the system perform after a user accesses a restricted section of Kentico or after a user tries to log
out. See Handling custom claims-based authentication for an example.
Windows Live ID authentication
Windows Live ID is a single sign-on service provided and maintained by Microsoft. By integrating Live ID into your website, you can allow site
visitors to log in to your website using their Live ID login and password.
How to start using Windows Live ID
1. Register your website at https://account.live.com/developers/applications/create.
To learn how this is done, see Registering your application to Windows Live.
2. Set up Kentico for Live ID authentication
For more details, see Configuring Windows Live ID authentication.
3. Use one of the Live ID web parts on the appropriate page on your site for users to sign in
More information in Web parts available for Windows Live ID authentication.
When a user signs in through a third-party authentication service for the first time, Kentico automatically creates a new user
account for this user. Learn more about managing users that sign in through a third-party authentication service.
How it works
The following diagram shows how the process of Live ID login works.
Registration approval and double opt-in
If your site is configured to require registration approval or double opt-in, first-time users who attempt to log in with their Live ID will
be redirected to the standard logon page without any further information, which may lead to confusion.
This issue can be avoided by creating a Required user data page where users must enter an e-mail address for their account.
When this is done, users will receive a notification e-mail about the status of their account.
Registering your application to Windows Live
To enable Live ID logon for your website, you must register an application at the Windows Live application management site.
1.
1. Sign in to your Microsoft account at https://login.live.com/ or create a new account.
2. Navigate to the application management site https://account.live.com/developers/applications/create.
3. Enter an appropriate Application name that will be used to identify your website in the Windows Live user interface (click Create
application if you already have an application registered and wish to add another one).
4. Select the language of your application.
5. Click I accept.
Windows Live creates a new application with the defined name.
6. Switch to the API Settings tab.
7. Type the fully qualified domain name of your website into the Redirect domain field.
8. Select the appropriate Mobile client app option.
9. Click Save.
Note the Client ID and Client secret values, since they will be required for the settings in Kentico.
You can also specify additional details for your application on the Basic Information tab, such as a logo or links to the terms of service and
privacy policy of your website. The Localization tab may be used to set a different application name for individual languages. These options
affect the logon page to which users will be redirected when they try to authenticate on your website using Live ID.
Configuring Windows Live ID authentication
Live ID authentication settings are located in Settings -> Security & Membership -> Authentication -> Windows LiveID.
Before you start entering values, make sure you have the right site selected using the Site drop-down list.
Enable Windows Live ID authentication - indicates if Windows Live ID authentication should be enabled.
Application ID - identifier of your website. Enter the Client ID that you received when registering your website.
Application secret - secret code that will be used to encrypt messages transferred between your website and the Live ID server.
Enter the Client secret that you received when registering your website.
Assign new users to roles - new users registered via Live ID authentication will be assigned to the roles specified here.
Required user data page - URL of a page containing the Required LiveID user data web part. If entered, new Live ID users who log
into the site will not have their user account created immediately, but will first be redirected to the specified page where they will be
required to enter some additional data (or merge with an existing account) using the web part.
Compatibility with Live ID users created in older versions
Due to changes in the Windows Live ID service, Kentico currently uses a different authentication mode (by default) than versions prior to 6.0,
i.e. 5.5 R2 or older. Each mode generates a different authentication token for the same Live ID. As a result, users created under the original
mode cannot be recognized or authenticated by the new one.
If your system contains Live ID users from an older version (e.g. after performing an upgrade procedure or as a result of a user import), you
may wish to switch back to the original authentication mode in order to preserve the functionality of these user accounts. To do this, add the
CMSUseServerSideLiveIDAuthentication key into the /configuration/appSettings section of your web.config file, as shown below:
<add key="CMSUseServerSideLiveIDAuthentication" value="false" />
Setting its value to false will ensure that backward compatibility is kept. Please note that new users registered via Live ID authentication while
this key is false will only work with the original mode (additionally, Live ID users created under the new mode will no longer be recognized).
Working with both authentication modes at the same time is currently not possible.
Web parts available for Windows Live ID authentication
After you register your site and configure the necessary settings, you can use the following two web parts on your website to allow
authentication via Windows Live ID. The web parts are located under the Membership -> LiveID category in the web part catalog.
Windows LiveID
This web part can be used to let site visitors sign in to your website using their Live ID. It can be placed on any page of your website. The
web part is hidden to authenticated users and will be displayed only to unauthenticated public site visitors. With default settings, the web part
appears as in the following screenshot.
Although the web part works fine with default settings, it has the following properties to fine-tune its behavior:
Sign in text - if entered, a link with the entered text will be used instead of the default sign in image.
Sign out text - if entered, a link with the entered text will be used instead of the default sign out image.
Show sign out - if enabled, the web part will display a sign out link to authenticated users.
Show as button - if enabled, buttons will be used instead of standard text links.
Sign in image - specifies the URL of an image that will be used for the sign in button if the Sign in text property is empty.
Sign out image - specifies the URL of an image that will be used for the sign out button if the Sign out text property is empty.
LiveID required data
In some cases, you may want new users to provide some extra details before their account is created. For example, if your site is configured
to require registration approval or double opt-in, all users need a valid e-mail address to help activate their account.
This can be achieved using the Live ID required data web part. The web part must be placed on the page specified by the Required user
data page setting in Settings -> Security & Membership -> Authentication -> Windows LiveID.
The following properties of the web part are the most important:
Allow forms authentication - if checked, new users will be able to enter a password for their new account so that they can log in the
usual way as well as via LiveID.
Allow existing user - if enabled, users are allowed to join their existing account with their Live ID.
Default target URL - if no return URL is passed, users will be redirected to the URL entered here after merging or creating their
account.
Hide for no LiveID - if checked, the web part will be hidden if the page with it is displayed without being a Live ID logon request (e.g.
when accessed by entering its URL into the browser).
OpenID authentication
OpenID is an open, decentralized standard for authenticating users. It is currently being used by Google, Yahoo!, MySpace, Flickr and many
more. Logon credentials used on all of these sites can be used to log on to your Kentico site.
How to start using OpenID
OpenID is easier to use then the rest of the supported third-party authentication services. For it to work on your site, you don't need to
register your site, all you need to do is take the following steps:
1. Set up Kentico for OpenID authentication - see Settings - OpenID.
2. Use one of the OpenID web parts on any page of your site for users to sign in - see Web parts available for OpenID authentication.
When a user signs in through a third-party authentication service for the first time, Kentico automatically creates a new user
account for this user. Learn more about managing users that sign in through a third-party authentication service.
How OpenID works
The following diagram illustrates how the process of OpenID login works:
Web parts available for OpenID authentication
After configuring the settings, you can use the following two web parts on your website to allow OpenID authentication. The web parts are
located under the Membership category in the web part catalog.
OpenID logon
This web part can be used to let site visitors sign in to your website using their OpenID. It can be placed on any page of your website.
It lets users choose from a number of websites which support OpenID and where they might already have an account. If they choose one
and click Sign In, they will be redirected to the logon page on that site. After a successful logon, they will be redirected back to the Kentico
site. A new account is created on each first logon.
Even though the web part works fine with default settings, it has the following specific properties to fine-tune its behavior:
Providers - Providers used for OpenID login. Each provider must be specified on a single line. Total number of 3 parameters should
be included for each provider:
a. provider display name
b. provider login URL
c. provider icon name placed in ~/CMSWebParts/Membership/OpenID/OpenID_files/.
Each parameter must be separated by '|'. The third parameter is optional and if not supplied then the default OpenID icon will be displayed.
Provided URL must be the login URL of the OpenID provider. If the username (or blog name, user id, etc.) is part of the URL, then use the ##
username## macro to replace the username part of the URL.
Example: myOpenID|http://##username##.myopenid.com/|myopenid.ico
Display textbox - indicates if the OpenID provider textbox should be visible; if disabled then only the sign in button will be visible.
Sign in text - if entered, a link with the entered text will be used instead of the default sign in image.
Sign out text - if entered, a link with the entered text will be used instead of the default sign out image.
Show sign out - if checked, the sign out link will be displayed after the user logs in.
Show as button - if checked, buttons will be used instead of links.
Sign in image - if set, the image will be used as the sign in link.
Sign out image - if set, the image will be used as the sign out link.
Required data for new users - using these settings, you can request additional data from the OpenID provider, which will be added
to the newly created user account. In case that you are using the OpenID required data web part, the requested data will be pre-filled
in the web part.
Notify administrator about new registrations - if enabled, a notification e-mail is sent to the website administrator when a new
registration is performed via the web part.
OpenID required data
In some cases, you may want new users to provide some extra details before their account is created. For example, if your site is configured
to require registration approval or double opt-in, all users need a valid e-mail address to help activate their account.
This can be achieved using the Open ID required data web part. The web part must be placed on the page specified by the Required user
data page value in Settings -> Security & Membership -> Authentication -> OpenID.
The following properties of the web part are the most important:
Allow forms authentication - if checked, new users will be able to enter a password for their new account so that they can log in
the usual way as well as via OpenID.
Allow existing user - if enabled, users are allowed to join their existing account with OpenID.
Default target URL - if no return URL is passed, users will be redirected to the URL entered here after merging or creating the
account.
Hide for no OpenID - if checked, the web part will be hidden if the page with it is displayed without OpenID logon (e.g. when
accessed by entering its URL into the browser).
Facebook authentication
Facebook is one of the most popular social media sites in the world. With its continuously growing number of registered users, it is likely that
visitors who come to your site will already have a Facebook account. With the Facebook Connect authentication feature, you can allow your
site visitors to use their Facebook accounts to register and log in to your site.
Allowing users to log in to your site with their Facebook account
Prerequisites
Before setting up logging in using Facebook, you must create a Facebook App, which allows integrating Facebook features, and
connect the app to Kentico. See Connecting Kentico to social media.
The configuration of Facebook Connect consists of two steps. First, you set up the Facebook App to receive authentication requests. You do
this on the Facebook App editing page at https://developers.facebook.com/apps.
1. Type the domain that your website uses when connecting to Facebook into App Domains.
2.
2. Click Website with Facebook Login.
3. Enter your website's URL into Site URL.
The Facebook Connect logon web part doesn't use this value but Facebook requires you to enter it.
4. Click Save Changes.
Facebook saves your app's settings.
Remember
When your website goes to production, disable the App's Sandbox mode.
Now you must enable Facebook authentication in Kentico.
1. Go to Settings -> Social media -> Facebook.
2. Select your site.
This step is not required but we recommend not to set up Facebook authentication globally.
3. Check the Enable login with Facebook box.
4. Save the settings.
The system stores the settings in the database. To verify the setup is correct and to finish the setup, place the Facebook Connect logon we
b part on a page.
1. Open the page in the Pages application on the Design tab.
2. Add the Facebook Connect logon web part to a zone.
The web part displays the Login button to users who are not logged in. If you click the button, the Facebook Login dialog appears. The
dialog asks you to enter your Facebook credentials and then requests permission to access your personal data. The required permissions
depend on the settings in Social media -> Facebook. For more details about accessing personal information on Facebook, see Loading
user information from Facebook profiles.
You may encounter one of these problems:
The web part renders an error message when in Design mode.
The web part doesn't display anything on the live site.
If you have these problems, double check your App ID and App Secret in settings. See Connecting Kentico to social media.
When a user signs in through a third-party authentication service for the first time, Kentico automatically creates a new account
for the user. Learn more about managing users that sign in through a third-party authentication service.
The system also automatically populates the user's details fields in the system with the details from the user's Facebook profile.
What data the system loads depends on how you set up loading user information from Facebook profiles.
Reference: Facebook integration settings
The following are settings that you can use to adjust the behavior of integrated Facebook features. These settings are located in Settings ->
Social media -> Facebook.
Facebook app
Settings in this category determine which Facebook app to use for authenticating using Facebook. If you want to post to Facebook from
Kentico, follow the procedure in Connecting Kentico to social media and Adding social media accounts.
It is recommended that you select a site before adjusting these settings. Having a Facebook app connected to Kentico on a global
level poses a security risk.
App ID - a numeric ID of your Facebook App. You can find your App ID on the Facebook App editing page.
App Secret - the key used to authenticate Kentico against the Facebook App. You can find your App secret on the Facebook App
editing page.
Login with Facebook
Enable login with Facebook - enable if you want your website users to log in with their Facebook account.
Assign Facebook members to roles - when a new user logs in using Facebook, the system assigns the user to the roles entered
here.
Update users using their Facebook profile - allows you to load information from the user's Facebook profile and store it with the
user's record in Kentico. This feature only works when users log in using their Facebook accounts. See Loading user information
from Facebook profiles.
Never - turns this feature off. User information that has already been downloaded is kept in the system.
When they log in for the first time - downloads the user information only once, when they log in for the first time.
Every time they log in - updates the user information every time they log in. However, this option doesn't update fields in
Kentico that the user has already changed or fields that the system already filled using the information from the Facebook
profile. For example, if an existing user gets married and changes her name on Facebook, her record in Kentico is not
updated because the system downloaded her name from Facebook before.
Mapping of Facebook user profile - determines how Kentico user fields match with Facebook profile fields.
Loading user information from Facebook profiles
The Facebook Connect authentication feature allows you to automatically download user information from their Facebook profiles. Users who
log in using their Facebook accounts don't need to fill out information about themselves. Instead, the system can do that for them
automatically.
This functionality replaces the functionality of the Facebook Connect required data web part, available in Kentico CMS 7.
1. Go to Settings -> Social media -> Facebook.
2. Select an option in Update users using their Facebook profile:
Never - turns this feature off. User information that has already been downloaded is kept in the system.
When they log in for the first time - downloads the user information only once, when they log in for the first time.
Every time they log in - updates the user information every time they log in. However, this option doesn't update fields in
Kentico that the user has already changed or fields that the system already filled using the information from the Facebook
profile. For example, if an existing user gets married and changes her name on Facebook, her record in Kentico is not
updated because the system downloaded her name from Facebook before.
3. Click Edit next to Mapping of Facebook user profile.
The Mapping of Facebook user profile dialog opens.
4. Select how Kentico user fields relate to Facebook user fields and click Save & Close.
5. Save the settings after you define the field mappings.
The system stores your settings. You can test the configuration by placing the Facebook Connect logon web part on a page.
Some fields in a Facebook profile can be accessed only when the user approves it. See the table below for reference.
You don't need to take any action to gain permission to access the restricted fields. The Facebook Connect web parts show a
request for permission to the user automatically. If the user doesn't give their permission, the system doesn't log the user in and
doesn't load any information.
Required permissions for accessing Facebook profile fields
Some fields in a Facebook profile are protected by permissions. The following table shows which Facebook profile fields require permission.
Facebook profile field
Required permission
Full name
none
First name
none
Middle name
none
Last name
none
Gender
none
Biography
user_about_me
Birthday
user_birthday
E-mail
email
Location
user_location
Website
user_website
Is verified
none
Culture
none
Link to profile
none
User name
none
Profile last changed
none
LinkedIn authentication
LinkedIn is a businessrelated social media website. By integrating LinkedIn authentication into your website, you can let users log in to your
website using their LinkedIn user name and password.
How to start using LinkedIn authentication
1. Register your application at https://www.linkedin.com/secure/developer - see Creating your LinkedIn application.
2. Set up Kentico for LinkedIn authentication - see Settings - LinkedIn.
3. Use one of the LinkedIn web parts on any page of your site - see Web parts available for LinkedIn authentication.
When a user signs in through a third-party authentication service for the first time, Kentico automatically creates a new user
account for this user. Learn more about managing users that sign in through a third-party authentication service.
How it works
The following diagram illustrates how the process of LinkeIn authentication works:
Creating your LinkedIn application
To use LinkedIn authentication on your website, you first need to create your LinkedIn application, and generate an API key for it.
1. Sign in to your LinkedIn account at https://www.linkedin.com, or create a new one.
2. Visit https://www.linkedin.com/secure/developer.
3. Click the Add New Application.
4. Fill in at least the required fields (marked with red asterisks) on the Add New Application page.
5. Click Add Application.
LinkedIn redirects you to a confirmation page. On this page, you can find the API Key and Secret Key values. You need to enter these
values in Settings -> Social media -> LinkedIn. See Settings - LinkedIn for more details.
Web parts available for LinkedIn authentication
After registering your application and configuring the required settings, you can add the following web parts on pages of your website. You
can thus enable the site visitors to authenticate using their LinkedIn logon credentials.
LinkedIn logon
This web part can be used to let site visitors sign in to your website using their LinkedIn logon credentials. It can be placed on any page of
your website. The web part is hidden to authenticated users and will be displayed only to unauthenticated public site visitors. With the default
settings, the web part appears as in the following screenshot.
Although it works fine with the default settings, the web part has the following properties to fine-tune its behavior:
Sign in text - if entered, a link with the entered text will be used instead of the default sign in image.
Sign out text - if entered, a link with the entered text will be used instead of the default sign out image.
Show sign out - if enabled, the web part will display a sign out link to authenticated users.
Show as button - if enabled, buttons will be used instead of standard text links.
Sign in image - specifies the URL of an image that will be used for the sign in button if the Sign in text property is empty.
Sign out image - specifies the URL of an image that will be used for the sign out button if the Sign out text property is empty.
Required data for new users - using settings in this section, you can request additional data from the LinkedIn user account, which
will be added to the newly created user account. In case that you are using the LinkedIn required data web part, the requested data
will be pre-filled in the web part.
Notify administrator about new registrations - if enabled, a notification e-mail will be sent to the website administrator when a
new registration is performed via the web part.
LinkedIn required data
In some cases, you may want new users to provide some extra details before their account is created. For example, if your site is configured
to require registration approval or double opt-in, all users need a valid e-mail address to help activate their account.
This can be achieved using the LinkedIn required data web part. The web part must be placed on the page specified by the Required user
data page value in Settings -> Social media -> LinkedIn.
The following properties of the web part are the most important:
Allow forms authentication - if checked, new users will be able to enter a password for their new account so that they can log in
the usual way as well as via their LinkedIn logon credentials.
Allow existing user - if enabled, users are allowed to join their existing accounts with the LinkedIn accounts.
Default target URL - if no return URL is passed, users will be redirected to the URL entered here after merging or creating the
account.
Hide for no LinkedIn - if enabled, the web part will be hidden if the page with it is displayed without LinkedIn logon (e.g. when
accessed by entering its URL into the browser).
Managing users coming through a third-party authentication service
When users sign in through a third-party authentication service for the first time, Kentico automatically creates a new user account for
them. If you edit such an account in the Users application, you can see that the account has some specific settings.
General tab
On the General tab, you can notice that the User name and Full name fields have been automatically filled with a string in the following
format:
User name
Live ID: liveid_<liveidtoken>
OpenID: openid_<openid>
Facebook Connect: facebookid_<facebookuserid>
Full name
Live ID: LiveID - <liveidtoken>
OpenID: OpenID - <openid>
Facebook Connect: Facebook ID - <facebookuserid>
These values can be changed manually without any effects on the functionality.
You can also notice that the Is external user check-box is selected. It indicates that the user account is imported from some external user
database and disables forms authentication for the user, i.e. the user can only log in using the third-party authentication service.
When merging an existing account with third-party authentication using one of the <provider> required user data web parts, the existing
account that you want to merge must not have this option enabled (because forms authentication using the web part would not work).
Settings tab
If you switch to the Settings tab, you can notice the Live ID, Facebook user ID and OpenID fields. This is where the user's ID from the
particular provider is stored.
You can change the values manually if you need to. You just have to make sure that the entered ID is valid. Then, the newly entered ID will
be used when the user logs in. You can also delete the value, in which case no ID will be assigned to the user. If you delete the ID value,
remember to clear the Is external user option on the General tab so that the user can log in using the forms authentication.
Configuring autocomplete for user names
Most web browsers support storing user names that you use to access secured areas of websites. This feature, called Autocomplete, allows
you to conveniently log into frequently used services without the need to type your user name every single time. However, Autocomplete can
pose a security threat when used, e.g., on a public computer. See Autocomplete deactivation for additional security information.
Kentico allows you to set whether you want browsers to offer this feature to users logging in to your website. By default, it is turned on. You
can change this in Settings -> Security & Membership -> Protection -> Enable Autocomplete. This setting influences the following log-on
dialogs:
Logon page to the administration interface
Logon web parts
Shopping cart web part
Sharing user accounts between sites
User accounts can be shared among all sites running on one Kentico installation. This means that if users creates accounts on one site, they
can automatically log on to the other sites running on the same installation using the same credentials.
This behavior can be switched on or off in Settings -> Membership & Security, using the Share user accounts on all sites check-box.
If the check-box is selected, user accounts created on one site will be shared among all the sites running on the installation.
If the check-box is cleared, new accounts will be assigned only to the current site and not the others.
However, registration web parts have the Assign to sites property. Using this property, you may determine which sites the user accounts
created via the web part will be assigned to.
User name prefixes and shared accounts
It is recommended to avoid using shared accounts together with the Use site prefixes for user names option that can also be
enabled in Settings -> Security & Membership.
Prefixes allow the creation of users with names that are not globally unique. If the Share user accounts on all sites setting is
enabled, this may lead to problems with multiple identical user names on a single site.
Configuring single sign-on
Single sign-on is a feature which enables users to authenticate just once and then access multiple websites without the need to enter logon
credentials again for each site. There are two ways how you can achieve this:
Single sign-on on the same main domain
Single sign-on across different domains
Single sign-on API
The sections below describe necessary configuration for each approach.
Single sign-on on the same main domain
This approach lets you configure single sign-on for multiple sites running on the same main domain (e.g. site1.example.com,
site2.example.com, etc.) in the IIS. The sites do not need to be running on Kentico.
Single sign-on on the same main domain is supported in the following scenarios:
Forms Authentication
If you are using Forms authentication and you need to share user identity across applications that run on the same main domain while all of
them use standard ASP.NET 2.0 Forms authentication, you need to ensure that:
1. All applications use the same user database or at least the same user names. You may need to integrate the authentication using a
custom security handler.
2. The web.config file of all applications uses the same authentication cookie name and the path is set to "/":
<authentication mode="Forms">
<forms name=".ASPXFORMSAUTH" path="/" ...="" />
</authentication>
3. The web.config file of all applications uses the same machine key.
The machine key is not present in the web.config by default.
You can generate the key using various machine key generators that can be found on the Internet. Once you have a key
generated, you can add it to the <system.web> section the following way:
<system.web>
...
<machineKey validationKey="ABCD0708...." decryptionKey="DDFF8943...."
validation="SHA1" />
...
</system.web>
4. If your applications run on different sub-domains, such as www.example.com and forums.example.com, you need to set the domain
attribute of the authentication cookie to the main domain so that it's shared across domains:
<forms name=".ASPXFORMSAUTH" path="/" domain=".mywebsite.com" ...="" />
Windows Authentication
If you are using Windows authentication, the user identity is shared within the Windows domain. No additional configuration is required.
Single sign-on across different domains
This approach requires all websites to be running in a single instance of Kentico, while they can use completely different domains.
Single sign-on across completely different domains in the same instance of Kentico can be enabled by selecting the Automatically sign-in
user when site changes check-box in Settings -> Security & Membership.
With this option enabled, no further configuration is necessary - users only need to enter their logon credentials once. After that, they can
switch between different sites running on Kentico using the Site drop-down list, without the need to enter their logon credentials for each
domain.
Single sign-on API
The single sign-on functionality is also achievable on your custom pages using the Kentico API. The following code example shows how to
authenticate a user with a particular username in your code:
string userName = "testuser";
// Authenticates the user with the specified user name
CMS.Membership.AuthenticationHelper.AuthenticateUser(userName, true, false);
The second code example shows how to generate a URL with a user authentication token. The system automatically authenticates users
when they access this URL.
using CMS.Membership;
using CMS.Helpers;
...
string userName = "testuser";
// Gets the user with the specified user name
UserInfo userInfo = UserInfoProvider.GetUserInfo(userName);
// Gets the authentication URL for a specified user and target URL
string url = AuthenticationHelper.GetUserAuthenticationUrl(userInfo,
"/default.aspx");
// Redirects the user to the target URL for authentication
URLHelper.Redirect(url);
Logon troubleshooting
If you cannot log in to the administration interface, please try the following:
Check if your browser is configured to use cookies.
Check if JavaScript is enabled in your browser.
Check if the cookies expiration time in your browser is set to a correct value.
Try to log in using a different browser to see if your problem is browser-based.
Disable your firewall if you are using one.
Disable all plugins and extensions installed in your browser.
If your login credentials are incorrect, try resetting your account's password using the Forgotten password link.
If none of these options help, contact an administrator.
Customizing the format of usernames
If you want to customize how the system displays usernames in the administration interface, modify the GetFormattedUsername method in
~/AppCode/CMS/Functions.cs.
Example
Usernames are displayed in the <full name> (<user name>) (e.g. Abigail Woodwarth (Abi)) format in some parts of the system, for example
when editing pages in the Pages application on the Properties -> General tab.
The following code example shows how to modify the method to get usernames in format <user name> [<full name>] (e.g. Abi [Abigail
Woodwarth]):
using CMS.Membership;
using CMS.Helpers;
...
public static string GetFormattedUserName(string username, string fullname, bool
isLiveSite)
{
username = UserInfoProvider.TrimSitePrefix(username);
if (!String.IsNullOrEmpty(DataHelper.GetNotEmpty(fullname, "").Trim()))
{
return String.Format("{1} [{0}]", fullname, username);
}
else
{
return username;
}
}
Monitoring on-line users
You can monitor users currently connected to the website on the On-line users tab of the Users application. This monitoring can be useful
for various site administration purposes. In addition to providing information, the functionality also provides a way to temporarily kick a
specific user off the website.
Users are identified as on-line when a new session between a client browser and the server is started. The user is considered off-line if the
session expires or when the user logs off. This means that users are still considered on-line for some time when they close their web browser
without signing off.
For more general information about users and site membership, please refer to the Managing users chapter.
On-line users web part
You can use the On-line users web part to display the number of on-line users on your site.
The web part displays a summary defined by the Additional info text property, followed by a list of users that are currently on-line. Users
are displayed based on the transformation specified in the Transformation name property.
On-line users web part properties...
Transformation name
Sets the transformation used to display the online users.
You can use the default CMS.Root.OnLineUsers transformation
, which displays user names separated by spaces.
Path
If you enter an alias path here, only users that are accessing
pages found under the specified path will be displayed.
Select top N
Sets the maximum number of users that can be selected and
displayed.
Additional info text
Sets the text which will be displayed above the list of on-line
users.
You can use the following formatting macros that will be resolved
into the appropriate number:
{0} - number of all connected users
{2} - number of connected registered users
{1} - number of connected anonymous users
No users on-line text
Sets the text that will be displayed if no users are currently
on-line.
Columns
Lists which columns should be loaded from the CMS_User or C
MS_UserSettings tables along with user records. Column
names need to be separated by commas ( , ). Specifying a list
without unnecessary columns may significantly improve
performance.
These columns may be used in the code of the specified
transformation to display data related to the online users.
Enabling monitoring of on-line users
The On-line users module can be enabled in Settings -> Security & Membership by selecting the Monitor on-line users check-box.
If you are running the system on a web farm, also select the Store on-line users in database check-box. This causes information about
on-line users to be saved in the database and also allows the system to provide more detailed information about guests (anonymous users).
The Update on-line users (minutes) property defines how often information about users accessing the site is reloaded. The value is
entered in minutes. When running the system on a web farm, enter the same value which is set for the Remove expired sessions schedule
d task (you can read the value in Scheduled tasks -> edit Remove expired sessions task -> Task interval -> Every: X minute).
The Deny login interval property determines how long users will not be able to log-in after they are kicked. The value is entered in minutes.
Managing on-line users
You can see the list of all users that are currently accessing your website in the Users application on the On-line users tab.
Kicking users
You can kick users off the website by clicking the Kick ( ) action next to one of the listed users. This means that the user is logged out of
the website and will not be able to log back in for the duration specified using the Deny login interval option in Settings -> Security &
Membership.
You can take back kicked users using the Take back (
) action.
When the on-line user data is being stored in the database, you can view all users who are currently kicked on the Kicked users t
ab. Otherwise, kicked users are displayed on the On-line users tab.
If the reason for kicking a user is serious enough, you may want to consider using the Banning IP addresses application to permanently block
the user from accessing the website.
Chatting with on-line users
Clicking the Initiate chat (
window.
) action next to an on-line user allows you to directly communicate with the given person through a chat
To work correctly, support chat must be enabled for the website and the page that the user is currently viewing needs to contain the the Ini
tiated chat web part. See the Using support chat chapter for more information.
UI Personalization
The UI personalization application enables you to provide certain users of the website with a simplified user interface. This is useful for
business users who don't need to see all the applications, tabs, menu items, or parts of UI pages which they don't use. Setting up a
personalized UI can significantly decrease the learning time for users new to the system and makes the system generally easier to use and
understand.
Kentico consists of modules. Modules contain UI elements. A UI element can represent one of the following:
application
tab
menu item
group of controls on a page
For each of the UI elements, you can say whether you want users in a particular role to see the UI element or not. Only users with the Global
administrator privilege level can use UI personalization.
UI personalization vs. Permissions
Do not confuse UI personalization with the permission system in Kentico. Permissions control what users can do, e.g., create or
modify objects, while UI personalization controls what users can see. A user may be able to see a part of the UI but still not have
permissions to perform any action.
Learn more about permissions and UI personalization
Configuring visibility of UI elements
Kentico allows you to show or hide UI elements based on user roles.
1. Open the UI personalization application.
2. On the Administration tab, select a site and a role. Selecting a module is optional.
3. Browse the UI element tree and select or clear the check boxes that represent the parts of the UI that you want to show or hide.
The system automatically saves the settings as you select or clear check boxes in the UI element tree. The system hides the parts of the UI
that have their check box cleared from users in the selected role. If a user tries to access such UI element, the system displays an access
denied message.
If a user is a member of multiple roles, they're allowed to see UI elements from all their roles combined.
Configuring visibility of editor buttons
With Kentico, you can show or hide buttons from the integrated editor toolbar. Each button in the toolbar is represented by a UI element.
1. Open the UI personalization application.
2. On the Editor tab, select a site and a role.
3. Browse the UI element tree and select or clear the check boxes that represent the editor buttons.
The system automatically saves the settings as you select or clear check boxes in the UI element tree. The system hides the buttons (UI
elements) that have their check box cleared from users in the selected role.
If a user is a member of multiple roles, they're allowed to see UI elements from all their roles combined.
Disabling UI personalization
UI personalization is enabled by default. You can disable UI personalization if you want all of your Kentico users to have access to the
complete administration interface, without the ability to customize what different users can see and use.
1.
2.
3.
4.
Open the Settings application.
Search for "UI personalization" or click the Security & Membership category.
Clear the Enable UI personalization check box.
Save the settings.
The system disables UI personalization for the selected site. All users see the complete administration interface when working on the
selected site.
Example - UI personalization
This is an example of using the UI personalization application to restrict users from accessing parts of the user interface. In this example, you
will create a new user role, called Forum moderators, and allow the role to access only the relevant interface.
When a forum moderator logs in to the administration interface, they will see only the Forums application. Inside the application, they will
only have permission to view existing forum groups and manage forums and threads inside the groups.
This example does not show how to configure permissions for the different actions that users can perform with forums. The
example deals only with visibility of user interface.
Preparation
Before diving into the UI configuration, create the objects that you'll be working with.
1.
2.
3.
4.
5.
Open the Forums application and create some forum groups and forums, or use the Corporate sample site.
Open the Roles application and create a new role called Forum moderators.
Open the Users application and create a new user called Alice.
Assign Alice to your site, and then to the Forum moderators role.
Open the Permissions application, select your site and the Forum moderators role, and then select the Read and Modify permissi
ons.
Configuring UI personalization
In this section, you will configure the system to display only relevant parts of the user interface to the user Alice.
1. Open the UI personalization application.
2. In the Site field, select your site. In the Role field, select Forum moderators.
3. In the Module field, select Forums.
4. Select check boxes as shown in the following image (click to enlarge).
Note that you must go up the hierarchy of UI elements and select all parent elements.
Now you can log out of the administration interface and log in as Alice. In, the application list, you can see that Alice can see only the Forums
application.
Browse the Forums application to verify that Alice can see only the parts of the interface that you selected in UI personalization.
Allowing users to change the information they share
You can give users the option of changing the visibility of fields in their user profiles. This way, users can choose which information they
share with others in the system.
Enabling field visibility control for form fields
You can add visibility selectors to any user profile fields:
If you are not familiar with the concept of alternative forms, see Creating alternative forms for more information.
1.
2.
3.
4.
5.
Open the Modules application.
Edit the Membership module.
Open the Classes tab.
Edit the User (cms.user) class.
Switch to the Alternative forms tab.
The alternative forms of the User class represent various types of forms that the system uses to display and edit the data of user accounts.
You can add visibility control for any of the forms.
For example, the following steps describe how to allow users to hide the Full name field in public profiles:
1.
2.
3.
4.
5.
6.
Edit the Edit profile alternative form.
Open the Fields tab.
Select the FullName field in the list.
Enable the Allow user to change field visibility option.
Choose Visibility (radio buttons - horizontal) as the field's Visibility control.
Click Save.
You also need to insert the visibility control into the form's layout:
1.
2.
3.
4.
5.
6.
7.
8.
Switch to the Layout tab of the alternative form editing interface.
If you are editing one of the default alternative forms, click Customize.
Select Use custom form layout.
Click Generate default layout. A default table layout appears in the editor.
Place the cursor into the desired location for the visibility control.
Select Visibility control as the Layout element and the associated form field (for example FullName).
Click Insert.
Click Save when you are done editing the form layout.
Allowing field visibility control in web parts
Forms are displayed on websites by adding web parts onto pages. To allow users to control visibility of form fields, you need to prepare an
appropriate alternative form and configure the properties of the web parts according to the following information:
User public profile
Form name - specifies the full name of the desired alternative form (cms.user.DisplayProfile by default).
Apply visibility settings - check to enable visibility control.
Use visibility settings from form - selects the form whose visibility settings the web part uses (if empty, the form specified by Form
name property is used).
Custom registration form
Alternative form - specify the full name of the desired alternative form (cms.user.RegistrationForm by default).
My account
Form name - specify the full name of the desired alternative form (cms.user.EditProfile by default).
Allow user to edit field visibility - check to enable visibility control.
For example, to add visibility control to the account page on the sample Corporate site:
1.
2.
3.
4.
Open the Pages application.
Select the Special pages/User/My Account page in the content tree.
Open the Design tab and Configure the My account web part.
Make sure that the correct alternative form is assigned in the Form name property (cms.user.EditProfile for the Edit profile form
modified in the example above).
5. Enable the Allow user to edit field visibility property.
6. Click OK.
If you log in on the live site and open the My account page, you can see the visibility controls for fields in the profile editing form.
Sending e-mails
When you want to send e-mails from the Kentico administration interface, you can:
Send an e-mail to a specific e-mail address in the E-mail queue application on the Send e-mail tab.
Send mass e-mail to selected users and roles in the Users application on the Mass e-mail tab.
E-mail queue
Sending e-mails is facilitated by the E-mail queue application. It enables the system to send out, for example, newsletter issues to
subscribers without the risk of losing any of the e-mails due to errors.
New e-mails registered in the queue are sent out automatically in regular intervals by the Send queued e-mails scheduled task. If an e-mail
is not delivered successfully, it remains in the queue so that you can delete or resend it manually later.
During the mailout, emails in the queue are distributed to the SMTP servers defined in the system. See the Configuring SMTP
servers topic to learn how you can register and configure SMTP servers in Kentico.
Successfully sent e-mails are displayed on the Sent e-mails tab for the number of days specified by the Archive e-mails (days) option in Se
ttings -> System -> E-mails.
You can configure the settings related to e-mails in Settings -> System -> E-mails in the E-mail processing section. See Settings - E-mails
.
Displaying personalized content
Kentico allows you to personalize the displayed content based on the current user.
Checking the permissions of the current user allows only basic personalization. Use Content personalization to achieve more
advanced personalization scenarios according to completely custom conditions.
Personalization in short
1. If you want to customize content displayed to the users, you need to grant or deny the READ permission to these users
and turn on the Check permissions attribute of the appropriate web parts.
2. When the user is not authenticated, the system uses a special user Public anonymous User (public).
Example: Personalizing the Products menu
In this example, you will learn how to display the Products section only to members of the Customers and Partners roles and how to
display the Smartphones category only to the members of the Partners role.
Creating sample objects
First create object you will work with in this example:
1. Open the Roles application.
2. Select the Corporate Site from the Sites dropdown list and create new roles Customers and Partners.
3. Open the Users application and and create a new user Customer1 with the following values:
User name: Customer1
Full name: Testing Customer
Enabled: yes (checked)
Privilege level: None
4. Assign the user to the Corporate Site and to the Customers role.
5. Create another user Partner1 with the following values:
User name: Partner1
Full name: Testing Partner
Enabled: yes (checked)
Privilege level: None
6. Assign the user to the Corporate Site and to the Partners role.
Assigning page-level permissions
Assign page-level permissions to the created roles:
1. Navigate to Settings -> Security & Membership and set Check page permissions to All pages.
This ensures that the security settings assigned in the following steps will be checked for all pages on the website.
2.
3.
4.
5.
Open the Pages application and select the root of the content tree.
Switch to the Properties -> Security tab.
Add the Public anonymous user (public) user and Customers and Partners roles to the list.
Grant the Read permissions to the user and roles.
Please note that you must click Save after assigning permissions to each user or role.
Hiding selected child pages
Now hide the product categories from public users:
1. In the content tree, navigate to /Products/Smartphones and switch to the Properties -> Security tab.
The permissions that you configured for the root of the content tree are inherited by this page.
2.
3.
4.
5.
6.
Click the Change permission inheritance link to break the inheritance.
In the following dialog, choose Break inheritance and copy parent permissions.
Select the Public Anonymous User (public) and deny the Read permission.
Repeat the previous steps for the Laptops and Tablets page.
Also deny the Smartphones page for the Customers role.
Configuring web parts to check permissions
The permissions are not checked by web parts by default, so we need to configure the web parts so that they check the Read permission of
the current user.
1. Choose the root in the content tree and switch to the Design tab.
2. Configure the Top list menu (CSS list menu) web part and select its Check permissions check-box in the System settings. Click
OK.
3. Repeat the same for the CSS list menu and Featured products web parts on the /Products page.
Verifying the result
Sign out. If you mouse-over the Products menu item as a public user, you will see that the sub-categories representing the restricted
sections are no longer displayed.
Sign in as user Customer1 (using the miniform at the top right of the page). Navigate to Products via the main menu. As you can see, the S
martphones section and Smartphone products are not displayed to this user.
Now sign out and sign in again as user Partner1. You will see all categories and products.
You have learned how to personalize the content displayed to users based on their permissions.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement