Security Policy Annual Acknowledgement

Over the past few years, I've encountered a number of customers who were struggling with a compliance mandate requiring employees to annually acknowledge that they have read the organization's security policy, code of conduct, or other important policy. Coreblox recently outlined how you can enforce that annual acceptance using a Web Access Management solution. If you're employees regularly need to access web resources, this is a good way to force their attention as-needed. How have you solved the problem?

Identity in the Cloud

Over the past year, there have been a number of identity management solutions popping up that aim to help companies deal with identities in Software-as-a-Service (SaaS) / Cloud applications. Here's a list of the solutions that I've encountered:

Cloud Identity - SaaS Identity and Access Management solution. Provides provisioning, workflow, audit reporting, and SSO. Leverages existing enterprise credentials. [more info]

Conformity - SaaS Identity and Access Management solution. Provides provisioning, workflow, and audit reporting for select cloud applications. Leverages Active Directory (or other on-premise repository) accounts as the source. [more info]

Identropy IC2 - Identity Management solution for SaaS applications. Leverages existing Identity infrastructure and work flow to provision accounts to cloud applications via the IC2 SPML gateway. [more info]

MyOneLogin - SaaS Identity and Access Management solution. Provides SSO and Secure Logon to cloud applications and web sites. Enables Account Management for select SaaS applications. Tracks SaaS application usage across apps from a single location. [more info]

Nordic Edge Opacus - SaaS Identity and Access Management solution. Provides Secure Logon to cloud applications. Synchronizes accounts from on-premise repository to cloud systems. Enables delegated user administration for cloud applications. [more info]

PingConnect - SaaS SSO solution for Salesforce CRM, Google Apps, and 60+ other SaaS applications. Leverages existing enterprise credentials, Google Apps Logon ID, or Salesforce credentials. [more info]

SecurAct - SaaS Identity and Access Management solution. Provides provisioning, work flow, SSO, and audit reporting for both local and cloud applications. Leverages Active Directory accounts as the source. [more info]

Symplified - SaaS Identity and Access Management solution. Provides provisioning, audit reporting, authentication, and SSO across local and cloud apps. Leverages existing enterprise credentials. Can also prevent side-door access. [more info]

NOTE TO VENDORS - please feel free to reach out if my description above is incorrect. I'm happy to make corrections where appropriate or provide additional differentiators. I also encourage comments that help identify how products stand apart from the others by end-users or vendors.

[Updated Aug 04, 2009]
[Updated Jul 29, 2009]

Single Sign-On; Multiple Confusion Points

The Identity Management landscape is littered with various products. It's already difficult to understand IdM product categories and how they work together. But it's made worse because various vendors implement their technologies differently. That's not necessarily a bad thing in itself, but customers are confused.

The problem is analogous to that of Microsoft's Internet Information Services (IIS). IIS is both a web server and an application server. So, in a chart, it would line up against the Apache and Sun web servers. But, it would also line up against Tomcat, WebSphere and WebLogic in the application server category. This same phenomenon occurs often with Identity Management products. Some products have single capability and others have multiple. Some companies offer a single product and others offer multiple. So, it becomes very difficult to compare apples to apples.

In protest of all this confusion, I continue to attempt to simplify the IdM landscape. A while ago, I tried to create an identity services architecture map that could be used as a visual aide when communicating about where products fit in to an overall IdM architecture. While not 100% satisfied with it, I do think it serves the basic purpose.

Lately though, I've been re-thinking Web SSO and Enterprise SSO. What I've found is that people tend to group them together. However, at their core these are two very different technologies.

Web SSO is about securing access. It's generally implemented as a web server filter that intercepts access requests and makes decisions about whether to grant or deny access to the requested resource for the requesting party. Strong Web SSO products typically include a mechanism to manage web resources and user access permissions.

ESSO, on the other hand, is about enabling a better end-user experience. Typically, ESSO is implemented as a desktop client that manages user credentials on behalf of a single user. There are some ESSO implementations that act as an access proxy somewhere on the network, but this functionality isn't core to ESSO capabilities. The main driver of ESSO tends to be end-user experience and not security. In fact, I often hear the ESSO question from customers posed something like this:

We want ESSO to make users' lives easier, but we're afraid of the security implications. If a password is compromised, an attacker would now have access to the entire kingdom.

My answer is that this problem isn't with ESSO -- it's a problem with the authentication mechanism. Two-factor authentication would prevent an attacker from accessing anything with just a password compromise. And ESSO enables strong password policies on applications throughout the enterprise, which means passwords are much less likely to become compromised in the first place. If users don't ever need to remember or manually enter their passwords into systems, you could reasonably require 10 character passwords which require upper, lower, numeric and special characters. And you can force a password change every 30 days (this can also be transparent to the end-user). This creates a password that's much more difficult to guess or brute-force attack than a typical user's 6- or 8- digit alpha-numeric password.

So, I guess I'm thinking that I might move ESSO out of the Access Services layer and into the User Services layer. It's really not doing any enforcement and it's not managing policies or access rights. It's really only fostering a better user experience in a secure way.

And let's just all start ignoring the term Reduced SSO. This term just acknowledges that not every enterprise system can participate in an SSO implementation. Is this really necessary to distinguish? We're looking to achieve single sign on for participating applications. Let's not confuse customers further with an additional term that only points out what should already be obvious. If we can make this all simpler, I think we'll see higher adoption (and success) rates and happier customers.

Password Solutions

One of the primary business drivers for Identity Management has always been password management. System users don't want to remember multiple passwords -- especially if the systems require password changes on different cycles and have varying policies for password length and structure. The frustration is more than understandable. And we've all seen the reports that state the cost associated to that frustration. Password-related Help Desk calls cost $x per call and x number of calls each year per each thousand users equals the enormous cost of managing passwords. I didn't even mention the security implications of having too many passwords.

What we haven't heard often is that there are a number of possible solutions to this problem. We may have heard each of these solutions individually, but usually from a single perspective. I believe that technology infrastructures are complex and dynamic. They're not one-size-fits-all. Every enterprise has a unique environment and somebody needs to (or at least ought to) put forth some actual thought about how to best approach any given environment. So, with that, here are four approaches to the problem of passwords. They are not mutually exclusive and depending on the size of an organization, it might make sense to look at more than one of these approaches.

1. Password Management (Reduced Sign On)
These solutions synchronize passwords across multiple systems. They enforce strong passwords that adhere to the policies of each of the connected systems and remember password histories so that people can't repeatedly use the same password. One of the nicest features of password management solutions is that they allow end-users to recover lost or forgotten passwords through some type of self-service mechanism. This cuts the helpdesk costs and leads to real ROI. System users are left with multiple user accounts which have a common password.

2. Centralized Authentication Infrastructure (Single Sign On)
These are the typical SSO solutions that leverage some type of access policy server. The SSO system identifies a user and determines whether or not to grant access to the requested resource. SSO vendors typically leverage LDAP to authenticate users against an enterprise LDAP directory. If an organization prefers to manage data in a relational database, the SSO system can send LDAP requests to a Virtual Directory which would then pass the request to a back-end database (or any other set of data stores). SSO solutions centralize authentication to a single account and enable management of permissions to access enterprise resources. On the back-end, these systems require access to an authoritative identity data store and therefore usually require either some form of identity data synchronization or a virtual directory implementation (as previously mentioned). One example of multiple back-end data sources is leveraging Active Directory for employees and an Oracle database for non-employees.

3. Single Authentication Source
In this scenario, an organization would forgo the expense and infrastructure of implementing an SSO environment, but would implement a single authentication source with varying authentication mechanisms and logic for each application. If there are a limited number of applications, the value of a true SSO implementation may not be fully realizable. Each application in this scenario would verify credentials against a Directory or Virtual Directory server. Just like in the SSO scenario, a Virtual Directory would enable lookups to one or more data sources on the back-end. This allows the organization to leverage a single set of credentials for authentication to multiple applications.

4. Enterprise Single Sign On (ESSO)
ESSO solutions reside on an enterprise network and manage user access to various resources. The user experience is pleasant because there is only a single point of authentication. Each application maintains its own set of credentials, but the ESSO solution maps user accounts for each system and performs the authentication process on behalf of the end user. Some things to consider are application password change policies and how access from external locations would be handled. The user still has multiple system accounts each with its own password, but the logon process is made transparent by the ESSO solution.

Federation solutions offer another way to handle authentication across multiple systems and may be able to provide an additional solution to password challenges. However, federation solutions are typically implemented for authentication across security domains whereas passwords are typically managed within a given security domain. User-centric identity solutions are another way to approach access across multiple security domains. Ultimately, organizations should consider the alternatives and implement solutions that will provide value within their own given environment based on their own specific requirements.

Internal users, AD password synch and Virtual Directory

At MaXware, we have a product that hooks into Active Directory to capture password changes. Once the change is captured, we can synch passwords downstream to connected data stores (directory, SQL DB, etc.). Like other implementations of this type of solution, ours requires having a component installed on each AD DC to identify and pick up the password changes. Although it's not generally preferable to install software on Domain Controllers, it serves a specific purpose in this case and AD administrators have been known to give-in to their business counterparts to make it happen.

The underlying need is probably obvious - multiple apps each have associated passwords. And more passwords means more to remember, less likelihood of utilizing strong passwords and higher likelihood of non-secure password practices (written notes, etc.).

As we all know, another way to solve the problem is to implement Single Sign On or Reduced Sign On solutions that enable applications to leverage a common authentication mechanism (or at least a common auth store). These solutions are complicated to implement and costly. And you usually need to find a way to synch with AD anyway since corporate users typically change their passwords using Ctrl-Alt-Delete.

ADAM directories serve as one possible solution for some of this pain. You can implement an ADAM directory to serve as the application identity store or even as a central authentication store and pass authentication request credentials through to Active Directory. This means a single password stored in Active Directory that can serve the network environment as well as the apps that leverage ADAM as the Auth Store. If you centralize the store, you don't really NEED to centralize the authentication mechanism, which might be nice in some cases. In environments with a large amount of custom-developed applications, a centralized mechanism would probably provide significant value even if there's already a common authentication store.

Wouldn't it be nice, though, if you could do the same thing without needing to implement ADAM directories and without storing the AD password in two locations? What if a Virtual Directory could pass authentication requests to Active Directory the way that ADAM does? You could potentially use the Virtual Directory to expose only specific attributes to given applications, reduce the overhead of an additional directory infrastructure, eliminate the need to store the AD password in multiple locations (and the need to install agents on AD DCs) and still achieve authentication to multiple systems using a single set of credentials.

[UPDATED Mar. 8, 2006] - Shorty after posting this, I was informed that MaXware Virtual Directory (along with its competition) does, in fact, support passthrough authentication to AD. I guess I thought ADAM was doing more than a simple bind, which is not the case -- I think I learned that years ago and forgot it again. So, I removed the question on technical feasibility. I guess the question becomes why aren't more people talking about this? It seems like it would be an incredibly useful application of our product.

[UPDATED Mar. 18 2009] - I posted more information about ADAM passthrough authentication.