Configuring Intranet Security Within Ektron’s CMS, Part 2

By Ken McAndrew, Senior Technology Consultant View Comments

Configuring Intranet Security Within Ektron’s CMS, Part 2

In part one, we discussed how to determine how best to set up users in Ektron™. In this part, we’ll be diving a little deeper into intranet authentication methodologies.

How to Authenticate Intranet Users with LDAP

For one of our recent intranet clients, we were required to use LDAP for authenticating users for both front- and back-end access. LDAP had to be connected to the CMS author accounts, and we also had to account for non-LDAP users needing front-end access only. This would cause conflict between CMS author usernames and membership account usernames. Also, because membership users are not linkable to LDAP, their network passwords would not be maintainable in Ektron.

Authenticate Intranet Users with LDAPThe first thing we did was to connect the CMS authors to LDAP, which is easily done through the workarea. We then had to establish a strategy for handling all front-end (membership) users, allowing for both LDAP users and straight Ektron membership users to log in. Here’s what we came up with.

Step 1: Custom Authentication with LDAP, Ektron and ASP.NET
What we came up with for LDAP users is using a custom LDAP authentication system for the end users to go through, checking them against the LDAP server separate from Ektron’s check, and then connecting them to an Ektron membership account.

First, we created a standard ASP.NET login page with the Login control, which gave us the username/password fields as well as a “remember me” checkbox to allow users to maintain their authentication. When the user clicks the Login button, the OnAuthenticate function is triggered, and one of two paths is taken:

  • Ektron membership is checked directly first to see if the account matches up. This avoids the LDAP processing if it’s not needed, as well as to ensure the first authentication point is for lesser permissions.
  • If the user is not found in Ektron membership directly, a custom LDAP authentication call is made. If the user passes that check, they are considered authenticated and they must then be logged into Ektron.

Step 2: Using Pass-Through Authentication To Create User Accounts
We now have a user that we know should be allowed into the intranet, but if this is their first visit, they have no account in Ektron. We could easily create one, of course, but two things prevent this from being a simple exercise. First, the username must be unique, and our user could potentially be a CMS author as well, so we cannot just use their entered username directly. Second, the user entered their network password, which while correct today will likely be changed someday due to network security requirements. That change will be reflected in LDAP, but not Ektron.

The solution is to use a pass-through authentication methodology, creating a presence in the membership world that can be recognized via code. We do this by adapting the username and creating a standardized password to use. In this case, we added “mbr” to the end of each username as it came in, to denote a network-based authentication that is now a membership account. For the password, we also used the username and added complex characters around it to create a common, yet hard-to-guess, password algorithm.

At this point, the user experience becomes identical no matter which way the user entered the system. LDAP-authenticated users do come with other information from the network, like name and email address, which can be used to update the Ektron record and maintain synchronicity between the systems. The membership record can also be used at this point to store other information in custom properties, whether other data for tracking user activity or storing data from other third-party applications. By encapsulating all of the information in the user record, not only does the developer have a single-source location for information, but that information is also searchable in Ektron using the standard APIs.

Lessons Learned

Continuing on the previous discussion on mixed-mode authentication, we can take membership users in Ektron and use the pass-through concept to invent a password algorithm. Then, use the authentication steps noted to handle network logins with a custom check as well as manually-created membership users.

Finally, let's look at maintaining the various login states involved with ASP.NET and Ektron.


Maintaining the Logged-In State Over Extended Periods

Given that you have more than just basic ASP.NET involved, maintaining the appropriate states can be a bit of a juggling act.

As far as ASP.NET is concerned, maintaining the login state comes down to using the Login control’s “remember me” checkbox. The logic behind what to do when this is checked is up to the developer, but typically an authentication ticket is created with an extended timeframe (say a month), so when the user returns to the site, they will continue on without having to enter their login credentials. (That being said, don’t dismiss the KISS method and overlook just using FormsAuthentication.RedirectFromLoginPage!) This is fine for ASP.NET, and using the stored username and Ektron APIs you can retrieve information about the logged-in user to populate a session variable about them.

ASP.NET for EktronWhat must be accounted for is the Ektron login. Much like a standard forms authentication ticket (when “remember me” is not checked on), the login period lasts for as long as the user session does, which by default is usually 20 minutes with a sliding expiration. If this time period expires, the user is logged out of Ektron, and if you were using their membership login to control and check permissions, for example, you will have to reauthenticate them without user intervention. And of course, you cannot retrieve their password and you would not store it in any exposed data structure like cookies.

For this purpose, we actually turned to the legacy Ektron API, which has a function to allow for a user to be authenticated without their password being required. To secure this from spammers and spoofers, the username comes from the User.Identity.Name property, which is populated by the forms authentication ticket, our key to knowing this user is allowed.

Lessons Learned

Setting up both ASP.NET forms authentication and Ektron authentication properly is important, especially if you want to maintain a user’s login for an extended period, which many intranet users will likely want to do. Maintain the extended time with forms authentication, then use that information to ensure Ektron authentication is handled seamlessly.

As always, good requirements gathering at the beginning of the project is the first key to a successful implementation. Understanding what the client can bring to the table for authentication as well as the types of users they’ll want to let into the system (and where), will guide you into the appropriate setup for your intranet.


Posted in: IT Security, Web Design & Development, Content Management, Intranets