Patrick Radtke - Cirrus Identity, CTO
There are a number of popular IDaaS products on the market which are great for integrating applications with your enterprise identities. Users are assigned applications (i.e. service providers), and when a user picks an application from their dashboard then the IDaaS system performs an IDP initiated login. These IDaaS products work well in this point-to-point model but perform poorly in Identity Federations for several reasons.
1. Applications are not predefined
In an Identity Federation the service providers are not constant. The federation routinely adds new ones, and there can be thousands of them (InCommon, including eduGAIN, has over 3,000). The application dashboard metaphor does not work well in these situations. An admin cannot keep up with adding all the service providers as applications, and a dashboard quickly becomes clunky when it grows too large.
2. Service Providers Determine Access
In an Identity Federation each service provider makes its own authorization decisions based on attributes provided at login. This conflicts with the IDaaS model where the admin assigns applications to users, and it is this assignment that determines authorization. Attempting to use a dashboard in this scenario can confuse users when they've been assigned an application but are then rejected by the service provider.
3. Inflexible IDaaS Configuration
Identity Federations require you to publish your IDP metadata, and often have custom attributes you need to assert. Not all IDaaS products can do this. Azure AD lets you define a custom application and configure the attributes to release, however it also generates a new IDP signing key per application. This does not fit with the Identity Federation model where IDPs have a single key, and it is published to all members. There is an alternate setup in Azure AD which keeps the signing key the same but prevents you from customizing the attributes released. Either way you lose.
IDaaS products are great, as long as you are not part of an Identity Federation. When we built our Identity Provider Proxy and Bridge services, one of our main goals was to provide hosted identity products that play nicely with Identity Federations. Feel free to contact us for more information at email@example.com.