Federation at Scale

Over the last decade federated identity has been widely adopted by many enterprise businesses to realize secure Single SignOn (SSO) to a large variety of applications. Nowadays federated SSO technology is commonly applied between the enterprise and its Software-as-a-Service (SaaS) and BPO providers, suppliers, trading partners, etc. and to cloud applications in general. While organizations gain significant business value from identity federation, they still face major hurdles as they look to scale. Businesses that need to deal with dozens, hundreds or even thousands of federation partners face scalability challenges when establishing large numbers of traditional static federated connections to these partners. These hurdles include both business and technology barriers and the burden increases when there is a requirement to deal with multiple identity federation protocols such as SAML 2.0, WS-Federation and OpenID Connect.

A federated SSO connection between partners is often based upon a one shot process: at the time of the initial agreement, the business conditions are agreed upon as well as the technical parameters for the federated connection based on a specific protocol. The connection is created with the implicit expectation that its parameters are relatively stable, not subject to frequent change. This expectation holds for both the business conditions as well as the technical aspects of the federation connection. As the number of connections grows over time, this assumption will prove to be problematic. Even though the hypothesis that changes for individual connections are incidental may still hold, when applied to a large number of connections it will result in frequent changes overall. The most important technical parameter change that relatively often occurs is an update of the signing key that is used to authenticate sender (ie. the federation partner) of SSO messages. This problem grows exponentially when there is more than one federation service (Identity Provider or Service Provider) deployed within a single organization. It is costly, cumbersome and error-prone to deal with frequent configuration changes on a manual basis.

It would be convenient to introduce to an automated change management process to address this and thus to facilitate federation at a larger scale than we can do today. As a result of the increased adoption of federation SSO more and more organizations face the challenges described above and now the time has come to start dealing with them. Without going into details, solution directions will involve one or all of Trust Frameworks, Multi-party Federation, Centralized Proxy architectures and Metadata peering. 2013 is be the year for kicking off initiatives in the area of Federation at Scale.  I’ll take deep dive in to the solutions in following posts.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s