Managed Service Providers (MSPs) traditionally operate and maintain all or part of their customers’ IT services, including applications, operating systems, and networking infrastructure. They provide high-value services requiring technical knowledge and experience that their customers either don’t have or can’t afford. This includes managing availability and performance, keeping software up to date and providing the technical knowledge and experience to keep their customers’ IT services secure and available. MSPs have enjoyed a good return for providing these services, but that world is changing.

Business Challenges

The rapid growth of cloud-based software-as-a-service (SaaS) applications is putting the squeeze on the MSPs’ business. Where previously enterprise customers would purchase various office automation and line-of-business (LOB) applications and have MSPs operate them, they can now obtain equivalent applications in the cloud. These require little or no technical experience to install and operate. They provide reduced complexity, potentially better availability and performance, and are often cheaper than those delivered by MSPs. Customers assume that cloud-based SaaS apps are sufficiently straightforward to manage by themselves and that therefore they do not need the expertise of an MSP.

MSPs need to adapt to this changing environment in order to attract and keep customers. They need to leverage their technology expertise to deliver more value to their customers. A compelling way to do this is to add customizable, standards-based Identity-as-a-Service to their offering. This gives the MSP a way to generate more revenue, increase customer satisfaction, retain existing customers, attract new customers and creates a framework for new opportunities to provide additional high-value services.

Identity as a Service (IDaaS)

Cloud-based IDaaS services are a relatively new addition to the cloud SaaS world. Vendors in the market today typically provide capability in one of three areas: end-user social identity (Google), application-centric identity (Auth0), or enterprise identity (Okta, Microsoft, Onelogin). For an MSP serving enterprises, this last category is the most interesting.

Conventionally an enterprise-focused IDaaS offers a directory service, browser-based authentication (username and password-based login), integration with on-premises Active Directory, and single sign-on (SSO) to cloud-based SaaS applications. Just this basic capability provides substantial value to the customer. Identity data (users and groups) can be  managed by non-IT staff, and the ability to get single sign-on to their cloud-based applications improves the end-user experience, decreases help-desk calls, and reduces the security problems associated with having multiple usernames and passwords.

Why IDaaS for MSPs?

IDaaS has several characteristics that make it an excellent opportunity for MSPs, particularly for MSPs that are also providing private cloud and hybrid cloud (a combination of private and public cloud) services to their customers.

Demand – IDaaS is one of the fastest growing segments in cloud computing, with Gartner predicting a 55% compound annual growth rate (CAGR) and a total market size of $US 7.3 billion by 2019.

Security – Security continues to be the number one inhibitor of cloud adoption, and effective identity management is the foundation of security. By providing a secure, robust identity system for their customers, MSPs can address cloud security concerns and accelerate their customers’ migration to the cloud.

Value – Identity services are high-value. Simplifying end-user access to low cost cloud SaaS applications adds value while increasing end-user satisfaction and enhancing overall security. Adding user self-service functions adds further value by streamlining the password reset and application access request processes and therefore reducing IT help desk costs.

Revenue – IDaaS can provide a significant and reliable new revenue stream for MSPs. Vendors such as Okta, Microsoft and OneLogin offer IDaaS on a per-user/per-month basis with list prices ranging from $US 6 per user/per month. Added-cost features such as multi-factor authentication, mobile device integration, and automated identity provisioning can lift the list price to $15 per user/per month.

Stickiness – Identity is a fundamental component of security and application infrastructure, and properly implemented, provides a way to create and maintain long-term relationships with enterprise customers. Active Directory is a prime example of how sticky identity services are in the enterprise.

Service Opportunities – Because few enterprises will simply lift and shift their entire IT service catalog into the cloud, a hybrid (part on-premises, part in the cloud) environment will be the norm for most enterprise customers. This creates several high-value services opportunities for MSPs:

  • Reviewing existing identity systems and processes
  • Developing a modern cloud-focused identity strategy
  • Integrating on-premises identity services and applications
  • Developing and implementing customized identity data models and workflows

Reduce vendor lock-in – MSP managing SaaS applications for their customers risk losing them if they switch SaaS vendors - the customers may simply work directly with the old SaaS vendor. Providing the underlying identity services (including single sign-on) helps insulate MSPs and their customers from the effects of vendor changes, albeit that there may be a migration process.

Why Not Public Enterprise Identity Services Like Microsoft Azure or Okta?

There are several vendors providing capable IDaaS solutions in the public cloud that are mature and relatively easy to set up and use. While for many customers these services provide a workable approach, identity is a service where one size does not fit all, and your customers may be better served by a privately hosted IDaaS solution for various reasons, including:

Regulatory or corporate policy requirements – Many organizations simply can’t put their sensitive identity information in the public cloud, either because of corporate policy or government regulations. These customers may need complete control over the geographic distribution of their identity data, or may simply need dedicated infrastructure. MSPs can address both of these concerns by hosting IDaaS in their own data center.

Better performance – Public cloud identity services are designed to meet the needs of a huge number of concurrent users while using the minimum possible amount of computing resources in a handful of globally distributed data centers. This means that most customers will receive adequate, but not great performance. By hosting IDaaS in their own data centers, MSPs can provide reduced latency and better performance to those customers who need it.

Flexibility and customizability – In order to achieve the scalability they require to be profitable, public IDaaS providers need to reduce identity to the lowest common denominator. But, although identity is a core software infrastructure service, it is not a one-size-fits-all proposition. Beyond simply adding attributes to a user object, enterprises often need to model organizational structures, projects, and cross-organizational relationships that can’t reasonably be represented by a simple users-and-groups identity model. MSPs can provide this additional customizability when they host IDaaS services for their customers.

What Should MSPs Look for in an IDaaS System?

Customer-oriented features – The most important aspect of any IDaaS system is the set of identity services it provides to your customers. At a minimum an IDaaS system should provide a cloud-based directory service, the ability for end-users to login (authentication) and single sign-on to cloud-based SaaS applications. In addition, it should also offer add-on services, configurable on a tenant-by-tenant basis, including:

  • Multi-factor authentication
  • Self-service password management
  • Integration with on-premises identity systems like Active Directory
  • Fine-grained, policy-based authorization services
  • Provisioning and synchronization of identities to applications both in the cloud and on-premises
  • A customizable data model allowing each tenant to define new attributes and new classes of object
  • Customizable workflows to support on-boarding, off-boarding, access requests, and other identity-related processes

Multi-tenanted – It is not uncommon for software developers to install their traditional single-tenant enterprise application software on a cloud-hosted virtual machine and call it “cloud”. Each customer gets a new virtual machine and a new copy of the software. This approach completely negates the cost and efficiency advantages of computing in the cloud, and it creates a huge administrative burden on the operator to boot. It is critical for a cloud identity platform to be architected from the ground up as a multi-tenant service, leveraging common software infrastructure to increase efficiency and reduce costs.

Standards-based identity services – The IT industry through its various standards bodies such as the IETF and OASIS has invested significant effort to define standard identity-related protocols that are effective, secure and work well on the public internet. These protocols have been heavily reviewed and vetted by experts, and have broad support from application developers and programming tools. Any system that uses proprietary protocols is likely less secure, and certainly more difficult to integrate and support.

Integrated out of the box – Some identity software vendors provide an entire suite of products and leave it to the MSP (or their consultants) to build a custom system. The problem with a made-to-order system like this is not primarily that it takes longer to implement (which it does), but that it is a one-off. Every time the vendor upgrades one of their products, the MSP has to go through the potentially risky process of upgrading pieces of the system. If business requirements change, all of the custom scripts and integration modules may need to be rewritten. And if a new group of consultants to update the system, the MSP has to pay for their learning curve. A complete product that is integrated out of the box suffers from none of these disadvantages.

Comprehensive API set – Identity is a platform service, meaning that it is consumed not just by end-users, but by other applications as well. Exposing all of the platform’s capabilities, including configuration, through a set of web APIs makes the platform easier to extend and integrate with other applications. A complete set of APIs also makes the identity platform easier to automate, which can significantly reduce operational costs.

Self-contained – There are many platform services available from public cloud vendors that allow cloud application developers to create cloud-based applications faster, cheaper, and more reliably. Amazon Web Services (AWS) for instance provides more than 70 such services, and adds new ones every few months. It is tempting for application developers to use these services whenever they can. But any MSP, and particularly MSPs implementing private clouds, should think carefully before accepting such external dependencies. Most of these platform services are charged for on a per API-call or per-MB basis, which creates a substantial hidden operating expense that is beyond the MSPs ability to control. Further, customers who are concerned about the privacy and sovereignty of their identity data will certainly not want their identity data leaked to external service providers with whom they have no contractual relationship.

Customizable on a tenant-by-tenant basis – As covered earlier, enterprise identity is not a one-size-fits-all service. Each customer will need at least some level of customization to support their own needs. The areas that most need customization by enterprises include the ability to:

  • Add new attributes to objects like users and groups
  • Add new kinds of objects, like departments and projects
  • Create new relationships between identity objects
  • Extend the role and permissions models
  • Insert and customize workflows into identity operations
  • Define and customize the production of reports
  • Source and transform identity data from other cloud or on-premises systems, including Active Directory and HR applications
  • Target and transform identity data to other cloud and on-premises systems

Scalable, robust, and efficient cloud architecture – Cloud service architectures need to support scaling both vertically to support large tenants, and horizontally to support more tenants and higher transactional loads. Cloud services need to replicate critical identity and configuration data in multiple locations to mitigate the risk of a virtual machine or disk failure causing data loss. And finally, cloud services need to be efficient to minimize operating costs.

Easy to install and operate – As a rule, MSPs have competent network operations people on staff who are fully capable of installing, configuring, and operating complex enterprise applications. But even so, it is still important for a cloud identity service to be easy to setup and operate and it should automate (or support the automation of) most common administrative tasks. For instance, adding a new tenant should be a simple API or command-line exercise and not require administrators to manually provisioning new virtual machines or configure load-balancers except in extraordinary circumstances. A cloud identity service should also expose performance and debugging information that can be consumed by common cloud management tools to enable operations staff to monitor and manage the service with little additional effort.


In this whitepaper we’ve described some of the business and technical challenges that MSPs face from cloud SaaS applications, and how adding Identity-as-a-Service (IDaaS) can be a high-value addition to an MSP’s application portfolio. We’ve also shown how privately hosted IDaaS can solve the problems some organizations have with moving their identity services to the cloud. Finally, we’ve identified some of the key functions and characteristics of an IDaaS solution that MSPs should look for.

Cobalt Cloud Identity

Cobalt Cloud Identity from ViewDS Identity Solutions is a software package for MSPs that answers these challenges. Cobalt is a multi-tenant cloud identity platform that an MSP can install and run in its own data center or in the public cloud infrastructure-as-a-service (IaaS) environment. It has been designed and built specifically for the cloud. It consists of a comprehensive and evolving standards-compliant identity and access management capability. It is built on proven, globally-deployed, identity server technology that has architectural advantages for cloud applications.

It encompasses the four capabilities required to deliver an IDaaS platform:

  • An identity store. This holds details of identities together with their entitlements.
  • Authentication. The ability to recognize and authenticate a user.
  • Authorization. Enables the system to determine what a user can and cannot do.
  • Integration. The ability to synchronize information with external (to Cobalt) systems.

Gil Kirkpatrick, CTO, ViewDS Identity Solutions

Recently I was asked to integrate our Cobalt Identity Server with Office 365 (O365) using SAML 2.0 for web SSO. I managed to get everything working in the end but not without some confusion and frustration along the way. This post attempts to capture the issues that I encountered and provides a straightforward step-by-step guide to configuring O365 to use SAML SSO, which I hope might help others attempting to integrate O365 with an external SAML IdP.

The main document that I referred to came from Microsoft MSDN and is called “Use SAML to Implement Single Sign-On”. I also referred to some MSDN PowerShell cmdlet pages to learn more about how they should be used.

I must confess that prior to this integration with O365, I had done SAML SSO integration with other Service Providers (SPs), including Salesforce. However, I had fairly limited experience with Microsoft product integration. My lack of Microsoft-specific product knowledge (things like PowerShell and ADFS) may explain why I had trouble with the integration. But I have a sneaky feeling that the MSDN documentation itself is a little misleading or at least is missing a few crucial steps. Hopefully this document will fill in those gaps and provide a complete description of how to get O365 working with an external SAML 2.0 IdP.

The tasks that must be performed include executing numerous PowerShell cmdlets, verifying the registered domain by making changes to its DNS records, creating and configuring an application on the IdP side, and optionally, creating a sample user in Azure AD for testing purposes.

Before you get started you should ensure that you have the following prerequisites:

  • An administrator account for Office 365
  • A domain name that you own
  • Windows PowerShell with the Azure AD PowerShell module installed

Connect to Windows Azure AD using Windows Powershell

Open Windows Powershell 4.0 and make sure the module Windows Azure Active Directory has been installed (see the prerequisites listed above). Run the following command to connect to Windows Azure AD using your Office 365 administrator account.

PS C:\> Connect-MsolService

Verify your domain in Azure AD

Verifying your domain is a one time task; it basically confirms to Azure that you have administrative control of the DNS domain. Unless you plan to use a different domain in Azure AD, you will not need to perform this again in most situations. For the purposes of this guide, assume you own the domain “”.

  1. Add the domain that you own to Azure AD.
  2. PS C:\> New-MsolDomain -Name -Authentication Federated

  3. In order to confirm ownership, Microsoft requires the domain owner to add a custom TXT DNS record for the domain to the domain server. This command is used to retrieve details of the DNS record that must be set.
  4. PS C:\> Get-MsolDomainVerificationDns -DomainName -Mode DnsTxtRecord

  5. Once the DNS record has been added to the domain server, you need to execute the Confirm-MsolDomain command, along with its mandatory parameters, in order to confirm ownership of the domain, as well as set up the federated domain.
  6. PS C:\> $domainname = ""
    PS C:\> $logoffuri = "https://localhost:9900/login/" # Landing page when user logs out
    PS C:\> $passivelogonuri = "https://localhost:9900/identity/saml" # Identity Provider SAML HTTP-POST endpoint
    PS C:\> $cert =
    "MIIEWTCCA0GgAwIBAgIJAJk28/BKoqaCMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkFVMTYwNAYDV QQKEy1lTml0aWF0aXZlcy5jb20gUHR5LiBMdGQuLCBBQk4gMTkgMDkyIDQyMiA0NzYxFDASBgNV....... ...I1hKLFfsiQgSfjGsQNcbNEAuF6DEb8LWhzZ34s7Qd/c5pjfCOAUGPTKIOOz5es2mPngwe5dl6355Z22 yTAaYjpQq92Pyjs7gJ0DCw+Quct5gos3Tw2be3aG6+KOcmtNB91AF/39qvS0jA8bWQGVi9jVaYSC/Fu/IH CoHGBi/Y8F5j3zBQhxn7Zz5cspcVYfF3yYz2dB8J1Fm6YbFGc4kNO2zTR5bw/c3aA7nlK5B8KWGJTfSFg==" # Server certificate, pem file. Remove spaces and newlines
    PS C:\> $issueruri = "https://localhost:9900/identity/saml" # Issuer URI set by your Identity Provider
    PS C:\> $protocol = "SAMLP" # To ensure domain uses SAML SSO

    PS C:\> Confirm-MsolDomain -DomainName $domainname -IssuerUri $issueruri -FederationBrandName $domainname -LogOffUri $logoffuri -PassiveLogOnUri $passivelogonuri -SigningCertificate $cert -PreferredAuthenticationProtocol $protocol

Issues: Firstly, I realized that I had to provide more arguments than were indicated in the MSDN Confirm-MsolDomain page ( As a minimum, -IssuerUri, -LogOffUri, -PassiveLogOnUri, and -SigningCertificate were required to get this cmdlet to execute successfully, rather than just the -DomainName that the documentation suggests. Secondly, spaces and newlines in the PEM certificate had to be removed. It took me a while to figure all this out and I can’t remember the exact error message but I recall complaints about an invalid value for parameter federationSettings, which I had not provided.

Configure the domain in your Office 365 for federation

The following cmdlet is provided by Microsoft MSDN for configuring SSO with a third party IDP. You might notice that the parameters are identical to the ones used to verify the domain in the previous section.

PS C:\> $domainname = ""
PS C:\> $logoffuri = "https://localhost:9900/login/" # Landing page when user logs out
PS C:\> $passivelogonuri = "https://localhost:9900/identity/saml" # Identity Provider SAML HTTP-POST endpoint
PS C:\> $cert =
"MIIEWTCCA0GgAwIBAgIJAJk28/BKoqaCMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkFVMTYwNAYDVQQKE y1lTml0aWF0aXZlcy5jb20gUHR5LiBMdGQuLCBBQk4gMTkgMDkyIDQyMiA0NzYxFDASBgNV..........I1hKL FfsiQgSfjGsQNcbNEAuF6DEb8LWhzZ34s7Qd/c5pjfCOAUGPTKIOOz5es2mPngwe5dl6355Z22yTAaYjpQq92P yjs7gJ0DCw+Quct5gos3Tw2be3aG6+KOcmtNB91AF/39qvS0jA8bWQGVi9jVaYSC/Fu/IHCoHGBi/Y8F5j3zBQ hxn7Zz5cspcVYfF3yYz2dB8J1Fm6YbFGc4kNO2zTR5bw/c3aA7nlK5B8KWGJTfSFg==" # Server certificate, pem file. Remove spaces and newlines
PS C:\> $issueruri = "https://localhost:9900/identity/saml" # Issuer URI set by your Identity Provider
PS C:\> $protocol = "SAMLP" # To ensure domain uses SAML SSO

PS C:\> Set-MsolDomainAuthentication -DomainName $domainname -FederationBrandName $domainname -Authentication Federated -IssuerUri $issueruri -LogOffUri $logoffuri -PassiveLogOnUri $passivelogonuri -SigningCertificate $cert -PreferredAuthenticationProtocol $protocol

Issues: I am not entirely sure why this command duplicates all the arguments from the previous cmdlet. There may be sound reasons for this from an implementation perspective or there may not be but in any event, I did not have time to mess around with the cmdlets and arguments to investigate further, so I decided just to run it anyway. In fact, I had to run it to get things working.

Tip: If for any reason you want to change the parameters that you configured previously, you can use the Set-MsolDomainAuthentication cmdlet but change the value of -Authentication to "Managed", then change it back to "Federated" with new values. You may find that the Microsoft MSDN documentation suggests using Convert-MsolDomainToFederated and Convert-MsolDomainToStandard to do this but AFAIK they are both ADFS-related cmdlets and hence not really relevant, as our goal here is to use an external IdP that isn’t ADFS.

Create a user for testing

The ImmutableId used here must match a user’s unique identifier in your IdP. And we must provide this unique identifier as the value in the NameID element in the SAML assertion.

PS C:\> New-MsolUser -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. -ImmutableId 2e28f6ce-4e3b-4538-b284-1461f9379b48 -DisplayName "John Doe" -FirstName John -LastName Doe -AlternateEmailAddresses "This email address is being protected from spambots. You need JavaScript enabled to view it."

Assign license to the user

A license should be assigned to the test user, so they can access O365 apps.

  1. To check if a user is licensed
  2. PS C:\> Get-MsolUser

  3. To check if you still have licenses available
  4. PC C:\> Get-MsolAccountSku

  5. To assign a license to a user. Assuming the license is "companyDom:O365_BUSINESS_ESSENTIALS"
  6. PS C:\> Set-MsolUserLicense -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. -AddLicenses companyDom:O365_BUSINESS_ESSENTIALS

Additional commands that might be useful

Check if the domain is Federated enabled.

PS C:\> Get-MsolDomain

Get the federation settings of a domain. Retrieve everything.

PS C:\> Get-MsolDomainFederationSettings -DomainName | Format-List *

Configuring an app in the identity provider

Defining the app (or service provider, SP) in your IdP is the final stage in the integration. Really what we are doing here is configuring the IdP so that it sends a SAML assertion that can be consumed sensibly by Azure AD.

Key things that are worth pointing out when configuring the app for Azure AD in your IdP:

  • Because Azure AD publishes and consumes AssertionConsumingServiceIndex, the app needs to be configured to recognize Azure AD AssertionConsumingServiceIndex and map it to its callback URL. The callback URL is the HTTP-Post binding URL found in the Azure AD’s metadata.
  • Azure AD's entityID is "urn:federation:MicrosoftOnline" (see Azure AD’s metadata).
  • Azure AD expects the IdP to provide an extra attribute with the name "IDPEmail" in the SAML Assertion that will be used to map the federated identity in Azure AD (see Use SAML to implement Single Sign-On).

Below is a sample of the Azure AD app configuration that I registered with the ViewDS Cobalt IdP. Critical information is highlighted in bold while the format is irrelevant in this context.

    "name" : "Azure AD",
    "type" : "RS256",
    "identifier" : "urn:federation:MicrosoftOnline",
    "entity" : "urn:federation:MicrosoftOnline",
    "secret" : "********",
    "callback" : [{
       "index": 0,
       "location": ""

    "duration" : 3600,
    "samlAttributeConsumingService" : [{
       "index" : 1,
       "default" : true,
       "name" : "Azure AD",
       "description" : "Azure AD with Cobalt",
       "attributes" : [{
          "name" : "IDPEmail",
          "nameformat" : "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified",
          "attribute" : "mail",
          "required" : true


Including the right email address in the SAML assertion

Note (from Use SAML to implement Single Sign-On)

The “UserPrincipalName” value must match the value that you send for “IDPEmail” in your SAML 2.0 claim and the “ImmutableID” value must match the value sent in your “NameID” assertion.

In this example, domain “” has been configured in Azure AD as the federated domain. Therefore, you must ensure that the SAML assertion being constructed in your IdP includes a user email with that domain. The reason being that Azure AD is only able to match the user in its directory using an email attribute with that domain (and NameID) in the SAML assertion.

- This email address is being protected from spambots. You need JavaScript enabled to view it.

Verifying SAML connectivity

One of the simplest and quickest ways to verify that single sign-on has been set up correctly is to attempt SP-initiated login to the Office 365 Portal.

  1. Access the Office 365 Portal.

    A login screen is displayed.

  3. Provide the user’s email address on the Office 365 login screen.
  4. This email address is being protected from spambots. You need JavaScript enabled to view it.

  5. If your external IdP has been setup correctly on the Azure AD side, then you will be redirected to the external IdP’s login screen. Provide the appropriate login credentials on the external IdP’s login screen.
  6. Once the correct credentials have been provided, the external IdP will send a SAML assertion (that contains attributes and the ImmutableID) to Office 365 and redirect the browser to the Office 365 Portal in a logged-in state. This indicates that external authentication has worked successfully.
  7. If Office 365 login is unsuccessful, then an error code will be displayed. Should this happen, you can use the Microsoft MSDN documentation to identify the meaning of the error code and help troubleshoot the problem.


In conclusion, the procedures are not too technical after all, once you get past the misleading documentation. Of course, understanding what needs to happen at different points in the exercise is crucial and I do hope that this article has provided clear guidance about how to implement your external Identity Provider with Azure AD. Finally, one other resource that really contributed towards the success of my implementation was the document by the third party Identity Provider Salesforce. I used it to verify the PowerShell cmdlets I was executing contained all the mandatory parameters and the correct values.

Edward Sia - ViewDS

Over the past 20 years we have learned how to architect and manage identity and access management for our on-premises applications. And what is the most important lesson we have learnt? That identity and access management cannot be left to the application but must be centralized in a system designed and securely built for that purpose. Although identity and access functions in the cloud are the same - directory, authentication, authorization, and audit - the mechanisms are entirely new.

Here are 7 reasons why cloud identity is different:

1. Accessibility

Probably the most important motivation for moving applications to the cloud is to make them more accessible to people outside the corporate firewall and outside the company. Expanding the reach of an application to new user populations requires rethinking the conventional on-premises approach to identity.

On-premises identity services exist to provide strict control over access to applications inside the corporate firewall. In the typical on-premises environment a new user has to go through several steps to use an application. First, the IT department creates an account in Active Directory (and possibly other systems). Then the user gets approval to use the application. After that, IT adds the user to the appropriate groups and maybe even installs the software on the user's computer. All these steps ensure that IT maintains control over who can use the application.

The purpose of cloud-based identity systems is more or less the opposite. They traverse network and security boundaries, integrate with external identity systems and make the application easily available to people inside and outside the organization, all with little or no input from IT. Users can sign up for the application using just their email address and use a social network identity (such as Facebook or Twitter) to authenticate. In the cloud, users define and control access to their own identity information. IT is not involved.

2. Scalability and performance

Scalability and performance requirements are very different in cloud applications. Some cloud identity systems (such as Facebook) handle billions of user accounts. Other cloud identity systems (like Azure Active Directory) provide hundreds of millions of authentication transactions per day. This is sort of scale is not the norm for on-premises identity systems and handling it requires careful attention to product architecture.

3. Efficiency

Related to scalability and performance is efficiency. Almost all Active Directory systems use dedicated servers as domain controllers, for both security and administrative reasons. So, once you have purchased a server, there are essentially no ongoing costs. Whether that domain controller uses 10% of the CPU and 5GB of RAM or 80% of the CPU and 10GB of RAM makes no difference to your bottom line. Purchasing virtual machines in the cloud is different. Because you are paying more per month the more computing resources you use, the efficiency of your cloud identity system actually affects your monthly bill.

4. API support

Cloud-based identity systems need to support a different set of application programming interfaces (APIs) than their on-premises counterparts. On-premises identity systems, like Active Directory, use LDAP for directory access and Kerberos for authentication and authorization. However, the cloud environment requires protocols that are stateless, can recover from connection failures seamlessly and can traverse firewalls and load balancers with no additional configuration. So, cloud APIs are based on HTTP/S and use a Representational State Transfer (REST)-ful model. Consequently there are a new set of identity protocols based on HTTP/S that provide equivalent identity functions to on-premises systems: OData and SCIM for directory access, OpenID Connect for authentication, and OAuth 2 and the XACML 3.0 REST/JSON profile for externalized authorization.

5. Multi-tenancy

The concept of multi-tenancy is the ability to segregate sets of identity data from each other, usually along organizational lines (think of a cloud service with multiple enterprise customers, something like SalesForce). This concept is not required in on-premises enterprise identity systems because they are inherently single tenant solutions. But cloud service providers have to maintain strict separation of the identities associated with their different enterprise customers, so cloud identity systems must be able to support that.

6. Identity data model

The cloud identity data model for applications is often more complex than that of a typical on-premises identity system. The on-premises model is generally pretty straightforward: there are some organizational structures (for example OUs in the directory) that represent different business units or departments, there are users and computers whose lifecycle is controlled by IT, and there are groups (possibly nested) that enumerate users with certain rights. And that is pretty much it. Whereas, cloud identity systems, particularly consumer-facing or externally-facing cloud identity systems, must model a more complicated ecosystem of identity information including users, organizations or tenants (and possibly tenants of tenants), a sophisticated relationship of applications, roles, and permissions, and trust relationships with external identity providers and consumers. Add on top of that the notion of social identity, for instance which products does the user like, which users like the same product, etc. and you can see that the cloud identity model is pretty complex.

7. Security and privacy

Finally there are the security and privacy issues. If you are a cloud service provider maintaining identity information for your customers or an enterprise storing identity data for your corporate employees and partner organizations, then you have the moral and legal responsibility to maintain that data securely. But at the same time you want to give your users maximum flexibility in defining who can access that information and under what circumstances. It goes without saying that passwords should be hashed and encrypted before being stored on disk, but so should other personal information like social security numbers, credit card and bank details. In addition, the identity software you use has to be bullet-proof to prevent hackers from compromising your system, your users' personal information, and potentially external systems as well.


Even though cloud identity systems have to provide the same basic functions (identity, authentication, authorization, and audit) as their on-premises counterparts, cloud identity really is quite different.

ViewDS develops Cobalt, a set of identity and access management components for the cloud. To find out more about how Cobalt can help you to secure your cloud applications contact us today.

Write Your Own Cloud Identity System

Probably the most common approach to developing identity infrastructure for cloud applications is to build something yourself. Using a combination of custom code and freely available open-source components it is possible to build a basic functioning identity system fairly quickly. However such identity solutions rarely work well in the longer term for a number of reasons.

Firstly, you must build your cloud identity system so it will scale as your user base grows. Identity systems are by nature very read-heavy, generating several hundred times the number of read operations as write operations. (Think of the number of times you login compared to the number of times you update your details.) And identity updates are usually very localized, requiring at most the update of one or two objects. SQL databases and the object-relational mappers (ORMs) used by many web application platforms are optimized for an entirely different kind of workload, where many rows in many updates are updated together in a single transaction. Configuring and managing the SQL partitioning and replication so that your application can reliably and efficiently serve a global audience is also highly specialized knowledge.

Second, cloud identity technology itself is complex. Implementing even basic username and password authentication properly requires specialist knowledge. Get it wrong and your applications are left vulnerable to bugs, the inadvertent disclosure of potentially sensitive information or even the theft of your data

And finally, identity requirements change as applications mature. The first version of your cloud application might only need a username, password and email address. However, version two might require links to social media, profile and preference information, contact details, roles and relationships with other identities and for version three you might want role-based access control to resources and user-based consent to personal details. Redesigning your identity system every time you have a new requirement is expensive and prone to error. On the other hand, trying to design an identity system that can accommodate all possible future requirements will most likely result in over-elaborate and extraneous code that you must test and maintain. And every time you add a new feature to your application, you must modify your identity system to support the appropriate authorization policies for that feature.

So, although it is fairly easy to use your application platform to build a rudimentary identity system, building an identity system that will evolve and grow to support your changing application requirements is a substantial investment, and a substantial risk.

Use a Cloud-based Identity Service

An alternative approach to providing identity infrastructure for your applications is to use a cloud-based identity service. There are a number of different service providers out there including the big cloud application development platforms such as Microsoft's Azure Active Directory, Google, and Salesforce and smaller specialist identity as a service (IDaaS) providers like Okta, Ping, and Onelogin.

Using a hosted service has a number of advantages over building your own identity system. Such services are generally well designed and implemented, they support common identity standards, provide a robust, reliable and scalable service and they are 'just there'. You don't have to manage any additional cloud infrastructure to support your application’s identity needs.

However, there are some significant downsides to using such service providers. First, you lose control of your identity information. Instead of storing sensitive identity data on servers that you control and administer, you store it on servers controlled by a third party. This might not be a big deal. The public identity services may very well have stronger security controls and administration processes than you do. But your legal or security requirements may prohibit letting sensitive identity information out of your control, or allowing it to be handled by a foreign enterprise subject to a foreign government's privacy and disclosure rules.

Another potential problem with public cloud identity services is their relative inflexibility. These providers have created infrastructure capable of supporting identity on a large scale, but they have traded off features and configurability that might be important for your applications. For instance, some identity services provide only a fixed identity schema. If you need to store additional attributes with your identity data, you must implement your own parallel identity store.

However, the real problem with committing to a public identity service is vendor lock-in. Once you have stored all your identity data with a particular service and written your applications to work with the particular features and quirks of that vendor's system, it will be very difficult to move your application to a different identity infrastructure. You have effectively locked your applications to the vendor's identity infrastructure and you will be subject to whatever service, feature, and cost changes that vendor decides to make in the future. So, while you enjoyed agility at the start of your project by leveraging an existing service, you have basically given up that agility for the life of your application.

Use Packaged Identity Software

The final approach to providing the identity infrastructure for your applications is to use packaged cloud identity software. This is essentially an extension of the software model used with Active Directory for on-premises identity. You must provide the hardware (virtualized or otherwise) and operations manpower but the software itself is complete and ready to deploy after some basic configuration.

The packaged software approach has a couple of disadvantages. It requires setup and configuration on your part, so it is not 'just there' like a public identity service. Depending on the cloud software package you choose, this might be a significant effort or not. Although once you have worked it out, your cloud automation software can handle subsequent installations. Then there are the ongoing operational costs. Not only do you have to manage your cloud applications, you also have to manage the identity software as well. Although once again, this can be largely automated, so the incremental costs should be small.

On the other hand, there are several substantial advantages to using packaged software for your cloud identity needs. You get a richer feature set and more configuration flexibility. So, instead of having to shoehorn your application identity into a one-size-fits-all identity data model, you can tailor your data model to suit your needs. And you remain in control of your identity data. You control where it lives, how it is managed, and how it is accessed. This means that you can be sure that your identity data is secured according to your requirements, not according to those of a third-party or foreign government. Finally, and most importantly, you are not locked into a service providers feature set or pricing model.


Cloud identity management is a totally different beast than on-premises identity management and the software you need to create your application's identity infrastructure has to be designed and built with cloud requirements in mind. Building your own cloud identity infrastructure is almost never a good idea. It is far safer and more efficient to let your application developers focus on the features of your application and to leverage the expertise of identity specialists for your identity infrastructure. Taking advantage of a cloud identity service can be an effective approach, particularly when you are just starting out, but has significant downsides in terms of control, flexibility and vendor lock-in. Using packaged identity software for your cloud application's identity needs does require that you deploy and manage the identity software along with your cloud application, but has several significant benefits including a richer feature set and increased control over your identity data, as well as the fact that you are never locked-in to a third-party's pricing model.

ViewDS develops Cobalt, a set of identity and access management components for the cloud. To find out more about how Cobalt can help you to secure your cloud IAM applications and its security featurescontact us today.

If you are in business and make use of IT, then the recent PricewaterhouseCoopers (PwC) UK 2015 Information Security Breaches Survey makes for alarming reading.

Data breaches are now almost inevitable, with 90% of large businesses and 74% of small ones reporting at least one. And the cost of those breaches is soaring.

The average cost to a large organization this year is in the range 1.46 to 3.14 million GBP (2.92 to 6.28 million AUD), more than double last year’s figures. For small businesses things are not much better, with the average cost of a breach running at between 75,000 and 311,000 GBP (150,000 to 622,000 AUD). Factor in the reputational damage that often occurs and things can be even worse - 11% of those surveyed had to change the nature of their business as a result of their worst breach.

The survey also suggests that adopting new technology can introduce new risks, with large organizations reporting that 13% of breaches were related to social networking sites, 15% involved mobile devices, and 7% affected their cloud computing services.

But it seems that the benefits of new tech outweigh the costs, as the use of mobile devices and cloud computing in particular, continue to rise. The 2015 Cloud Computing Trends: State of the Cloud Survey indicates that 88% of enterprises are using the public cloud but there is still plenty of scope to increase the cloud workload, with 68% of enterprises currently running less than a fifth of their applications in the cloud.

Against this backdrop it is more important than ever to ensure that your cloud applications - and the underlying identity data they use - are safe and secure. And the best way to do it is to use purpose built cloud identity infrastructure that employs the latest secure identity protocols.

ViewDS develops Cobalt cloud identity components, a set of easy-to-deploy identity and access management components for the cloud. To learn more about Cobalt's security features and how our identity solution can help you secure your cloud applicationscontact us today.

The first, and arguably most important component of your cloud identity system is the identity and attribute store. It forms the heart of any identity system, whether it be a cloud-based or on-premises application. So what should you look for in a cloud identity store? Here are 13 questions we think you should be asking:

1. What sort of data model does it support?

The data model defines the kinds of information you can store in the directory, the ways the data items can relate to each other, and the operations your applications can perform on them. It is the most critical aspect of the identity system. A simple identity data model might include only the notion of user. A sophisticated data model includes things like organizations, departments, roles, user types (such as customer, employee, or contractor) and various possible relationships between them. Many identity service providers a very simple model with little ability to customize it. An unchangeable, simplistic data model will require you to add parallel data structures to you application to support the data and features your cloud based application will require as it matures .

2. Does the cloud identity store have a flexible and extensible schema?

Related to the data model itself is the extensibility of the data model through a schema. Some systems, even though they have a sophisticated data model, don't allow for any extensibility. If your application's identity needs change over time, you don't want the identity system's lack of extensibility to hold you back.

3. What types of data does it support?

Beyond just supporting an extensible schema, the cloud directory needs to natively support different types of data. In addition to basic strings and numbers, the directory should support constraints on the data to ensure that the data being stored is consistent with what the application expects. It is much more efficient to ensure that the data stored is correct than it is for every application to check the data before it tries to process it.

4. Is it easily searched?

A frequently overlooked capability of cloud directories is the ability to search for identity information easily. The directory is not just a store for authentication; it is essentially a catalog of the users, applications, and devices that use it. Providing a way for people to easily and reliably find this information is really important.

5. Is the cloud identity system multi-tenanted?

Many cloud service providers require a multi-tenant identity system that allows for the creation of tenants that serve as containers for their identity information. The identity system must keep tenants isolated from each other, and provide each with separate administration and configuration. It is extremely difficult and error-prone to graft a multi-tenant model on an identity system designed for a single tenant.

6. What sort of APIs does it expose?

The SCIM (System for Cross-domain Identity Management) API is a relatively new standard for identity systems and is gaining traction for simple provisioning of users. OData (Open Data Protocol) is a comprehensive data access API suitable for almost any kind of data, including identity data. It has a rich relationship model and is completely extensible. Standard APIs such as SCIM and OData have extensive support libraries for different application platforms. Beyond that, most cloud directory services expose a custom, HTTP/S-based API of some sort.

7. Does it support replication and geo-redundancy?

Cloud applications usually have a 24-by-7 global access requirement that most on-premises don't have. To support this, the cloud identity system must also be globally available, 24-by-7. The identity system must have built-in redundancy of components, as well as data replication to place identity data near where it is used.

8. How is access to directory data controlled?

It's not enough to rely on web applications to determine who has access to what in the directory. Regulatory requirements, security and privacy policies, and user consent all require authorization policies that must be enforced regardless of the application. The directory has to provide its own layer of authorization policy over and above the policies implemented by the applications.

9. How is sensitive data secured on the cloud identity system?

Access to sensitive identity data (usually things like personally identifiable information, account numbers, and other personal details) needs extra layers of security. It's no good authorization policies control access through the applications and attackers simply steal the directory data out from underneath the application. Sensitive directory data needs to be encrypted on disk as well.

10. Does it support publish/subscribe APIs?

Even though the directory is the most critical component of any identity system, it traditionally plays a completely passive role in the overall application architecture. Applications treat it as a database, and unless an application asks for information, the directory does nothing. Cloud identities are highly dynamic with new users signing-up, tenants coming and going, users creating new access control policies, enterprise administrators associating users with roles, and so on. Rather than relying on applications to somehow discover what has changed, a cloud directory needs to provide an easy way for applications to learn about changes in the directory that they are interested in, and this is what a publish/subscribe API provides.

11. Does it support human, organization, application, and device identities?

Cloud identity is not just about users; any entity that can access digital resources needs an identity, including applications, devices, and organizations. Further, the directory needs to be able to represent the relationships amongst these entities so that applications can apply the appropriate policies to resource access.

12. How well does it scale up to the number of identities you need to support?

Another characteristic of cloud identity systems is the large number of identities they have to support. 100K identities in an on-premises systems like Active Directory is a big number. Cloud identity systems frequently deal with tens or even hundreds of millions of entries. The directory has to be designed to accommodate these sorts of numbers while still providing fast authentication and lookup times.

13. How does it handle scale out for performance, redundancy, and geo-location?

Cloud identity systems need to scale out (and in!) to satisfy changing performance requirements. The directory has to support spinning up additional instances so that they can serve more authentication and authorization requests, and so that they can place service instances near the clients making the requests.

To learn more about ViewDS' Cobalt cloud identity components or for more information about cloud identity systems, contact us today!