April 2011 Archives

As organizations
begin using and deploying cloud applications, some of their services are left
on-premises (for various reasons), resulting in a hybrid architecture. In such
deployments, the on-prem services sometimes need to be invoked securely from
the cloud. When doing so, an STS can be used to broker trust from the cloud
into the organization. Unfortunately, the token
issued by the IdP when authenticating end users isn't always available to the
cloud-based caller due to restrictions/limitations of the cloud platform. In
such cases, the on-prem STS can't be given a token asserted by a trusted issuer
that it can validate and transform. As a result, the on-prem services do not
have all the data needed to make authorization decisions, enforce licensing
agreements, etc. One possible solution to this problem is to allow the
cloud-based caller to specify in the message sent to the STS certain
end-user-related data that should be put in the token that is minted. This will
then be passed along to the on-prem services in a token asserted by the local
STS. This idea is shown in the following figure:

At first, this may
seem odd since the STS is the asserting party and it is being told what to assert. In cases where there is a trusted subsystem in place between the STS and the
cloud app, however, it is safe IMO. Consider the alternative where the
cloud app doesn't have the original security token. Since the interface of an
STS is restricted to security tokens (by design), the client must create one
using the identity attributes provided to it by the PaaS environment in which
it's running. In other words, if the token asserted by the IdP isn't available,
the cloud app has to cook one up. In this case, it is the asserter, resulting
in the same sort of situation where it's the authority not the STS. The nice
thing about passing the end user data in the message is that the caller needn't
create a security token. There are tradeoffs w/ this approach, but there always
are ;-)

The WS-Trust
specification allows any XML to be included in the RST that the client sends to
the STS. Ping Identity has used this extensibility point in the protocol to
allow callers to include name/value pairs that PingFederate should include when
minting security tokens. As a result, it is very easy using that STS to
implement the sort of architecture described above. To do so, you would configure
the STS w/ the attribute names that can be passed in the request, stipulate
what to do if they are not (fault or do nothing), and include them in the RST.
Totally simple.

To make this even
simpler though, I extended WIF's RequestSecurityToken and
WSTrustRequestSerializer classes to make the client-side programming model
natural and easier for .NET developers. Using these, a cloud-based STS client
could pass the end user's identity info in the request rather than having to
create a security token. The result would look something like this:

Now that I'm w/ Ping Identity in Sweden, it was only a matter of time before I bumped into the guys at Axiomatics. When I was in Stockholm the other day, we had fika and talked about federation, entitlement management, financial services, and the upcoming EIC conference. While we sipped our coffee, we discussed what it would look like to put our products, PingFederate and Axiomatics Policy Server (APS), together to form a best-of-breed solution that provides organizations like financial institutions with the ability to easily get prospects into the customer corridor by leveraging identities that they already have while simultaneously removing authentication and authorization from their line of business (LOB) applications.

Before our bullar were done, we had come up w/ an architecture that used PingFederate's Cloud Identity Connectors to reduce the number of steps prospective retail banking customers have to perform when deciding whether or not to do business with a particular financial institution. Using these, prospects can connect with Facebook, Google, Twitter, or other social networks to easily provide basic information about themselves (e.g., the country they live in). With this, a bank can show the prospect personalized and targeted information such as local contact phone numbers, state- or country-specific terms of service, local market news (e.g., exchange rates for the Krona if in Sweden or USD if in the States), and locations of nearby branches and ATMs. Using existing identities, organizations can provide Web surfers with more relevant information, helping them find what they need to decide to begin doing business with the provider.

In the banking scenario that we were chatting about as well as in many others, security in critical. In such cases, social sign-on, though helpful in reducing friction and increasing conversion rates, cannot provide a high enough level of assurance (LoA) that a person really is who they say they are. To overcome this, after someone signs up for an account, a bank would verify their physical identity and then provide them w/ a new digital identity. Using the new one and not a social network identity, the customer could gain access to higher value assets like online banking. This account would be stored in a directory maintained by the financial institution. Even with this and the support for all the different protocols used by the various social networks, our architecture was simple because PingFederate supports so many types of identity providers. The overall scheme we cooked up is shown in the following sketch:

When a prospect or customer accesses the banking Web site, they are given the opportunity to use a social login or an identity provided by the bank. Regardless, information about the requested page and how the user authenticated is sent to APS in a XACML message which renders a decision about whether or not access should be granted or denied. As a result, if a prospect has authenticated using a social networking account, APS will not allow them to access sensitive area of the Web site; instead it will redirect them back to the login page where they can login using a more trustworthy identity. If APS decides that access should be allowed to the page, which buttons, tabs, bank accounts, and other elements should be render will also be determined using claims asserted by PingFederate.

With an architecture like this, the application doesn't have to understand the numerous federation protocols and security tokens used by the various social networks. It also doesn't have to interface directly with the identity store where customers are kept which could be an LDAP directory, a RDBMS, a mainframe, and/or something else. The LOB application handles identities as claims asserted by PingFederate, giving it one normalized representation of the customer or prospect. Authorization rules that governs access to resources are also maintained outside of the application. Policies can be stored centrally and updated without recompiling or redeploying the application.

After finishing our coffee, we couldn't help ourselves; it seemed so simple, we had to try to implement it. Before I had to catch my train home, we had the basics working. It didn't require any custom coding whatsoever. (The only coding needed was for the online banking application because neither of us had one of those.)

Given that we are both going to be at EIC, we thought we might show it off there. Stay tuned on that. In the meantime, if you have questions or thoughts about this, please drop me a line.

Connecting w/ you all here, on Twitter, and elsewhere around the intertubes is great, but it is no substitute for meeting face to face. In hopes that I can do so w/ as many of you as possible, I wanted to let you know that I'll be at a number of upcoming events. If you're attending any of these, please drop me a line, so we can hookup. Here's the specifics:

I'll be presenting on the fundamentals of Identity and Access Management (IdM) at the University of Surrey outside of London next Tuesday at 14:00. (Ping me right away if you'd like to attend.)