Category Archives: Cloud computing

Optimal IdM wins best of Tech Ed for Cloud Products

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.

Tell us how you really feel…

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]

Office365 announcement

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.

Exciting times!

It’s easier to push than be pulled

There is a lot of push vs pull provisioning discussion going on recently. Both models have a place but there is hard and fast rule you should consider. If your solution requires your customers to stand up a web service (SOAP or REST) you are going to be running uphill against a head wind. Customers see public web services as support and security costs they just don’t want to pay.

For most customers it’s far easier to have a system running in a data center that makes that makes web service requests to a provider than it is to stand up a service. Google, for one recognizes this. The Google Apps Directory Sync is often incorrectly cited as a “Pull Provisioning” technology when it is exactly the opposite. The sync software runs on the customer side, reads from the local directory and pushes to the Google Apps Provisioning Web Service.

A proper provisioning standard, regardless if it’s SOAP or REST, should support both push and pull (note that SPML supports both). But I really don’t see the pull model getting much traction for cloud based provisioning. Perhaps it will for provisioning internal applications.

Federated Provisioning

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.

Top 10 cloud scares

This article lists 10 reason companies may resist adopting cloud services. There some good points here but number 6 is just silly. Even if you are a believer in anthropogenic global warming (as opposed to what is caused by the giant fusion reactor in the sky), you would sill be better off employing cloud services. Unless your company that has very sophisticated power management technology you won’t be able to run a service as efficiently on a per-user basis as a company that host services for a living. Power usage for that service is a much bigger cost item for them than for you and they have much more incentive to minimize it.

Number 7 is a good point but vastly understates the problem. It isn’t so important where the servers live but where your provider has a legal presence or does business. For example if your provider does business in China it will need to bow to their whims regardless of where the servers physically reside. Really US privacy laws (or the lack there of) are really the least of your worries in regards to your data.

Kloudy Kindle Kerfuffle

There are several themes emerging in the wake of the Kindle Kerfuffle (see this and this). These can be summarized as:

  1. Kindle is really a cloud service
  2. The recent file deletion kerfuffle is not about DRM, it’s about copyright protection
  3. 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.