identicentric - identity and security from the trenches

Over the past several months many of us at Identicentric’s parent, Zetetic LLC, have been working on a side project in Ruby on Rails called PingMe. In short, it’s a free interactive reminder service with Web, email, and TXT / SMS interfaces and some limited social features.

The easiest way to describe PingMe is as sort of an inversion of Twitter (no, we’re not affiliated with Twitter Inc. in any way…). We ask the question “What *should* you be doing?” You create reminders, called Pings, that are sent to your e-mail or SMS phone on schedule. On the web Pings look like familiar colored sticky notes on a whiteboard.

We’ve got some very slick mobile features that let you create and reschedule pings via TXT message or email to keep up with changing schedules while you’re away from the internet (think command line from your mobile phone), We’ve also added some basic social functions so you can hook-up with others, share Pings, and send reminders to your spouses, friends, family, and colleagues. Pings can even be tagged to create lists organized by category or context.

There’s even been a minor blog storm about PingMe…

• WebWorkerDaily - PingMe Offers Automated Nagging
• Mashable.com - PingMe Annoys the Hell Out of You To Make Sure You Get Things Done
• 43Folders.com - PingMe Reminders…
• LifeHacker.com - Set up quick SMS reminders with PingMe
• tech.BLORGE.com - Twitter’s opposite, PingMe asks what *should* you be doing
• KillerStartups.com - GoPingMe.com - What Should You Be Doing?
• Digg.com

… just to name a few. We even made it onto del.icio.us/popular.

Sign-up is free, only takes a minute and PingMe is flexible enough to use as a simple to-do list or as part of a “real” organization system like Getting Things Done. We hope you’ll check it out!

http://www.gopingme.com

There is no question that Access Management systems provide a host of benefits to the users and maintainers of web applications in large-scale environments. Yet, adding an access management system can also introduce a set of new potential points of failure. Even though infrastructure may be designed to maximize fault tolerance there is still risk because many security “eggs” are now in one basket. Systematic failure of any single component (LDAP directory, Virtual Directory, Access / Policy Server, web/application server plug-in, application integration code, etc.) can render applications unusable. As a result, system monitoring is often one of the most critical considerations in an Access Management deployment.

Thankfully, there are a number of network monitoring solutions that are capable of automatically monitoring applications and issuing notifications when a service become unavailable. We particularly like the open source Nagios system because it’s easily extensible, feature rich, and low cost. In order to make it more useful in the context of Access Management deployments we’ve developed a Nagios plug-in called CkFormLogin that monitors every point in the simple form login process common to most Access Management systems:

1. Initial request for a protected website URL - CkFormLogin verifies that the initial request receives a redirect to the login page.
2. Login page availability - CkFormLogin follows the redirect and performs a content check on the login page to ensure that it is accessible and no errors are returned.
3. Authentication - After login page verification CkFormLogin issues an HTTP Post request with the username, password, or any other credentials to a configurable authentication URL. This step tests the functionality of a web server plug-in like a WebGate, Web Agent, or Policy Agent and implicitly verifies the availability and functionality of any policy/access servers, LDAP directories and other supporting infrastructure components.
4. Content check - Assuming that authentication has succeeded CkFormLogin will follow the redirect back to the requested page and execute a custom content check on the page. By checking for the presence of some personalized text, or other identity specific data, the plug-in assures that application components have properly recognized and authorized the test user at runtime.

In short, this process provides a high level of assurance that secure/protected sites, and all of their externalized security dependencies, are actually available and functional to end-users. If any step in the login, authentication or authorization process fails the plug-in will return an error and the appropriate support staff can be notified by Nagios based on its configurable notification rules. When used in conjunction with other Nagios plug-ins for TCP/IP socket connections, LDAP, and HTTP services it can even help to pinpoint the root cause of a failure before a support technician even starts to troubleshoot.

The plug-in itself was written to validate the form login features of Oracle COREid Access Manager, but should also work with the usual suspects (Siteminder, Sun Access Manager, custom form based authentication) without significant modification. Its simple to install, requiring only Nagios, Perl and a few CPAN libraries. Like Nagios, CkFormLogin is released as open source software under the GNU Public License. Feel free to check it out.

As part of a large Identity & Access Management project we’ve beenmigrating a number of LDAP dependent systems from running under ASP.NET 1.1 to the 2.0 framework. The upgrade process has been remarkably painless, with the notable exception of a small but significant “breaking” change to authentication with System.DirectoryServices. In .NET 1.1 it is perfectly acceptable to issue an LDAP simple bind with code like this:

DirectoryEntry entry = new DirectoryEntry("LDAP://ldap.somecompany.com:389/");
entry.Username = "cn=Directory Manager";
entry.Password = "bigsecret";
/*...use entry for searching, etc, here...*/

However, execution of this code will fail under the .NET 2.0 framework unless it is modified to explicitly set the DirectoryEntry’s AuthenticationType property, because the class constructor no longer defaults the propertyto None. Here is what new 2.0 code should look like:

DirectoryEntry entry = new DirectoryEntry("LDAP://ldap.somecompany.com:389/");
entry.Username = "cn=Directory Manager";
entry.Password = "bigsecret";
entry.AuthenticationType = AuthenticationTypes.None;
/*…use entry for searching, etc, here…*/

Overall, its an easy fix, but finding every use of an authenticated DirectoryEntry in code can be tricky…

Nothing beats reading positive coverage of your company’s product. That’s why it’s so exciting to see that Dave Kearns, one of the most respected authors and columnists in the Identity Management space, has mentioned simAXS in his most recent NetworkWorld Identity Management Newsletter. From the article, Dave says that simAXS is “very useful” and that:

Anyone who has ever tried to develop a product that needs to be able to integrate with one (or more) of a number of different [Access Management] products will understand the problem this solves

It’s great to see that the pain-point simAXS is designed to address really does create a value proposition that’s recognized by the experts.

Microsoft ADAM provides a nice LDIF export tool, roughly equivalent to ldapsearch, called ldifde. However, the ADAM directory itself tracks a number of internal attributes that will cause a subsequent import of a generated LDIF to fail. In order to get a “clean” export, you need to selectively omit, via the -o command line flag, those operational attributes that you’re not interested in exporting (line breaks inserted for readability):

ldifde -f c:\people.ldif
  -d \"ou=people,dc=xyz,dc=com\"
  -s localhost
  -t 389
  -r \"(objectclass=*)\"
  -o   \"whenCreated,whenChanged,uSNCreated,
          uSNChanged,name,objectGUID,badPwdCount,
          badPasswordTime,pwdLastSet,objectSid,objectCategory,
          dSCorePropagationData,lastLogonTimestamp,
          distinguishedName,instanceType,lockoutTime\"

The output generated by the command can now be cleanly imported into another ldap directory, or into a separate ADAM instance using a simple import:

ldifde -i -f c:\people.ldif -s localhost -t 389

Yesterday Identicentric released simAXS, a developer tool that makes it easy to simulate access management integrations in a development environment. Additional information including a product overview, guided tour, demo screencast, and free trial are available. Some background and history follows.

At the Burton Group Catalyst conference this year Jamie Lewis spoke at length during his keynote about the challenges facing Identity and Access Management products and deployments. Of special interest was the fact that he identified a lack of easy to use developer tools as a major road-block to the widespread adoption of I&AM technology.

Walking away from the keynote I recognized that he was, as is usually the case, spot-on. In fact the subject of the keynote coincided with the idea behind a small utility, inspired by a need for improved development process, that we’d started to write. The premise was simple - provide a small standalone and configurable component that would pass Header variables directly to applications. Many Access management, Single Sign-on, and federation products, including Oracle COREid Access Manager, CA eTrust Siteminder, and Sun Access Manager, use HTTP headers to pass information about the logged in user to a protected application. In some cases the information is as simple as a login ID, but many advanced deployments pass roles, group lists, profile data, and identity information using the same mechanism, like so:

Most access management products do this by installing a small piece of code (WebGate, Policy Agent, etc) into the webserver that can manipulate the HTTP request directly at the server level. In IIS this usually takes the form of an ISAPI filter.

This approach provides interoperability and flexibility between implementations, but has some serious drawbacks - mainly that it is difficult or impossible for developers to insert HTTP Headers programmatically because HTTP servers are opaque. Developers are usually faced with some very undesirable choices:

1. Run a complex Single Sign-on / Access Management / Federation stack in their development environment.
2. Work while continually tethered to a shared server on the corporate network.
3. Fake integrations using hard-coded variables and form based stubs (and hope things work when they are deployed to the integration test area)

Over the course of 10+ access management projects it had become apparent that these challenges often resulted in days or weeks of wasted time. Problems with shared data and access control would often complicate the lives of developers even further. Likewise coordinating integration with development teams increased the workload of the shared services groups responsible for the I&AM infrastructure.

Enter simAXS: developers use it to simulate the same HTTP header and cookie base integration provided by large-scale commercial access management products.

The difference is that each developer manages their local environment and configurations through the simAXS tools - there are no external dependencies on access servers, LDAP directories, SSL connections, or authorization databases.  Instead of depending on a shared system or hard-coded “stub code” the tool puts each developer in control, using a simple management tool, of the data passed into their standalone development environment.

SimAXS works by installing a small ISAPI filter into IIS that gains full control of the web server, just like the popular access management systems. Once installed, a developer can select the desired profile using a web based utility that “injects” the appropriate header and cookie data into their session.

Applications that have been developed using simAXS can be deployed to a full-scale access management protected integration test or production environment with no code changes. Simply configure the access management agents to pass HTTP headers or cookies of the same name, and the fact that the data is coming from an LDAP directory, access server, or database is irrelevant to the application. From the application’s view there is no difference between running with simAXS or an access management enforcement point- the interface is identical.

The simAXS application itself takes less than 5 minutes to install, but can save hours or days of time from a typical development cycle. It also includes sample code, debugging utilities, and other features to make a developers life easier. Feel free to check it out.

Matt Flynn, in a post about AD password sync, asks:

What if a Virtual Directory could pass authentication requests to Active Directory the way that ADAM does? … Would this be useful functionality in a virtual directory? Is it technically feasible?

+1 for virtual directory pass-through authentication.

It’s definitely technically feasible and works very well to drive consolidation of authentication services. From past experience it’s one of the most powerful benefits of virtual directory technology. In fact, this feature was key to the value proposition and purchasing decision for several of the prominent deployments I’ve worked on. It was also one of the key topics we discussed at the DIDW 2005 Virtual directory panel.

Yesterday we discovered 100+ notifications for spam messages contributed through an online form by a malicious bot. We usually get a few of these per day at identicentric, because of this blog and various other unauthenticated forms, but the volume has never been enough to warrant decisive action. Nevertheless, Friday night’s activity “stepped over a line” and, much to our chagrin, spam continued to pour in over the course of Saturday morning at a rate of 15-20 per hour.

There are several established approaches to battling form spam. Some techniques requiring a user to enter in random characters displayed in a embedded image on the page. Others rely on logging IP addresses on form load, so that the processing script can reject bulk form submissions. Some attempt to use mod-rewrite to block form spam based on missing or specific Referrers or known blacklisted IP segments, with mixed results.

We wanted a dead-simple, general purpose solution that could be used to block spam on any form submissions, without dependencies on the back-end processor. Conceptually, mod-rewrite seemed like a nice fit because it could be implemented on Unix or windows (using ISAPIRewrite), and it was completely externalized from the form-backing application. Yet, the referrer and IP filtering techniques were unsuitable as they could result in long rewrite configurations, frequent ongoing maintenance, or incompatibility with many personal-firewall packages.

Our solution wound up being very simple, and involved setting a cookie using JavaScript that could be detected using mod-rewrite. It relies on the fact that spam-bots are dumb, not cookie-aware, and certainly aren’t JavaScript aware.
Here’s how it works.

Start off by creating a small .js file and including it in the page with the form. Expose a single function called setFormAllowCookie(), or something similar. This function, when called, will set a browser cookie named “formallowed” to a value of “true”.

function setFormAllowCookie() {
        var cookieName = \"formallowed\";
        var cookieValue = \"true\";
        document.cookie= cookieName + \"=\" + escape(cookieValue) + \"; path=/\";
        return true;
}

Include the .js file into the page with the form. This is easily embedded in practically any html page. Next, add an onload oronsubmit to the bodytag or formtag respectively that calls setFormAllowCookie().

The final step is to configure a rewrite rule that redirects form submissions to an error page if the cookie is not present in the request, like this (show protecting WordPress comments):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} /wp-comments-post.php
RewriteCond %{HTTP_COOKIE} !formallowed=true
RewriteRule (.*) http://blog.xyz.com/error.html
</IfModule>

Pros:

• This solution should continue to work until form-scrapers become cookie and JavaScript aware.
• This approach does not introduce dependencies on the form processing application.

Cons:

• Requires JavaScript and Cookies, potentially interfering with a subset of form submitters.
• Might not work against bots that are manually configured to attack a site, as a human could easily figure out the appropriate cookie to set.

It’s a judgement call as to whether the pros outweigh the cons with this approach, with the answer depending largely on the form’s target user base. In our minds the results speak for themselves: it took about 15 minutes to implement this approach to stop the initial barrage of spam and, according to logs, has operated with a 100% success rate against subsequent attempts.

Sean O’Neill from Sun points out some very valid reasons against using email addresses as unique identifiers within identity systems. I agree with him on all points, except for one:

So the recommendation still remains to utilize a numeric value or alpha/numeric value for UID and put up with user’s complaints they are not easy to remember.

Even within highly secure environments user perceptions can be very important. Customer facing applications, high-volume ordering systems, business partner extranets, and even large scale identity deployments within the enterprise are all faced with the challenges of balancing good data practices with user experience. There is no doubt that changing unique identifiers is a Bad Thing™, largely because they are used to map between different systems. However, playing the devils advocate, exposing poorly chosen UIDs to end-users can cause a wide range of problems including increased help-desk traffic, reduced usage of shared credential management services, and even the creation of duplicate user registrations.

Luckily, there is a middle ground made possible by separating the concept of the Username from that of the unique identifier (although they will remain interconnected entities at some level). First, at provisioning time, each Identity must be assigned a globally unique, persistent unique identifier. This is by no means a new concept, and it is often referred to as a GUID, so we’ll use that term here as well. In a properly implemented system this GUID will never change over the life of an identity. Next, each identity should be assigned, by some means, a friendly, easy to remember Username for the purpose of authentication.

The key to success with this relatively simple approach lies not within the separation of identifiers, but in how they are used. Basically, applications, databases, services or resources that reference the identity should always use the GUID. Period. The only entity in the entire universe that should ever reference the Username is the human authenticating to the system. After credential validation, the authentication system can simply map the GUID to provide a unique identifier to other resources.

Consider how this works in practice. Lets say you have an central authentication system using a popular web access management platform. Each user has an identity record in the central service. Each user also has access to one or more applications that have been integrated with the central service. Each of these applications has its own database back-end, auditing functions, and other services that require a UID. As Sean points out, when the Username is the UID, the entire identity system is fragile - a name change, typo, or marriage can break the mapping between the authentication service and the applications.

Now reconsider this situation when the Username and UID are separate. Jane Doe logs into her applications with the Username jdoe. Then the authentication service maps that back to her GUID, 09103510 (or whatever…), and passes that value back to the application she’s using. Now all of databases, services, transactions, historical audit logs, etc. are all tied to GUID. If Jane marries
John Tailor, none of the backend systems change. She can log in tomorrow with jtailor and her applications won’t even realize a difference. This same model extends nicely into more flexible systems too, as people could just as easily select their own usernames.

By decoupling the Username from the UID, an identity system can enjoy the benefits of strict unique identifier assignment along side complete flexibility in username assignment. Best of all it can be implemented with most (although not all) common authentication technologies like JAAS, Web plug-in style access management systems, PAM, SAML, LDAP, etc., with assignment driven by your choice of provisioning tools. While its not appropriate for every scenario, its definitely worth examining as an option while establishing standards for identifier assignment.

Thanks to Johannes Ernst for pointing out this gem by Peter Gutmann about the broken state of XML Security. Johannes is right - the article brings up a set of excellent points.

I often find myself asking the same question the original author Mr. Gutmann poses in his article - why insist on doing it the hard way? Within the context of web services, I’ve seen developers with little security training go down the road of WS-Security solutions that invariably break or are rendered useless by poor integration. Most often the project in question has three straightforward requirements:

1. authenticate the service provider
2. ensure that the message is not modified in transit by third parties without detection, and
3. ensure that the message is not readable in transit by third parties.

The requirements are dead simple - but its so easy and tempting to get lost in the details of the XML-way-to-do-things that the obvious solution is never used. If you’re using SOAP for web services (which most people are), and you’re adhering to the WS-I Basic Profile 1.0 (which most people should be), then you’re using HTTP as a transport. The fact is that SSL/TLS provides a practical method of security communications between service providers and consumers over HTTP, including XML web services. It has practically universal platform support, good performance characteristics, encrypts all data sent between parties, prevents data tampering, supports authentication of both servers and clients, and there is widespread availability of acceleration hardware. Plus, the security is externalized, so it drastically reduces required integration time, and places no dependencies on developers for “proper” implementation. It’s a very pragmatic and elegant solution to several web service system security problems.

Don’t get me wrong. WSS is great and has a wide array of very legitimate uses, and I’m not downplaying its importance in the web service arena. Nor am I’m trying to imply that SSL/TLS is a security panacea - especially if your XML transport is not HTTP. But good system security is about choices - and often the simplest choice that meets a particular requirements is the best choice. So if your web service implementation has straightforward security requirements, my advice is to take a close hard look at SSL/TLS.