I have noticed a disturbing trend recently. A lot of vendors seem to have taken the position that as soon as their help desk finds out that there is federation with another vendor involved, they immediately toss it over the wall.
I have seen my company (Optimal IdM) have to spend a lot of time and resources helping customers when vendor that really needs to solve the problem won’t do even the basic trouble shooting as soon a federation is involved.
So here is the question, is this because not enough support folks understand federation, or is that they do but want to reduce their work queue and see a convenient scapegoat?
Recently Microsoft announced Azure AD support for SCIM 2.0. This is a big deal. But the announcement was lacking one key detail:
Does Office 365 support managing users and groups via SCIM 2.0?
It seems that since Office 365 is based on Azure AD provisioning to Azure AD should be the same as provisioning to Office 365. But Microsoft doesn’t say that in the announcement or anywhere else that I can find. So for now I will have to assume that while SCIM is supported for Azure AD, it is not supported for Office 365. I would love to hear otherwise.
Great news, our VIS for Office 365 product won the Windows IT Pro Best of Tech Ed award.
It really is a great product. The key is that it dramatically simplifies Office 365 adoption for customers with complex multi-forest AD environments.
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.
Posted in Identity, Identity Management, LDAP, Programming, SOA, SOAP
Tagged Idempotent, Identity, LDAP, Protocols, REST, SOAP
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]
From the Orlando Sentinal is this report about police abusing the FL DMV database. The is more about it at the Reason blog.
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.
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.
Standards fascinate me. One of the most problematic standard in use almost universally today is the kilogram (kg). The problem is that no one really knows exactly how much mass a kilogram actually has. By extension that means that no one knows how heavy a pound is either since the US government defines it in relationship to the SI kg unit.
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.
Vittorio Bettocci from Microsoft has a great write up of OAuth 2.0 and how it relates to authentication protocols (but is not one itself). You can read it here.
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.
Posted in AD, Identity, Kerberos, LDAP, Linux, Open Source, Security, Software
Tagged Active Directory, AD, Kerberos, Open Source, Samba 4