By Cathy Dew
Authentication with Kentico
When you need to provide a login, there are several options you can use. Authentication with Kentico can be internal to the CMS or external. With either pathway, everyone accessing Kentico needs to have a Kentico profile in order to receive content personalization and other services from Kentico. (Even Anonymous browsing, if enabled, has a base profile. Cookies are used to differentiate between anonymous users. In the event they register with the site and create a profile, their site interaction history is retained.)
Therefore, with the 3rd Party authentication, Kentico needs to be able to communicate with the 3rd Party system and harvest information about the user to build the local profile. Out of the box, Kentico can work with a limited number of 3rd Party Authentication methods and the primary one is Active Directory. Custom authentication providers can be developed to extend Kentico’s authentication support.
Kentico Controlled: Forms Based Login
The basic Kentico authentication control is forms-based login. This process is 100% controlled by Kentico and requires a login by the user for each session. Session length can be extended by settings in Kentico and by the user via the “remember me” feature. Even with these features enabled, the sessions need reauthentication at regular intervals. Automated pass-thru authentication is not supported with this setup since there is no linkage with any other authentication provider.
Whether IIS has authentication disabled (e.g. setup for anonymous browsing) or not, IIS’s authentication process does not affect the Kentico Forms based authentication. However, having IIS’s authentication disabled is the recommended setup for public Internet sites since the only authentication needed might be for Registered Members versus anonymous visitors.
Once the user has been authenticated, the internal Kentico Security Roles are used to allow/deny access to internal Kentico Services.
Active Directory Authentication
Kentico can off load the user authentication to Active Directory. (Again, Kentico still needs a local profile for every visitor.) In this scenario, IIS is enabled to intercept traffic and verify that the requesting user has authenticated with the local Active Directory service.
Once the authentication is completed, the visitor’s AD Account is passed on to Kentico to identify the local profile needed by Kentico to communicate properly with the visitor.
If the AD Account does not exist locally, Kentico needs to communicate with Active Directory in order to build a profile for the new visitor. (Note: That for all Active Directory accounts, no passwords are stored with the local profile and password management with the profile is disabled.) This communication pathway is built into Kentico for Activate Directory, and can be replaced with custom code to communicate with 3rd Party Authentication providers.
The biggest benefit of using AD Authentication with Kentico is for Intranets, where the visitor has already authenticated with the local network. The authenticated intranet visitor will receive a “pass-thru” from IIS on the authentication prompt and will be sent directly to the Kentico services.
Once the user has been authenticated, the internal Kentico Security Roles are used to allow/deny access to internal Kentico Services. The internal Kentico Security permissions can be mapped to existing AD Groups, which can be configured to be imported from AD during the profile build process for new users. Without these mappings, the user will only receive basic services from Kentico until the proper security permissions are enabled by the Kentico Admin. (e.g., editing permissions.)
Hybrid – Both Forms and AD Authentication
Kentico can be configured to utilize both forms-based and Active Directory authentication at the same time. This can be helpful when not every visitor has an Active Directory account on the internal network. For this scenario to work, IIS cannot be part of the authentication pathway. All the authentication control must reside within Kentico or the non-AD users will never get to the hosted website.
Like forms-based login, the session length can be controlled, but all users will be required to login at regular intervals – both locally authenticated and AD authenticated accounts. “Pass-thru” authentication is not supported with the scenario.
During the authentication process, Kentico looks for an existing local profile. If one exists, the local authentication method is tried first. If that is successful, the user is allowed in. If that fails, Active Directory is checked for authentication and pass/fail proceeds as normal.
If the local profile doesn’t exist, Kentico will attempt authentication with Active Directory first and if successful will build a local profile. If the user does not exist within AD, Kentico will direct the user to build a local profile. Therefore, if a local account exists with the same name as an AD account name, the local account must be renamed in order for the AD Account to be used successfully with AD Authentication.
Note: That for all Active Directory accounts, no passwords are stored with the local profile and password management within the local profile is disabled.
Azure AD Authentication
Azure Active Directory Authentication is not supported directly out of the box by Kentico, like internal Active Directory services are. However, Azure AD does support claims based authentication which is a supported authentication pathway with Kentico.
Using Azure AD/Claims base authentication is similar to regular AD Authentication, where Kentico off-loads the authentication to a different service. In this case, IIS is not part of the authentication process, and Kentico needs to know a set of required configuration settings for proper validation and processing of the authentication claim.
Additionally, when authentication is needed, Kentico routes the visitor the Claims Provider (a predefined authentication page), which handles the authentication and returns the user back to Kentico with a valid claim “ticket.”
There are two keys with Azure AD and the claims based authentication that are critical for controlling access to Kentico services after authentication. One, Kentico will need to import the User’s AD roles, or have a default set of roles assigned for management of the internal Kentico security. If importing of the AD roles is utilized, these roles must be mapped to security permissions in order to allow more than the basic access to the Kentico services.
Because of the claims authentication setup, you cannot run Kentico in “mix mode” authentication. All authentication must be routed through the Claims provider.
Note: Azure AD can be integrated with the company’s internal AD services, and still support Azure AD only accounts. This method could be utilized to support a mix of internal and external user access to Kentico.
As you can see, options for Kentico Authentication can be quite simple or quite complex, depending on the nature of your intranet and what type of site security and content personalization you wish to provide. If you need help learning the basics of Kentico authentication or configuring your Kentico web site for more effective content personalization, 2Plus2 can help.
Go online to schedule a free consultation with our team or call 510-652-7700 today.