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
|