Category Archives: Identity

HTTP PUT vs LDAP Modify

The StormPath blog has an interesting article exploring HTTP PUT vs POST in REST based APIs for managing identity information. The article is interesting and worth reading, but misses the bigger picture. It points out that both HTTP PUT and POST can be used for sending updates in a REST API, but the HTTP spec mandates the HTTP PUT be idempotent. The idempotent requirement dictates that for an HTTP PUT, all values must be sent on the request, not just the ones being modified by the client.

Now I am sure idempotent PUT operations are important to people that design ways to update html documents. But I’m not in that business and neither are you. I am in the business of designing and enabling distributed identity systems, and in that business you never send a modification request that passes data you don’t need to modify. Simply put, you have to assume multiple concurrent updates to the backend data.

Put another way the article could simply have said “Never use HTTP PUT for data modification”. And herein lies the most important lesson of REST APIs: the REST mechanism is the means by which to build distributed systems, not an end to itself. The fact that you are using REST does not obviate the principals of basic distributed system design.

Oh, but it gets worse. Assuming your data model is attribute-value based, some of those attributes are going to be multi-valued attributes. Just as a client should only transmit the attributes that are modified, it should also only transmit the value modifications for multi-valued attributes.

That’s why LDAP Modify works as it does. One common mistake developers make using LDAP is not doing proper multi-valued attribute updates. Likewise your REST API will not only need to support partial record updates but partials attribute value updates.

Tell us how you really feel…

Okta has some choice words about ADFS in this recent post. I always felt that if you can’t say anything nice… don’t blog about it.

Jackson Shaw points out that the operative four letter word is FREE.

Claiming your product is better than a free product is a losing argument. A better approach is to make a product that co-exists with, and extends, a free product.

That’s where VIS and VIS Fedaration come in. ADFS is a great tool for a lot of enterprises. But for some enterprises it needs a little help. The OptimalIdM products work side by side with ADFS and AD and extend their capabilities.

[Full disclosure: I am an employee of OptimalIdM]

Next war on passwords

Google is the latest vendor to try to slay the password beast. I wish them the best, I really do. But password authentication hasn’t been the defacto security for this long without a reason.

Still, if any vendor has a shot it’s Google.

Did you get DC source code for Christmas?

Just in time for Christmas Samba 4.0 was released. This big news here is Samba 4.0 adds Active Directory Domain Controller emulation, including Kerberos, LDAP, DNS, and a bunch of other services.

While this is an impressive technical achievement, I don’t really see many enterprises adopting it. Samba 4 is fighting against one of the biggest IT pressures, headcount reduction. Most enterprises are now willing to pay more for the license cost of the software if it saves them administrative man hour costs.

So unless Samba 4 is going to be easier to install and maintain than Windows servers, it’s not really going to have an impact. Who knows, maybe it will be that easy. If you have Samba 4 in production drop me a comment and let me know what you think.

Meanwhile, Jackson Shaw is … unimpressed.

Graph API for Windows Azure Active Directory

Last week at TechEd Microsoft disclosed their new Graph API for Windows Azure Active Directory. Graph API is a RESTful web service for accessing the identity system behind Windows Azure and Office365.

This is an interesting development because it will enable Azure and Office365 customers to provision with systems other than FIM. While Graph API is not specifically an identity management API like SPML and SCIM, the capabilities are effectively the same in the context of the Azure environment.

There is a great presentation on this here, including a demo of the soon to be released OptimalIdM support.

It seems strange that there is so little attention being paid to this. It really an important step in cloud identity.

Office365 announcement

OptimalIdM announced its new Office365 offering this morning. You can read the announcement here.

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!

Enter the Migrator

One common business case we get is to migrate from various directory servers to AD. This is usually an issue of per user license cost but lower maintenance is also a factor. Companies are realizing that since they are maintaining AD anyway, why pay for and maintain other multiple directory servers as well? For employee accounts it usually doesn’t make sense to have the same account in two places and need additional processes just to keep them in sync.

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).