Identity management is one of those things you want to “just work.” You shouldn’t spend a lot of time figuring out how to provide secure, frictionless access to authorized users.
That’s the goal of Single Sign-On for PCF (SSO). The service provides helps developers quickly secure their apps with federated identity providers. It uses standards like OAuth and OpenID Connect to bring simplicity and consistency to identity management.
SSO 1.5 – now GA – makes protecting apps with cloud identity management providers extremely simple for app developers. In this tutorial, we’ll show you to use SSO with AzureAD for this purpose.
But first, let’s examine why you want to combine Azure AD and Single Sign-On for PCF.
What is Single Sign-On for PCF?
The Single Sign-On (SSO) service is the identity service broker tile included with Pivotal Cloud Foundry. SSO provides support for native authentication, federated single sign-on, and authorization for applications and APIs deployed on PCF. The Single Sign-On service uses Cloud Foundry UAA behind the scenes as the core identity provider, authorization server and secure token server (STS).
Why do customers use SSO for PCF? Here are three scenarios:
Scenario: Extending incumbent identity management tools to support legacy workloads and cloud-native apps.
How SSO helps: SSO converts authentication and authorization from any enterprise identity provider into standards-based OAuth 2.0 and OpenID Connect tokens for applications to consume. You can extend the life of your existing infrastructure, while you build cloud-native applications.
Scenario: Application developers are flummoxed by corporate governance for identity. Different teams own different parts. And each group uses a different process. There’s so much red tape to plow through.
How SSO helps: SSO is self-service; developers can handle identity on their own, to better suit their needs. For example, developers can automate identity configurations and API permissions via manifests that flow directly to their applications. The net effect? A dramatic reduction in turnaround time, from weeks to hours!
Scenario: Managing identity management systems is a thankless, costly task. Administrators are often looking for a reason to say “no” to cloud-native initiatives because of this pain.
How SSO helps: SSO helps IT staff flip from “no” to “yes” with intuitive dashboards that simplify administration of service plans and IdM systems. Operators use these tools to manage multi-tenant service plans that segment identities & policies based upon your requirements. One customer used SSO to support identity across hundreds of developers while simultaneously supporting PCF with just 3 operators! Scaling the service is a breeze – just click a button, and you’re done. And there’s no downtime!
Now that we’ve established how companies use SSO, let’s dive into the tutorial!
Azure AD: Ideal for Social and Enterprise Login
You tend to integrate identity with Azure AD for one of two reasons:
- Consumer Apps. You want to enable social login with Azure AD. Microsoft Accounts can be integrated using OpenID Connect once developers register on the Microsoft Application Registration Portal. This allows you to tap into the same user base as Outlook.com, Hotmail, Office 365, OneDrive, Skype, Xbox, and Windows.
- For Your Enterprise. More commonly, you want to migrate your enterprise applications from a private datacenter to Azure.
Both use cases are supported with Pivotal’s SSO service.
We’ve offered integration with Azure AD through SAML for a while. Now, SSO is upgraded to also offer OpenID Connect, a method that’s easy to setup, maintain, and troubleshoot. In this tutorial, we’ll show the steps needed to get OpenID Connect integration up and running with SSO for PCF.
Dissecting an OpenID Connect (OIDC) flow
In an OpenID connect flow, the SSO service is the Relying Party (RP). We’ll register it as a Relying Party Client for Azure, the Identity Provider (IdP) in our example here.
The RP then initiates a call to the IdP’s “authorize” and “token” endpoints, based on the associated OpenID Connect flow. The user authenticates to the IdP by signing in. The IdP will also prompt the User to authorize the Relying Party. Upon completion of these steps, an OpenID Connect ID token is sent from the IdP to the RP, completing the OIDC login flow.
In order to complete the setup above, we’ll register SSO as a RP for Azure. We’ll also configure our applications to initiate the OIDC flow through the SSO service plan.
Create an Identity Provider using Azure Client
First, let’s create a service plan. Then we’ll assign this service plan to our Org, a designated place for us to work on our apps in PCF. In the image below, we’ve created a plan and assigned it accordingly.
From here, we configure our service plan, so that Azure can be an OIDC provider. We start by creating a new Identity Provider, reaching the Identity Providers configuration page shown below.
Let’s call our Identity Provider something simple, as it will be used as part of the URLs in back-end communication between Azure and the SSO service plan.
We now add a the description, and select OpenID Connect as the provider type (instead of “SAML” or “LDAP”). Further, we uncheck Enable Discovery, since we’ll need to enter additional information to integrate with Azure. Here’s what our screen looks like:
Let’s pause on this page for now. You’ll notice we have quite a few fields to fill, and for that we’ll need to gather this information from Azure. This requires us to do two things:
- Identify our Azure tenant’s OpenID Connect discovery endpoint
- Register an OAuth client in Azure
We’ll leave this page where it is for now, and come back to finish the configurations once we have all of the information we need. Let’s open a new browser tab.
We’ll use the new tab to get the discovery endpoint. This URL follows a standard convention, with a format of https://login.microsoftonline.com/{TENANT-NAME}/.well-known/openid-configuration. Enter your company’s Azure tenant name (typically found under Azure AD domain names) into the URL field, paste the link into your browser, and hit enter. You’ll then see output that resembles this:
Parsing the information above, we can finish up the “Create Identity Provider” screen. Proceed to fill in these values:
- “Authorization Endpoint URL” (
authorization_endpoint) - “Token Endpoint URL” (
token_endpoint) - “Token Key” (
jwks_ur) - “Issuer” (
issuer) - “User Info Endpoint URL” (
userinfo_endpoint)
For response type, we’ll pick id token. Note that these values may change on the Azure side over time, so always take the latest live information from your tenant’s well-known endpoint.
Our configurations now looks like this:
Next, we’ll open a new tab and go into our Azure Portal account to register an OAuth client. These are called “App Registrations” under the Azure AD section. You’ll see that we’ve configured our client as a “Web app/API” type application. We will use the “Application ID” value as the “Relying Party OAuth Client ID” in the SSO configurations.
We’ll also create a client secret for use as the “Relying Party OAuth Client Secret” in the SSO configuration.
Finally, we’ll configure the callback URL. Since we made the Identity Provider name simple, we can use the auth domain URL from our SSO plan (https://example.login.mydomain.com) with the /login/callback/{origin} endpoint (/login/callback/azure), where our “origin” value is the lowercase name of our identity provider.
With this, we’re done with configurations in Azure!
Now, let’s go back, and enter in the client ID and secret values for the SSO configurations in Pivotal Cloud Foundry.
As a finishing touch, we’ll map the “unique_name” value from Azure to the username in SSO. This will keep the usernames consistent between Azure and SSO.
Now we can save our identity configurations, and start configuring our applications to use Azure for login!
Create App and Login
We start by adding the SSO service plan to the Space in Pivotal Cloud Foundry where our applications are running. This creates a service instance.
Next, we’ll bind the service to our application. In this case, we are using one of our identity sample applications, a Spring Boot app that uses Spring Security. The app is already OAuth-aware.
We included the SSO connector as a dependency of Spring Boot. The application automatically reads environment variables from PCF and integrates with SSO. Developers get this feature for free! (Find out more here.)
Finally, we’ll configure the application on the SSO dashboard to use Azure AD instead of Cloud Foundry’s internal UAA user store.
Now, when we login, we’re redirected to login via Azure!
And we’ve successfully authenticated with an Azure account! SSO will issue ID tokens that identify our user as having authenticated from Azure as an external identity provider. See below:
Want to Learn More? Check out the Docs!
As we’ve shown, you can configure logins for your users with Azure and SSO in just a few steps. But here’s the best part: as you add more applications on Cloud Foundry, you can reuse the same configurations within the SSO plan! SSO for PCF makes it easy to secure your apps and APIs as your cloud-native app portfolio grows.
You can find detailed instructions for configuring Azure OIDC integration – including troubleshooting steps – on our documentation site. You’ll also see similar guidance for our other supported identity providers (like Google, Okta, CA, and Ping).
The talk “OpenID Connect & OAuth – Demystifying Cloud Identity” from SpringOne Platform includes useful background as well.
Developers Rejoice! SSO for PCF Integrates with Spring Boot and Steeltoe
One final question to ponder: what do you want to develop, new features for customers, or identity management plumbing?
When you use Spring Boot and Steeltoe, these frameworks automate security enforcement and runtime configurations. This way, your app can be easily integrated with an identity provider because your code is already OAuth-aware. And once you push your app to Pivotal Cloud Foundry, Pivotal’s SSO service takes over from there.
These security abstractions save you time and effort. An added bonus: once you’ve done it once, you won’t need to do it again if you happen to switch for your next identity providers.
Focus on your code, and let SSO handle identity for you!
