In my last blog post I mentioned how Service Providers face a different set of challenges than Identity Providers as they roll out federated identity technology for customers. In this post, I’ll elaborate on those challenges and share best practices to address them.
As I’ve said previously, identity is fundamentally an integration challenge. If you’re a Service Provider, you likely have customers with varying degrees of sophistication in their identity technology. You’re likely asked to integrate your identity functions (Authentication, Authorization, Provisioning, Audit) with that of your customers in order to provide them with more visibility and control into user activity while providing their users with a seamless experience. Because you sell your services to different types of organizations, you need to be prepared to integrate your identity functions with different types of identity systems.
Here are four broad categories of the customers you’re likely to integrate with today, and their preferred style of integration:
Most larger companies (think Fortune 500-1000) have already invested in Identity and Access Management (IAM) technology and expect their SaaS vendors to interoperate with the standards-based interfaces those IAM vendors provide. Over the last couple of decades IAM vendors have come together to create interoperable standards like SAML to enable this very use case and have convinced enterprises that this is the best approach for integration. If you’re selling to a large enterprise, you need to support a SAML-based authentication scheme in order to have the best solution for those customers. This enables a seamless experience for their users who can then access multiple web and SaaS applications while only having to authenticate once.
Most companies that haven’t yet invested in IAM technology are leveraging Microsoft’s Active Directory (AD) as the primary way that they manage their list of application users and have built procedures for maintaining it. When a person joins the company, he or she gets an account in AD and that gives them access to some of the systems they need. When he or she leaves the company those procedures ensure that the account is removed from AD. These companies want to extend the reach of their AD out to their cloud applications. While Microsoft provides a component called Active Directory Federation Services (ADFS) to SAML-enable AD, the reality is that most midsize companies lack the expertise required to deploy ADFS and integrate it with their partners. So these companies need you to work with Active Directory directly using a “delegated authentication” scheme – whereby a SaaS provider makes a web service call on the company’s infrastructure to validate the username and password when the user logs into their app or service. This enables users to type in the same username and password for SaaS applications that they use for logging into their own company’s network. In this scenario, the SaaS application will see (and have the opportunity to collect) user passwords and is generally considered a less-secure approach than what is enabled by standards.
Most small companies do not have an electronic system like Active Directory maintained with current information about their employees. In this case, you must provide that company with a user administrator account that allows them to manage the list of users who will be accessing that app or service for their company. As a result, end users have different usernames and passwords stored within each of the applications – leading to poor password practices like writing them down on a mouse pad, or using the same password across multiple sites.
In some cases small companies may use a SaaS provider like Google or Workday, and those providers become the de facto employee user repository. To the extent you can leverage these third parties to authenticate customers’ users, you can make your services easier to adopt by the small company and its end users.
Individuals often have existing accounts on social media sites like Facebook and Google when they sign up for a new service. In many cases those users would like to leverage that existing account rather than create a new one in the new service. You must be able to give these users the option of leveraging their social identity or creating a new account when they join a new service.
You may not sell into all four of these groups, but the upshot of knowing about their different integration mechanisms is you can be prepared to work with the existing identity strategies and capabilities of the ones you want to target. Companies require this integration so they can have greater visibility and control of what their users are doing, and end users require this to make it simpler to access your application – leading to increased usage.