Configuration can be done in multiple locations in Optimizely Content Management System (CMS), depending on the type of settings. Typical examples are configuration files such as _appSettings.json_, environment variables, content types, and templates in code and site configuration in the database.
We assume here that you have installed an empty CMS site and added a page type, as described in [Create a starter project](🔗).
## Configure
An ASP.NET Core web application can have several different sources for configuration data such as an _appSettings.json_ configuration file or environment variables. See [Configure](🔗) for more details about default configuration settings when you install CMS.
## Content types
Content types and templates are typically defined in code and stored in the database. Each content type consists of a number of properties, such as Title (`MetaTitle`) and Main body (`MainBody`). Available content types are displayed in admin view, and you can modify their properties from here. For example, administrators can change the tab under which a property is displayed, or the order in which properties are displayed for a content type.
Note
You can create content types from the admin view, but creating page types from code makes pages more strongly typed.
During website **initialization**, the **synchronization** engine in CMS scans and validates available content types and properties created in code, or from the CMS admin view. See [Content model and views](🔗).
## Database configuration
An important configuration setting is the connection string, which must contain the path to your server and database, and SQL login and password. Make sure your connection string also contains `MultipleActiveRecordSet=true`. It is enabled by default when you install a website from a scratch, but not if you are generating a connection string from the server explorer in Visual Studio. By default, CMS uses the connection string named `EPiServerDB_._DataAccessOptions` to configure a different named connection string.
You configure the site URL and start page in the admin view and store it in the database. This makes deployment easier and you can add and remove sites dynamically without having to restart the application.
## Configure the start page
When you build a website from scratch, you will first create a set of content types and content items. To browse to your site, define a site URL and start page, which acts as a default URL to the site when links are generated.
The start page is often a specific page type with unique properties, but you can configure any page type as a start page in the CMS admin view under **Config **>** Manage Websites**, by selecting a page in the page tree. The `SiteUrl`, `StartPage`, and host mapping settings are stored in the database.
See [Create a starter project](🔗) and [Set up multiple sites](🔗).
## Authenticate and authorize
The default authentication in CMS is based on the ASP.NET Core built-in framework for authentication and authorization. When implementing an CMS solution, you can choose which authentication to use.
### Configure authentication
#### ASP.NET Core Identity authentication
You can configure your website to use **ASP.NET Core Identity** as authentication for managing users and roles. There is package _EPiServer.Cms.UI.AspNetIdentity_ that is a CMS specific implementation based on ASP NET Core Identity. See [AspNetIdentity](🔗).
Note
The [Optimizely sample site](🔗) (Alloy templates) uses ASP.NET Core Identity for authentication.
#### Azure AD integration
If you are developing a website for the cloud, you may want to use **Azure Active Directory (Azure AD)** for directory and identity management. CMS provides the possibility to use OpenID Connect to integrate with Azure AD. See [Integrate Azure AD using OpenID Connect](🔗).
### Configure access rights
CMS uses an extension of the **Role** concept called `VirtualRoles`. These are roles that are not original role claims for the user but rather dynamically added claims where the membership criteria is determined at runtime. Virtual roles are controlled by `VirtualRoleOptions`.
These virtual roles are delivered with Optimizely:
**Administrators**
**Everyone** – Provides visitor access to front-end
**Authenticated**
**Anonymous**
**CmsAdmins** – Mapped role, maps to WebAdmins, Administrators
**CmsEditors** – Mapped role, maps to WebEditors
**Creator**
**SearchAdmins** – Mapped role, maps to WebAdmins, Administrators
You can also create your own virtual roles in code and register them through `VirtualRoleOptions`. See [Virtual roles](🔗).
**WebAdmins **and **WebEditors **are non-virtual Optimizely-specific groups. They provide access to the CMS admin and edit views_._ The groups are predefined in Optimizely, but they need to be added from the admin view to become available for usage, if you manage users in the CMS admin view, using for example _EPiServer.Cms.UI.AspNetIdentity_ package.
When you have configured your authentication, and added users to appropriate groups, you need to define _what_ users can do _where_ in the content structure. See _Access rights_ in the Optimizely User Guide.
## Logging
When you set up a website, configure logging, such as for troubleshooting. You can use different logging tools. Logging within CMS is based on the logging framework within ASP.NET Core so configuring logging for a CMS application is the same as for other ASP.NET Core applications. See [Logging](🔗).