Obviously Radovan’s approach is not a scalable one. While there are a lot of terrible software products out there, especially in the enterprise space, there are also a lot of good ones that just work. Limiting yourself to coding solutions is a waste of time that most companies won’t pay for. Also Radovan’s solution limits you to open source solutions implemented in a language you are familiar with.

At the same time there are some problems that just need a coding solution, or are best solved that way.

 For enterprise solution I am going to thread the path between Jeff’s Scylla and Radovan’s Charybdis by posing these questions:

• How much coding should be expected to implement an enterprise solution?
• How can you find enterprise solutions the works well enough you don’t need the source code or extensive customizations?

An enterprise solution that requires you to write code or scripts to do basic functionality is not well designed, in my opinion. Coding or scripting should only be required wheen the functionality needed is unique to a specific deployment (or too uncommon enough to be a main feature of the product). This is a core philosophy at OptimalIdM as well. Although the VIS virtual directory does support .NET plug-ins, most of our customers never need one. When we have seen the need for plug-ins in the past we looked for a common feature that could be added to the product.

So not having to write code one measure an enterprise solution’s quality. Here are some others:

Ease of install – they say you only get one chance to make a good first impression and install time is it for enterprise software. If your vendor is telling you that you need consulting hours just to install the software, it’s not going to get better from there.

Ease of use – requiring training to use enterprise software is a bad sign. Did you have to have training to use your browser or word processor? Enterprise software should be like that.

Stability – once installed and configured the software should just work. Baby-sitting should not be required. And if you really need two weeks of work or the source code to figure out why your solution stopped working, you made a poor vendor choice.

So go ahead and write code, but only when you have to.

This has been an great project to work on. OptimalIdM can now enhance Office365 with a great set of new features and can do so for both the WS-Federation Passive and Active profiles. The Active Profile is used for Office365 Lync and Outlook support.

The new features we add to Office365 include easy multi-forest support, support for non-AD users, support for users with non-addressable UPNs, two-factor authentication, auditing, and a whole bunch of other features.

Exciting times!

There are several ways you can migrate directories. You could use a one-time import/export, a Metadirectory, or a provisioning system, but these approaches have several key drawbacks. One issue is that in most cases you can’t migrate the user passwords. Another issue that the migration may require custom attributes to be added to AD (try getting your AD team to agree to that).

But the biggest issue is that these directories exist for a reason. There are client apps, sometimes tens or hundreds, which rely on the information in the old directories. Most home grown apps written for one directory won’t be able to switch over to AD without extensive rewriting. Even commercial apps that support AD may require significant and disruptive configuration changes.

Enter the Migrator (obscure Disney reference intended)

A virtual directory can be your Migrator. The solution is to standup a virtual directory that merges your AD with the old directory into a single view that emulates the old directory. Run both directories side by side while migrating the accounts. When a password change is made the virtual directory can update both AD and the old directory with the new value, so after running side-by-side long enough, most of the passwords will have been migrated. Eventually the old directory can be retired.

This approach has two main advantages:

• no changes need to be made to the client applications
• no schema changes need to be made to AD.

There is a good white paper that covers this in detail on the OptimalIdM web site (no registration required).

The creeps a lot of people out. What creeps them out even more is that you can’t opt out.

Of course there is always my way out… (cue lightning flash and creepy James Earl Jone laugh).

Seriously though, don’t use Google services exclusively. Use Bing instead of Google for searching. Use Yahoo instead of GMail. Buy an iPhone, or if you want an Android phone, create a new email account just for phone use. Use Facebook instead of Google+.

If you give one company all your data what do you think they are going to do with it?

You ultimately have control over this in your choice of providers. You can opt out by switching.

If you are not familiar with the acts you really need to be. Please take time to visit the EFF pages on SOPA and PIPA here and in more detail here.

The job you save could be your own.

• SCIM defined a standard schema in 1.0. I wish SPML had done the same. Not doing so was one of the biggest mistakes we made.
• SCIM supports filtered and paged searches. That’s a must have in my book.
• SCIM supports multi-value attributes with the proper modification semantics. You be surprised how many Identity APIs I have seen that don’t get the modification semantics right.
• SCIM only did what it needed to do, nothing more.

So what don’t I like about SCIM? I don’t really care about the REST vs SOAP aspect. It’s not going to be widely used unless it’s wrapped in an API or toolset. So that’s a moot point. So I can’t really think of anything I don’t like.

But will SCIM be accepted where SPML was not? I don’t know, but I think there is a decent chance. I think announcing the IETF SCIM 2.0 effort so soon may be mistake as it may convince people to just ignore it until 2.0 comes out.

But ultimately the proof of standards is in adoption. For it to succeed it has to be both adopted by the cloud providers as a service and by IT as a client. Each of them wants the other to go first.

My biggest question is will the backers of SCIM implement it in their main product lines. Will SalesForce.com stand up a SCIM provisioning service? Will PingIdentity then add SCIM support to their SalesForce.com offering? We shall see.

Jackson Shaw has some great points to make about it here, but I didn’t really get the parrot reference. He points to this article about SCIM which also makes some great points.

Security via obscurity, as effective in 1903 as it is today.

Hat tip to Bruce Schneier.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 7,600 times in 2011. If it were a NYC subway train, it would take about 6 trips to carry that many people.

Click here to see the complete report.

Still, perception has a reality of its own and search filters are often given as a reason not to support SPML.

So now that SCIM has finalized the 1.0 version, the filter-phobes can breathe easy, right? Not so much it seems. Like SPML, SCIM has a search filter mechanism that supports filters of arbitrary complexity. Which is a good thing for without that capability a provisioning service would be severely limited.

But really this should not be a reason to avoid either SPML or SCIM. This class of problem comes up regularly and provisioning service developers should learn how to handle it (if don’t already). One could argure that it would even be considered a pattern.

Actually it is: the Specification Pattern.