Querying AD from SQL Server

This is a great how-to article on querying Active Directory from within SQL Server. I've written in the past about using Virtual Directory technology to query SQL data via LDAP. This is the reverse and I can envision many use-cases where this would be useful. This isn't exactly new technology, but it's a new write-up on how it's done and very easy to follow.

For example, you could use this approach to extend the information available to an application without doing any data synchronization or introducing new data sources. If the application's logon ID is the user's email address, you could query AD based on that email and get info about the user's group memberships, attributes, manager, location, etc. and have that returned to the application as if the data were stored in the local app's database.

...another useful approach to keep in your development toolbox.

Defining the Cloud

I just read another definition of Cloud Computing. It was a pretty good one, similar to what I submitted to the non-geek definition conversation. To save you the suspense and extra clicks, Andre Yee defined Cloud Computing as:

An on-demand delivery model for IT services or applications with the characteristics of multi-tenant hosting, elasticity (variable capacity) and utility based billing.

My version was:

Shared computing infrastructure over the web that distributes cost across participants and lowers the cost for each.

I actually like Yee's better than mine. I was focused more on the business purpose than actually describing what it is.

In thinking further, I think we should remove applications from the definition. Applications are delivered As a Service or On Demand. But it is infrastructure that is provided 'in the Cloud'. When we talk about Cloud Computing, we're talking about shared infrastructure (hardware, OS, security mechanisms, backup, etc.). I personally wouldn't use cloud terminology to describe what salesforce.com has made famous.

Salesforce isn't sharing infrastructure with other software providers. They're just including the infrastructure as part of the value they provide to customers. Their delivery mechanism internally looks a lot like what cloud computing providers offer, but they're offering it to their own customers.

Cloud Computing is a service for software or solution developers that can reduce cost by leveraging a shared infrastructure that is billed based on use. Those developers then offer their solution As A Service. But, they can also offer their solution As A Service without utilizing a Cloud infrastructure. They can, as Salesforce did, build their own infrastructure.

What do you think? Worthwhile distinction? Clear?

If the UI fails, the application fails

A blog posting by Luther Martin at Voltage reminded me of something I said a long time ago when I was developing Web applications:

If the UI fails, the application fails.

I probably wasn't the first or only person to have ever said that, but I think it rings true today and is especially applicable to information security practices.

Luther is specifically talking about cryptography and uses an analogy of mechanical clocks. If people had to understand how the clock worked in order to read the time, the clock would no doubt have failed to reach widespread adoption.

But, we have no trouble assuming that end users should understand that they need the HTTPS and should verify certificate authorities because obviously without proper SSL, the information they pass to their bank is exposed to snooping attacks and they are susceptible to phishing attacks. What?!? That statement contained five terms that most people off the street wouldn't even be able to define -- never mind understand well enough to use the technology properly to safeguard against relevant threats.

Security needs to be built-in. And the User Interface needs to be easy-to-use and simple to understand. Otherwise, as we've seen, the security mechanisms will fail.

SaaS-ish Identity Management

Matt P wonders about the security and reliability of having identity managed as a service. The more I think about IdM as a service, the more I like it. A company might tell you that they are concerned about the security of having their critical IdM systems hosted by (or managed by) someone other than their own trusted "Active Directory guy". But, that same company probably wouldn't think twice about bringing in consultants to help out (who easily have access to plant code, create back doors, enable bad accounts, etc.).

I think most companies are already outsourcing IdM – they just do it on a project basis and therefore have the associated personnel continuity, troubleshooting, and learning curve issues. Not to mention customized hardware and software combinations that nobody has documented or even understands. Wouldn't it be better if the consultants that designed and implemented the IdM solution did it in a repeatable way that is easily understood, managed, and configurable or extensible to adapt to future requirements? And they just continue to manage it taking the burden off of you?

This model also helps with infrastructure reliability due to economies of scale and the value of having a known environment. Yes, the Internet could go down. But, the internal network could go down too. Or the server. Or the database. With a managed solution, someone else will have the economies of scale to ensure a higher up time probability and a quicker response time (if they do it right).

I don't think security or reliability is a good argument against buying into IdM as a service. Data can be encrypted. Admin activity can be monitored. Redundancy can be built-in.

I agree with Matt that "only firms that specialize in the IdM space will be able to be successful hosts." I'd rather see an IdM service company try to move to the SaaS model rather than a SaaS provider try to create an IdM offering. But the complexity, repeatability, and value of IdM seem to make it ripe for a service-based delivery model. What do you think?

See the Statue

An old friend has migrated to a new blog titled Marcus Lasance's Identity Management and Privacy blog and posted today about the relationship between identity and philosophy. It's a topic that immediately caught my attention because I was a philosopher before I was a techie. I did my undergraduate work in Philosophy at a small mountainside university and I often took long hikes up the mountain to reflect on life's big questions. That was back when I was a user - you know, one of those people that just logs in and uses a computer without thinking about what's happening under the hood. It's been a long time. Do you remember when you were a user? Enough digression.

For me, the take-away from Marcus' comments is that we should remind ourselves to remove our blinders as we envision a new system design or architecture. We all have blinders of one kind or another - whether it's prejudice against data redundancy or preconceived notions of identity. We ought always to start with the essense of what we're trying to build and work outward from there - like Michelangelo who saw the statue within the block of marble. The question you should be asking is: What are the business requirements that we want to solve? If they're unclear, start over and try again. If they are clear, make sure that your design decisions support the successful meeting of those requirements and don't get caught up in pre-existing ideas about Microsoft or databases or enterprise architecture. Thanks for the reminder Marcus!

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?