Transparent Security and Permissions

Business problem
We hate to log in. Creating and remembering secure passwords is hard enough. Especially for clinicians, logging into each application — numerous times every day, often on different computers — is an annoyance and time-waster. This is why people love Single Sign-on! Is there a way to solve this problem for an intranet without a lot of expense and effort?

NTLM to the rescue
Ideally, security to be transparent (invisible) to the user. It should just happen. They should see only what they are authorized to see, and in most cases without any special action on their part. Since virtually all of our desktop computers use a Microsoft operating system, we could leverage a Microsoft authentication protocol: NTLM.

Anytime someone goes to the intranet, the first thing we do is identify the current user via NTLM. Once we know the network login for the current user, we can look it up in our database of current users (System Access - Who has what?), and determine exactly what that person should see in the current context.

On the home page, the only customization is "My Links" (Personalization). However, customization is much more extensive throughout the rest of the site. There are two ways in which security is managed on the site:

• Each application has roles that are specific to that application, and each user for that application is assigned to a role. Their role defines exactly what they can see and do within the application.
• Document access (including reports) is managed with security profiles, as part of the Backbone database described in Driving with Databases.

Application security
In applications built for the intranet, transparent security defines and controls the functionality available for each user. At the simplest level, the user will see a different application menu. In the example shown below, someone with permission to use PPD tracking will only see the "PPD Testing" tab. Someone with permission to use Fit Testing tracking will only see the "Fit Testing" tab. Someone with both permissions will see both tabs, and someone with admin permissions will see the System Maintenance tab.

Within each application, the current user's role is also used to define what they can see and do. The basic rule of thumb is that no one should ever be offered a link for something they aren't authorized to use.

Document access
Document access is managed with security profiles, as discussed in Reporting on Full Auto. The security profile offers tremendous flexibility for managing permissions, as shown below.

• Permissions can be granted to everyone in a department or only to the managers in that department.
• E-mail distribution lists offer a very powerful way to manage permissions, where the department can control permissions indirectly by managing the members of a distribution group (which they already manage for other reasons).
• Position numbers allow permissions to remain constant, even when there is turnover in a position.
• If all else fails, individuals can be granted permissions. (This is our least favorite method, since it requires hands-on maintenance by web development staff whenever the list changes.)
• Any combination of types of permissions can be used.

Using the security profiles for each document, we display only the links to documents for which the current user has permissions. This keeps security transparent to the user, and makes their experience with the intranet smooth and efficient.

Lessons learned

• An intranet can be built to provide transparent security for the user.
• The investment of effort in building a solid data foundation about users and departments really pays off when managing permissions.
• People love a personalized experience that just happens.

Posted 2 April 2008