When it comes to federation and single sign-on (SSO), a fundamental difference exists between Identity Providers (IdPs) and Service Providers. IdPs enable you to authenticate users accessing an application or website via SSO; Service Providers deliver the service you want users to consume. But in today’s market, we’re starting to see the lines blur as organizations act as both an IdP and a Service Provider – consuming applications from third parties while also extending applications to their own employees, contractors, customers and partners.
Service Providers face a couple of key challenges IdPs don’t need to deal with when implementing federated SSO technology:
- Customers with varying identity capabilities. Identity is ultimately an integration challenge. Different customers will have different levels of sophistication in their own identity technology, and they will expect you to work with what they have. (I will describe this challenge in an upcoming post.)
- Application Integration. Service Providers are essentially providing access to a set of applications to their customers and partners. In order to provide a consistent user experience across these applications, federation technology needs to be integrated with each application to provide SSO. A variety of approaches exist today for solving this problem,from adding SAML support directly to the application via an SDK or toolkit, to “wrapping” an application in an IAM system that passes user information into the application as part of the HTTP session.
If you are evaluating Identity as a Service for your business today, make sure you consider whether you will be providing services as well as consuming them. If you plan on providing services as well as consuming them, make sure your system is capable of supporting the functionality you need. To do this successfully, you’ll need to understand the types of customers you would like to sell to, and have a plan for providing the types of identity interfaces that your customers will need.