First Week at RSA

I had an interesting and busy first week at RSA. It's no surprise that I met some extremely bright people. I spent my first few days in Phoenix working with an internal team and managed to speak with a few customers as the week progressed. Some of the very cool ideas I've already heard include:

• Providing Network Access Control using machine certificates. The idea here is that you can't plug in a machine without a proper cert and gain access to the network. RSA has certificate management software that makes this solution a reality. The cert can be based on a specific hardware profile so getting your hands on the cert won't help. It's simple and effective.
• Risk-Based access control or what RSA calls Adaptive Authentication. This is about adding an additional dimension to the authentication process. Not just what you have and what you know, but where are you right now? Or from which device are you attempting to gain access?
• The business value of implementing Federation as a way to reduce bandwidth on the LAN. It never even occurred to me until one of my new colleagues pointed it out. Why tie up your global WAN with unnecessary packets (and spend your budget on increasing infrastructure) when you can leverage the web to pass access rights to overseas applications using a simple Federation solution?
• RSA also has a nice key management utility for organizations that need to build encryption into software solutions but don't want to assume the burden of: 1) designing a secure encryption solution. 2) securing the encryption keys for use by the solution. Or worse yet 3) managing the on-going key life cycle. Keys can be shared amongst applications and re-generated on a schedule to reduce the risk of the keys being compromised.

Needless to say, I'm already getting very busy. I have a lot to do and I have to say I'm invigorated by the new challenges. ...until next time.

TBG's take on EMC + RSA

On The Burton Group's new identity blog, they recently weighed in on EMC's purchase of RSA. I think it's a little more insightful than the other coverage I've seen (albeit at a high level):

Why did EMC acquire RSA Security?

More Info:

• EMC sets up RSA security division, Sept. 26, 2006
• EMC Secures its future, Sept. 22 2006
• SMBs should outsource everything and vendors must adjust, Sept. 20, 2006
• In Depth: The Transformation Of EMC , Sept. 18, 2006
• RSA Security acquired by EMC for $2.1 billion, June 29, 2006
• EMC Announces Definitive Agreement to Acquire RSA Security, Further Advancing Information-Centric Security (Press Release), June 29, 2006

Time to rethink your IdM strategy?

"The unexamined life is not worth living"
- Socrates

"The unexamined Identity Management solution is not worth the investment"
- Me

While not quite as eloquent as the original, my point is that we should apply Socrates' theory to business and IT strategy just as we apply it to the way we live our lives. I gave a nod to a blog post a while back that described Identity Management as a lifestyle. Yesterday, in an article entitled CIO Jury: Businesses face ID management headache, the CIO Jury reminds us that identity management is a lifestyle. You can't set it and forget it like Ron Popeil. You need to make a plan, start to build, re-evaluate, launch some functionality, re-evaluate, build some more, alter the plan, evaluate what's coming next, etc.. There are certainly technology components that will run on their own without constant maintenance, but they live at a very tactical level. At the strategic level, it's important to continually re-think the plan. The business climate as well as the technology landscape are both dynamic in nature. Change is constant. Keep this in mind during planning and be prepared to switch gears if needed.

In a recent MaXware webinar, a customer described the process of backing out of a big investment in IdM and starting again with an entirely new product set. The webinar will be available on the MaXware site and it's definitely worth the viewing time. One important take-away for me was that you can forfeit a major investment that's not working, completely shift gears and come out successful. It takes some guts and some ingenuity, but it can pay off. The webinar presented an excellent example of the value of constant re-evaluation.

Another point I want to make is that while planning an Identity services architecture, it's vital to build an environment that is flexible and adaptable. Take a look at Identicentric's idBUS product. They've got the right idea. Build a flexible service-oriented middleware layer that enables you to quickly adapt the front end apps or the back end infrastructure to the ever-changing business requirements. I've also talked in the past about Virtual Directory as a data abstraction layer providing similar capability but at a data access level rather than an application access level. Think about these approaches and how else you might enable your Identity Services infrastructure to adapt quickly to changing requirements.

And rethink your Identity Management strategy. It's always a good time for that.

The Keys to Successful IdM Deployments

In case you missed Digital ID World this year and didn't get to hear his presentation, Shawn Ellis, Director Identity and Access Management at Raymond James Financial, will share his enterprise identity management story tomorrow at 11am PST/2pm EST.

Click here to view the Webinar invitation and enroll.

Registration is free and takes just a few minutes. ...There's always something to learn from somebody else's project experience.

Identity Management Software Design Guidelines

Identity Management infrastructures are large and complex. There are many moving parts and sometimes deciphering one component from the next is difficult. When you consider that there are numerous software vendors that offer different versions of each component and sometimes classify identity solutions differently from each other, the task of identity software selection can be daunting. To make the task easier, organizations should develop some design criteria by which to measure individual software components against each other. Rather than just conducting a feature and functionality comparison, companies should develop a set of architectural considerations that are important within their own organization.

With one eye focused on the move toward service orientation and the underlying premise that business agility will be a key differentiator for companies moving forward, here are a few recommendations for criteria by which to measure identity software solutions:

• Open: The software is based on open standards rather than proprietary or closed architecture. It can run on Windows, Unix, Linux, etc.. It can be accessed via multiple incoming and outgoing protocols. It's interoperable with other like-minded solutions.


• Extensible: The software is able to be extended. Organizations are complex and specific needs vary greatly. Identity software should be able to be extended to meet whatever requirements arise now or in the future. The solution should be extensible at multiple points and via open languages or APIs.


• Flexible: The software can be put to use to solve multiple problems. Identity software that solves only one specific problem is limiting. Identity software needs to be flexible enough to meet multiple demands and solve numerous problems. While an application can't be all things to all people, it can keep flexibility as a core design goal so that companies can leverage the solution to achieve their maximum ability to adapt.


• Small-Footed: The software leaves a small footprint on the IT architecture. The requirement to load numerous components and additional applications to support the deployment of a single identity solution leaves a bad impression upon the existing architecture. Identity solutions should fit seamlessly into an existing infrastructure without the need for additional software. Each new required component increases the cost and complexity of the environment - and reduced its manageability.

I thought about including performance, but I ultimately decided against it for 2 reasons: 1) it's highly subjective and 2) it will vary for almost every implementation based on architectural decisions, infrastructure and requirements. So although software makers should strive for high performance, it's difficult to measure without extensive testing.

What else is on your list of identity software design goals?

Burton Document on Identity Data Services

The Burton Group published a new research document today:

Enabling Identity Data Services: New Developments in Identity Tooling Provide a Good Start
You can find it under: Identity and Privacy Strategies

The article touches on many of the same concepts that I've been grappling with lately related to identity data services. They discuss the value of an identity interface layer. The concepts they present are more advanced than what I've been talking about, but I think they're based on the same underlying business drivers, which is encouraging. It's good validation. And I learned a few new things. It's well worth the read if you have a Burton account. Go check it out.

Dave Kearns on Virtual Directory

Dave Kearns' latest newsletter states: Virtual Directory finally gains recognition. He writes:

"Virtualization is hot and a virtual directory is the building block, or foundation, you should be looking at for your next identity management project"

So, it's not just me. Thanks for getting my back Dave ;)

Starting Point for Identity Services

A while ago, I posted about the Identity Management Continuum. I want to revisit that topic from another angle. As we move toward a service-orientation and establish a more component-ized architecture approach, it becomes easier to insert, remove or swap any one particular piece of the puzzle. The continuum still exists - an Identity Services infrastructure is dynamic, should be implemented in phases and should be cyclically re-examined in accordance with business goals. But the starting point clearly varies based on the needs of the organization. For some companies, a particular set of functionality is important. They want to reduce the number of user passwords, provide self-service password recovery, provide a single sign-on service or user-enable a new application. For other companies, the goal is simply to start building an identity infrastructure. Either way, the solution design goals are the same - to implement an open and flexible identity services infrastructure so that components can be added, improved or removed as business needs change.

One solution that makes this architectural approach extremely accessible is an identity services data abstraction layer. An abstraction layer unties the bind between identity services and identity data. Identity data is typically stored in multiple locations, structures and formats throughout an organization. Mapping each identity service to all of those data repositories is a daunting effort. One way of building an abstract layer is by creating an enterprise directory that holds all of the organization's identity information. This can be effective if an organization knows all of the identity and application requirements for this uber-repository. Unfortunately, application requirements change. And data repositories change. And new services rise and fall. Due to the dynamic nature of the business environment, enterprise directories are difficult to manage and maintain. There's often a trade-off between enabling new services and just keeping up with status quo.

An alternative approach is to leverage virtual directory technology as a data abstract layer. Virtual directory technology not only effectively maps identity services to identity data to meet current requirements, it also enables the organization to rapidly adapt to changing business needs. Migrating data repositories to new formats or structures is a seamless experience for the consuming applications and services. Adding new services is easy because identity data is accessible in a single location via customizable views.

I've often heard people discuss virtual directory technology as cutting edge technology that's only adopted by advanced organizations that have well-developed identity infrastructures. I propose that we (as the IdM community) ought to be encouraging the businesses we serve to look at virtual directory technology in the earliest stages of design. Since our process is cyclical and our requirements are dynamic, it's extremely important to be able to adapt to ever-changing identity needs. Virtual directory is a no-brainer for this scenario. If implemented early enough, organizations can greatly reduce the workload of implementing and managing identity services each step of the way - say by 20% - 25%. Isn't that the portion of the effort associated with integrating identity services and applications with the underlying data?