Calling On-prem Web Services from the Cloud

| No Comments

Architecture showing how to call an on-premises STS from the cloudAs 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:

Federation, Entitlement Management and the Cloud

| No Comments
Now that I'm 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 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: