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.