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
John Fontana writes about a new idea called People Centric Security. The idea is to loosen enterprise security policies so that security decisions are made by those directly responsible for business area rather than a central security team.
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.
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.
There is an idea that has been kicked around in IdM for years called Security Policy Provisioning. Basically the idea is that you have a system that takes centrally managed security policies and pushes them out to disparate system, the same way provisioning systems manage user accounts. We kicked around the idea of building a Security Policy Provisioning product back at OpenNetwork, but never did. In all honesty I had expected some IdM vendor to have added this feature to their provisioning engine by now, but as far as I know none ever went farther than user role management.
Well Axiomatics has apparently rolled it out in the guise of pushing their XACML policies to Windows Server 2012 to leverage the new authorization features. This is a very neat idea.
Of course after you push out the policies, Windows Server 2012 becomes the PDP as well as the PEP. You could develop a similar solution without using XACML at all.
I recently saw two polar opposite recommendations; one from Jeff Atwood begging you to not write code; and one from Radovan Semančík suggesting that the only practical software to use is open source software that you can fix as needed.
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.
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.
Posted in AD, Authentication, Cloud computing, Identity, Identity Management, Microsoft, Security, Standards, WS-Trust
Tagged Identity, Office365, WS-Federation
Now that SCIM 1.0 is final and SCIM 2.0 is starting I wanted to share my thoughts. First here is what I like about SCIM:
- 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.
Radovan Semančík has put together an interesting list of open source IdM platforms. There are not as many as I would have expected.
One of the most puzzling complaints I have heard about SPML is the search filter. The complaint is that it requires the service to support search filters of arbitrary complexity. I have never considered it that hard and have posted sample code to demonstrate it.
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.