cloud-native security financial_services identity PCF Pivotal Cloud Foundry security Single Sign-On sso

For Banks, Securing Modern Apps Starts with Identity & Access Management. Here’s How PCF Helps the Largest Firms Reduce Risk.

We’ve long said that running IT for a bank is not for the faint of heart. The job requires a unique mix of creativity, agility, pragmatism, and plenty of grit. You're tasked with navigating generational changes like:

  • Regulatory requirements & compliance. Industry rules and regulations must inform how you innovate and where you invest.

  • Security. The most successful banks of the next decade will be fast and secure. Choosing one or the other isn't an option.

  • Rising consumer expectations. Users now expect banking apps to behave like their favorite consumer mobile apps. You need to deliver fast, responsive, and engaging experiences to be relevant.

  • Increased competition from FinTech. Your competitors aren't only your neighbors on Wall Street. Silicon Valley's best and brightest aim to disrupt the banking industry.

How can you capitalize on these seismic shifts and gain market share? By becoming a cloud-native enterprise. Many leading banks turn to Pivotal Cloud Foundry (PCF) to help with this transformation. In fact, 7 of the largest banks in the U.S. work with Pivotal.

In this blog series, we’ll explore common security challenges for banks embarking on their cloud-native journey. Each post will describe a common security challenge. Then, we’ll describe how banks use Pivotal Cloud Foundry to improve their security posture.

First up: identity and access management.

The Big Picture: Ensure Frictionless Access to the Right Services

You’re going to need a platform to maximize developer productivity. The question becomes, how do you give each developer the right permissions to do their job? How can this be as self-service as possible? And how the heck do you scale the model? After all, the largest banks have more developers than many tech blue-chips.

You’re trusting an automated platform to power your growth for the next ten years. So let’s look at the big picture. In your current state you have:

  • Identity silos that are hard to manage. You need to look after thousands of developers, from many departments around the world. Each developer may have his or her own unique set of permissions and access levels. And don’t forget about mapping users to their respective cost centers!

  • Many data centers. You’ll want to quickly scale the platform to run in multiple locations.

  • Oodles of regulatory and compliance requirements. Gotta think about this from the get-go.

  • Employee provisioning and de-provisioning considerations. This is the “identity” part of identity management. What processes and technologies do you have for registering, provisioning, and propagating identities? What about ongoing management and deprovisioning? How quickly can you spin up and spin down access?

  • Integration with existing identity and access management practices. You probably have good controls in place today. How can you adapt them to a modern platform?

It’s tempting to roll out a solution with many login IDs and multiple passwords. But this will come back to haunt you in a big way. Invariably, employees will reuse passwords, use weak passwords, share passwords, and so on.

Instead, we’ve helped banks deploy a better solution: Reuse credentials through federated identity management. Here, you couple Pivotal Cloud Foundry’s authorization and authentication modules with your chosen identity provider (IdP). Why is this model a best practice? Lots of reasons:

  • It saves time and money. When you implement automated identity provisioning alongside the organization's IdP, you’re not duplicating effort. It reduces cost by cutting thousands of hours of IT and help desk time.

  • It’s simpler. Users have fewer credentials to remember.

  • Ease of administration. You can provision and deprovision users from single control plane.

  • Change once, propagate everywhere. Need to update the status of a user? Do it once in the identity management system, and the platform will relay the change to all PCF foundations.

  • Inherit compliance. You probably have certified, compliant processes for identity and access management. Use these workflows as a baseline for your modern platform.

This option is secure, compliant, and “it just works.” It also sidesteps the most common pitfalls of identity and access management:

  • There’s less chance for human error because the system automates provisioning and deprovisioning.

  • Productivity stays high since users aren’t waiting for access.

  • Risk goes down – you can quickly de-provision outgoing employees.

Many of these same benefits apply to integrating single sign-on as well. (More on that later.) First, let’s take a closer look at how banks secure access to the platform.

Use PCF APIs for Federated Identity Management

We want our automated identity provisioning system to tackle several important tasks. So let’s use the Cloud Foundry API to:

  • Create Organizations. Organizations are part of Cloud Foundry’s permissions model. Think of orgs as a collection of users, resources, applications, and environments. Each org has a resource quota and is billed separately. It’s common for an org to “map” to a product team in your company.

  • Create Spaces. Organizations are further subdivided into spaces. Spaces represent discrete application environments. For example, an org may have spaces for staging and production. Spaces help you adhere to the dev/prod parity factor.

  • Map Organizations to your cost centers. Use this to simplify chargeback and showback for platform usage. Sync your org structure in PCF with internal accounting workflows. Curious how to implement chargeback/showback in PCF? Check out this whitepaper! It’s got loads of best practices from enterprises like yours.

  • Create Users, and assign them to Organizations. Your current IdP has all your user info in there already. So the task here is to bring those users into PCF, then configure what they can do and see. Use the CF CLI to automate the import of users from your IdP.

  • Set Roles. A user can have one or more roles. The combination of these roles defines the user’s overall permissions in the org and within specific spaces of that org, for example, Admin, Space Manager, or Space Developer.

Take a moment to consider these scenarios. The totality of these features make it possible to get hundreds of developers productive with Pivotal Cloud Foundry on Day 1. The whole is greater than the sum of the parts!

Configuring User Entitlement with User Account and Authentication (UAA)

Now that we’ve added users to PCF, it’s time to authenticate and authorize developers to use the platform. Our goal is to empower the right individuals to access the right Pivotal Cloud Foundry resources at the right times for the right reasons.

We see these common requirements, based on our work with several large FinServ firms:

  • Prevent access to PCF resources, unless the user enters proper credentials. Further, controls should be “smart” enough to reflect different levels of access. Consider a CI/CD tool that automatically deploys applications. You will want large sets of developers to have access to deploy to dev environments. Similarly, you will have a smaller set of devs with access to deploy to production. This should “just work” without any additional friction in the daily work of your engineers.

  • Provide a framework for managing user attributes, credentials, and entitlements across the Cloud Foundry environment. You’ll need to determine the resources each person can access. Should they be able to create and manage account information? What about write or read-only access to resources controlled by the Cloud Foundry API?

  • Allow policy-based access. It’s so much easier to administer policies that can apply to many users. It’s more secure, too! You should be able to create policies on any number of factors, like the team they belong to and their role.

The User Account and Authentication (UAA) Server is the identity management service for Cloud Foundry. The UAA module provides identity-based security for applications and APIs. It supports popular open standards for authentication and authorization, like OAuth, OpenID Connect, SAML, and LDAP. Choose the right IdP, either in your data center or as a managed service in the public cloud!

The task now is to configure UAA as a service provider that redirects to an external IdP. Most administrators opt to integrate UAA with an LDAP server. When this integration is live, UAA can authenticate users via LDAP search and bind operations.

Let’s examine how you map corporate identities to platform roles. You will build a simple script to automate the onboarding of users from your corporate identity management system into PCF. We can automate the process in a few easy steps using the APIs for PCF and UAA:

Step Action API Call Description
1 Get an UAA OAuth token POST /oauth/token
Host: uaa.[DOMAIN]		 Get the Oauth token to authenticate automation application for the the calls you will do.
2 Create an organization POST /v2/organizations
Host: api.[DOMAIN]		 Create an organization by giving it a name. You will get a organization guid in the response
3 Create a space POST /v2/spaces
Host: api.[DOMAIN]		 Create a Space and associate it with the organization using the organization guid. You will get a space guid in the response.
4 Import user from LDAP into UAA POST /Users
Host: uaa.[DOMAIN]		 Import users from your IdP. In this case for LDAP use username: <userID> and origin: ldap. You will get a UAA User guid for the user.
5 Create a user in PCF POST /v2/users
Host: api.[DOMAIN]		 Create the user in PCF using the UAA user guid
6 Associate User with Organization PUT /v2/organizations/:guid/users/:user_guid
Host: api.[DOMAIN] 		 Assign the user to the Organization using the organization guid and the UAA User guid 
7 Associate Developer with the Space PUT /v2/spaces/:guid/developers/:developer_guid
Host: api.[DOMAIN]		 Assign the user a Developer role and a space using the space guid and the UAA User guid

From here, we can proceed to implement single sign-on for applications running on the PCF platform. As mentioned earlier, SSO is a must-have feature. The service securely and seamlessly allows developers to connect their applications to the right users and resources.

Most customers choose to deploy the Single Sign-On for PCF tile. The tile is purpose-built for this use case, and Pivotal regularly issues patches and updates for it.

The Single Sign-On service for PCF

SSO for PCF helps you do several useful things:

  • It supports the concepts we’ve discussed so far, including native authentication, federated single sign-on, and authorization. Operators can configure native authentication and federated single sign-on (using SAML, for example) to verify the identities of application users. After authentication, the Single Sign-On service uses OAuth 2.0 to secure resources or APIs.

  • The tile presents approved and configured identity services as part of your Cloud Foundry marketplace. Developers have identity capabilities preconfigured for their applications, so integration is a snap! It’s also helpful that identity systems appear next to other developer-ready services in the marketplace.

  • Converts complex SAML exchanges into basic OAuth tokens for applications to consume.

  • Supports rapid security enablement of Java Spring Applications. How? Spring Security can process and enforce OAuth tokens.

  • Works in concert with the platform to automate security enforcement and runtime configuration.

Wiring up SSO to your preferred provider is a simple, if tedious, process. Make sure to check out our excellent integration guides for your preferred provider:

OK, time to wrap up with a broader discussion about cloud-native security at your bank.

Keep CALM and cf push

Highly automated platforms like Pivotal Cloud Foundry can dramatically improve your security posture. PCF makes the secure thing the easy thing. What else can you do to boost security?

  • Culture. No conversation about modern software development is complete without culture. So what does a modern InfoSec culture look like? For starters, you should have a team of generalists and specialists, with an emphasis on coding ability. And you should rotate people on the security team for a few months at a time. This is a fantastic way to change how your teams think about security. Change won’t happen overnight, but rotations will make it happen faster than you think!

  • Automation. If you do something more than once, you should automate it. Scanning should be automated. And you should build service brokers to automate how your teams interact with add-on services.

  • Lean controls. A company can spend millions on traditional security products that offer marginal benefits. Instead, orientate around your PCF platform! Right out-of-the-box you can inherit so many security and compliance controls. (Check out Security and Compliance in PCF and Pivotal Cloud Foundry: The Auditor’s Guide for details.)

  • Metrics. If you can measure it, you can manage it. You need to collect and track the right data. Focus on the common KPIs like rapid patching, perhaps better known as mean-time-to-repair. We’re also seeing banks track the age of their systems. Why? Older resources tend to be more fragile. Strive for younger VMs, clusters, containers, and credentials. Don’t let your systems get stale!

Want to learn more about CALM and PCF? Attend this upcoming webinar, featuring 451 Research analysts and Pivotal executives.

Stay tuned for the next installment in this series. We’ll address how to secure all the services that touch PCF, including platform services, custom services, and credentials!

Related Articles