Nishant Kaushik has a great (and funny) slide deck on federated provisioning on his blog. He discusses some distinctions between two flavors of federated provisioning, the Just-in-time (JIT) and what he terms advanced provisioning (often referred to as bulk provisioning).
I would like to clarify a couple of points in his presentation, however. He talks about a possible SAML profile of SPML for JIT provisioning. There was already an effort (which I lead) to define a SAML profile of SPML in Project Liberty (most of the work has already been done if anyone wants to revive it). But this was not for JIT provisioning as there is really no need for SPML when doing JIT provisioning. JIT provisioning can be done by SAML alone (or OpenID+other stuff). Rather the SAML profile of SPML was intended for advanced (bulk) provisioning. While the DSML profile could be used for advanced provisioning the Liberty TEG felt that using the SAML attributes assertions as the provisioning data structure was a better fit for advance provisioning accounts that would later be used in a SAML sign-on.
Me, I see it six one way, half dozen the other.
Another point the Nishant brought up is the need for the equivalent of the SAML attribute query in SPML. That already exists in the form of the SPML Search query which supports getting a single user record and asking for a subset of attributes.
When discussion whether JIT or advanced provisioning is appropriate, the points that are usually brought up are auditing, de-provisioning, and billing. But Nishant overlooks the most important point:
Do the identities have any meaning outside of authentication?
If the answer for your service is yes, than JIT provisioning is likely not an option.This is not a case of “tightly coupled” versus “loosely coupled”. Rather it is a matter of business requirements.
Take my current employer CareMedic (now part of Ingenix). We have a suite of medical revenue cycle management web apps that we host as SaaS. We need to know the identities of our customer users for the purposes of workflow before the user actually logs into the system.
Of course there are plenty of apps where the business requirements make JIT provisioning ideal. But it still comes down to the business requirements, not the technical architecture or standards.
Posted in Cloud computing, Identity, Identity Management, OpenID, Provisioning, SaaS, SAML, SPML, Standards
Tagged Federated Provisioning, Identity, Identity Management, SAML, SPML, Standards
There are several themes emerging in the wake of the Kindle Kerfuffle (see this and this). These can be summarized as:
- Kindle is really a cloud service
- The recent file deletion kerfuffle is not about DRM, it’s about copyright protection
- Kindle had to delete the Orwell titles because they did not have the rights to sell it in the first place
The second and third arguments are the easiest to dispense of. Without getting into the legalities (I am not a lawyer) the simple fact that they promise not to do it in the future means that they didn’t have to do previously. And of course DRM is the main issue. Without DRM we wouldn’t be talking about it.
Which leaves the question, is Kindle really cloud service? The argument is that it is really a Cloud bookshelf where your books are cached to your local device. I don’t buy it. By that definition web pages are a cloud service because they are stored on a server and cached on your local device. The main thrust of Kindle is reading books on your Kindle reader. The fact that you can get books from the cloud is just a delivery mechanism, just like downloading software to run on your PC. If that makes it a cloud service, then please tell me what doesn’t qualify as a cloud server.
The Cyber Cynic raises this point:
But, it’s worse than that. Now, that we’ve discovered that Amazon can remotely and automatically delete your books without your knowledge or consent, what’s to stop Amazon, some other company, or the government from not merely deleting it, but replacing it with an edited version? Nothing.
It’s not that I’m not a trusting person… oh wait it is.
Here is an interesting story about one downside to SaaS:
Stealing the password for someone’s Gmail account, for example, not only gives the hacker access to that person’s personal e-mail, but also to any other Google applications they might use for work, like those used to create spreadsheets or presentations.
That’s apparently what happened to Twitter, which shares confidential data within the company through the Google Apps package that incorporates e-mail, word processing, spreadsheet, calendar and other Google services for $50 per user per year.
Co-founder Biz Stone wrote in a blog posting Wednesday that the personal e-mail of an unnamed Twitter administrative employee was hacked about a month ago, and through that the attacker got access to the employee’s Google Apps account.
Of course internal documents get compromised all the time in companies that use traditional methods of document sharing, but its still food for thought.
Jackson Shaw makes the point that the last thing that most enterprises need is to take on is provisioning their SaaS identities when they are still struggling with their internal identities:
We have a standard called “Services Provisioning Markup Language” (SPML) which was specified to help provision identities via a web service. Does your SaaS vendor support that standard? I’ll bet they do not! What do you do then? I’ve met with hundreds of customers over the years and many are still struggling with provisioning inside the enterprise! Throw in SaaS provisioning – via some hairbrained interface because the vendor doesn’t support SPML – and it only adds to the organization’s identity management complexity.
Of course having an SPML capability in a SaaS is not going to be much help if the enterprise doesn’t have a provisioning system in place with SPML support. SPML support is not widely available in provisioning systems (although there are a few that have it out of the box).
Ashraf Motiwala echoes the point and also points out that enterprise are going to want to leverage not only their internal provisioning systems, but also their workflow and role management systems as well:
Recreating a workflow engine, role management, delegation, etc. in the cloud seems to just create redundancy for these capabilities, especially for organizations that have already dropped a few dollars to deploy an IdM solution on premise. Why would I drop my existing investment here? (Perhaps there is a compelling case, but I just don’t see it.) I would much rather find a solution that proxies the SPML requests from my existing provisioning solution that handles all the complexities (or “hairbrained interfaces”) for the SaaS apps on the backend!
The upshot is that SaaS vendors should be rolling out SPML interfaces to their services. But just like with the traditional enterprise software vendors, they most likely won’t do it until the customers demand it. Until it becomes a selection criteria it probably won’t happen.
The Economist is warning of a new vendor lock-in, Cloud computing (hat tip to Suretec):
But now there is the danger of a new form of lock-in. “Cloud computing”—the delivery of computer services from vast warehouses of shared machines—enables companies and individuals to cut costs by handing over the running of their e-mail, customer databases or accounting software to someone else, and then accessing it over the internet. There are many advantages to this approach for both customers (lower cost, less complexity) and service providers (economies of scale). But customers risk losing control once again, in particular over their data, as they migrate into the cloud. Moving from one service provider to another could be even more difficult than switching between software packages in the old days. For a foretaste of this problem, try moving your MySpace profile to Facebook without manually retyping everything.
I wrote here about how legal jurisdiction affects privacy. Tim Cole writes here about how the EU Data Protection Directive affects cloud services:
Recently, at a press briefing by German IBM boss Stefan Jetter who waxed enthusiastic about Cloud Computing, an elderly journalist rose and asked him a show-stopper: “Where are my data when they’re out there in the Cloud?” Jetter did a double take, but my colleague pressed on: “I mean, physically, where are they?”
Of course, the answer is: On some nameless server somewhere, anywhere in a grid farm in Ohio or Dublin or… In fact, the usual answer is : Who cares?
Well, for one the German privacy protection agencies. Passing data across national boundaries can be a federal offense not only here. The EU Data Protection Directive (officially Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data) mandates that personal data may only be transferred to third countries if that country provides an adequate level of protection – something the U.S., just to name one, does not, at least not according to European standards, especially since foreigners do not benefit from the US Privacy Act of 1974.
This could well be problem for smaller cloud businesses that don’t have an EU hosting center. That means that they not only couldn’t serve EU based customers if their service included personal data, they also couldn’t serve multinational companies that had employees in the EU.
Bruce Schneier has this posting about privacy risks for Cloud software. These are all good points, but there is one that Bruce doesn’t mention. In fact few people are mentioning it which is a shame because it’s one of the biggest risks with using Cloud services: controlling legal authority.
In other words, in what country’s jurisdiction is your Cloud service? Do you know? Shouldn’t you know?
This was brought home recently when Germany-based RapidShare had to divulge its users IP addresses, according to this ARS Technica article:
The popular Germany-based file hosting service RapidShare has allegedly begun handing over user information to record labels looking to pursue illegal file-sharers. The labels appear to be making use of paragraph 101 of German copyright law, which allows content owners to seek a court order to force ISPs to identify users behind specific IP addresses. Though RapidShare does not make IP information public, the company appears to have given the information to at least one label, which took it to an ISP to have the user identified.
The issue came to light after a user claimed that his house was raided by law enforcement thanks to RapidShare, as reported by German-language news outlet Gulli (hat tip). This user had uploaded a copy of Metallica’s new album “Death Magnetic” to his RapidShare account a day before its worldwide release, causing Metallica’s label to work itself into a tizzy and request the user’s personal details (if there’s anything record labels hate, it’s leaks of prerelease albums). It then supposedly asked RapidShare for the user’s IP address, and then asked Deutsche Telekom to identify the user behind the IP before sending law enforcement his way.
What’s really interesting is this comparison to the laws governing US based last.fm and Germany based RapidShare:
There are, however, many differences between Last.fm and RapidShare. For one, if Last.fm were to find itself in the position RapidShare is in with GEMA, it would be able to argue that the Safe Harbor provision in the DMCA protects it from liability as long as it removes infringing content after being presented with a takedown notice. In Germany (and many other countries), there is no equivalent, meaning that RapidShare has little choice but to comply with the rulings. RapidShare’s incredible popularity-Germany-based deep packet inspection (DPI) provider Ipoque recently put out a report saying that RapidShare is responsible for half of all direct download traffic-has only made the issue more sensitive for the record labels and service providers alike.