Identropy Moves Application Provisioning to the Cloud

Michael Vizard

One of the most significant challenges that any IT organization faces when it comes to managing cloud applications is provisioning access. By and large, Microsoft Active Directory is the dominant method IT organizations rely on to provision access to applications within the enterprise. The problem is that Active Directory can’t be easily extended out to manage applications in the cloud.

What’s really needed is a way to provision application access using an identity management offering that can manage applications on premise and in the cloud. To address that specific issue, Identropy today launched an identity-as-a-service (IaaS) offering called SCUID Lifecycle that is based on technology that Identropy previously made available as a managed service.

According to Identropy Chief Architect Nishant Kaushik, SCUID Lifecycle goes beyond simply providing users with a single sign-on password capability by giving IT organizations all the tools they need to actually provision applications via the cloud without incurring massive system integration costs. Identropy includes support for most popular cloud applications and, says Kaushik, can be extended to support other applications via the emerging System for Cross-Domain Identity Management (SCIM) standard.


Kaushik concedes that when it comes to replacing Active Directory, there is a lot of emotional resistance in the enterprise. For that reason, Identropy has made sure that SCUID Lifecycle is compatible with on-premise installations of Active Directory. But from a practical perspective, Kaushik says that in the age of the cloud it now makes more sense to manage application provisioning via a cloud service that can more easily adapt to new applications that are being unfurled on a cloud on an almost daily basis. That’s especially true, says Kaushik, when you consider the fact that going forward, the very nature of identity management across multiple organizations is going to require a federated approach. In fact, it’s that requirement that is driving a lot of the interest in being able to use, for example, LinkedIn credentials, to give people access to any number of cloud applications.

Kaushik says that obviously that “bring your own identity” approach may not work for applications loaded with sensitive corporate data, but for a lot of cloud applications that simply need to authenticate users before granting access, a credential validated by LinkedIn would be sufficient.

Clearly, identity management needs to evolve across the enterprise, which is one reason Microsoft has moved to host Active Directory on top of its Azure cloud platform. But in a world where Windows is no longer the dominant enterprise platform, approaches to identity management that can be more easily extended to cloud applications running on any platform may be worth some further investigation.

Add Comment      Leave a comment on this blog post
Jan 9, 2013 2:15 PM RB RB  says:
I am defining the provisioning processes for 90000 users moving to Google from Exchange and there is no chance the organization would entertain the thought of users registering in the cloud for services in the cloud. The element of risk is far to great that users will associate their private (or other) email addresses with those services and eventually find a backdoor to corporate data sitting on VMs, storage vaults, etc.. Our policy for provisioning all the users with the services they need in the cloud is through enterprise based IDM tools where full control of the provisioning logic and audit trails can be recorded. It is my firm belief that this hallowed ground in enterprises of the size I work for will never be allowed to be trampled on in the same way that mid-sized businesses may allow it because of cost considerations. Prove me wrong. Reply
Jan 10, 2013 1:19 PM Jim Jim  says: in response to RB
RB, You're implying that there are controls you could apply in the enterprise which could not be applied in a cloud service. You said that "the element of risk is far to great that users will associate their private (or other) email addresses with those services". I assume you mean you would restrict user accounts to only have email addresses in a certain domain. Why couldn't this be enforced in a cloud IDM tool? Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.