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.

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]

Government databases will always be abused. That’s the nature of man and there is no use fighting it. Which is why massive government databases should not be created to begin with, unless there is no alternative.

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

Originally the metric system was supposed to be defined in terms of “natural laws” that the common man could measure for himself. The kg was originally defined as a cubic decimeter of water under certain conditions. This is probably what you were taught in school, one of many metric misconceptions (see why everything you know about the metric system is wrong).

But that approach was jettisoned as impractical due to variations in water density, temperature, etc. In 1889 the standard became defined by a set of “physical prototypes” that were manufactured and distributed to major countries. So what was a standard based on “natural laws” became based on an arbitrary hunk of platinum and iridium.

Only that has not worked either (at least not to the number of significant digits desired). The problem is that the different physical prototypes are changing mass by a small but measurable amount. So today there is effectively no precise consistent definition of a kilogram, and thus by extension the pound.

The plan going forwards is to define the kg in terms of basic physical properties, similar to what has been done with the meter and the second. But for now, kg is only an estimate for given levels of precision.

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.

Given the recent news that Instagram has announced that they now have the rights to sell your photos, perhaps that should be good advice for online services. Here is a good hint; if you aren’t paying for a service, then at a minimum you aren’t a “customer”. Oh the service has customers all right, you’re just not in their number.

Update: of course XKCD nails this one better than I ever could.

To paraphrase the immortal words of Pogo: We have met the security team and they is us!

For better or worse I think this actually reflects the current state rather than some new idea. For all the work security teams do, users just work around them to do what they need to do.

Who many times have you heard these conversations:

• The mail server blocked your attachment. Can you send it to my gmail account?
• I can’t reach your website. Let me disconnect from the VPN and try again.
• Our machines disallow USB storage devices, but I can upload the files to DropBox.

Your company’s security already depends on your users. They are just pretending it doesn’t.

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.