Enabling Cloud Native Security with Multi-Tenant UAA

Enabling Cloud Native Security with Multi-Tenant UAA
Hello everyone, thank you for coming to my talk, I’m very excited to be here. William Tran, Pivotal

Agenda Introductions Why use UAA for Cloud Native Applications
Advantages of Multi-tenant UAA How to get started Here’s what I’d like to cover, I only have 30 minutes so let’s gets to it. We’ll start by introducing some concepts. Then we’ll talk about why UAA is a great fit for securing cloud native applications. We will go over the problems you might run into that Multi-tenant UAA can solve Then I’ll show you how to get started.

Introductions

About Me Spring user since version 2.0 (2007)
Joined Pivotal October 2013 Based in Toronto, Canada Working on Pivotal CF Services Mobile Services API Gateway Pivotal SSO Spring Cloud Services Committer on UAA First a little about me. I’ve been a Spring user since version 2.0, which was released in 2007, and in fact that is how I began my career, mostly diving into Spring MVC and Spring security. I’ve been using spring ever since, and its come a very long way. I joined Pivotal in October 2013, through the acquisition of Xtreme Labs, a Toronto company that was a major player in mobile app development Since then I’ve been building Pivotal Cloud Foundry services like Mobile API Gateway, Pivotal Single Sign-On, and now I work for Spring on Spring Cloud Services And I also worked with the UAA team bring you the multi-tenancy features of that I’ll be showing you today

About UAA User Account and Authorization server
Secures all CF components OAuth2 and OpenID Connect SCIM API for user management in internal user database Integration with SAML 2.0 and LDAP OAuth2 client registration API So what is UAA? UAA stands for the User Account and Authorization server It secures all Cloudfoundry components by acting as an OAuth2 Authorization Server and an OpenId Connect Identity provider Users can exist in an internal user database, and can be managed via a standard API called SCIM Users can also exist in external identity providers that support SAML 2.0 or LDAP And because this is an OAuth2 authorization server, UAA also has an API for client regitration

About OAuth2 Delegated Authorization 3 Actors
The Authorization Server Users Clients Clients act on behalf of users Authorization Code Grant Resource Owner Password Grant Implicit Grant Clients act on their own Client Credentials Grant So maybe I should take a step back and talk about OAuth 2. OAuth2 is an HTTP based protocol for Delegated Authorization, so instead of every CF component managing their own users and roles, components can make UAA responsible for centrally managing users and roles In OAuth2, there are 3 actors, the Authorization Server, Users, these are actual humans, and Clients, these are applications like mobile apps, CLIs, and web applications. Clients can act on behalf of users, and clients can act on their own. And there are standard methods, called “Grant Types” that are used to get an access token for each of these situations I don’t have time to go through the mechanics of each grant type, so instead we’ll go over some examples of how OAuth2 is used in Cloudfoundy

OAuth2 In Cloudfoundry Apps Manager (PWS or PCF)
So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a

OAuth2 In Cloudfoundry Apps Manager Go to apps.cfdomain in the browser
UAA (login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.)

OAuth2 In Cloudfoundry Apps Manager Apps manager redirects you to UAA
(login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.) Not logged in!

OAuth2 In Cloudfoundry Apps Manager Apps manager redirects you to UAA
(login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.)

OAuth2 In Cloudfoundry Apps Manager UAA asks for username and password
Please log in UAA (login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.)

Here is the username and password
OAuth2 In Cloudfoundry Apps Manager User logs in Here is the username and password UAA (login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.)

Here is an authorization code
OAuth2 In Cloudfoundry Apps Manager UAA redirects back to Apps Manager with a one time code Here is an authorization code UAA (login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.)

Here is the same authorization code
OAuth2 In Cloudfoundry Apps Manager Apps Manager gives the code back to UAA UAA (login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.) Here is the same authorization code

The code is the same, here is a token
OAuth2 In Cloudfoundry Apps Manager UAA exchanges the code for an access token The code is the same, here is a token UAA (login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.)

/v2/apps -H “Authorization: bearer eyJhbGci…”
OAuth2 In Cloudfoundry Apps Manager Apps manager uses the access token to access the CC API UAA (login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.) /v2/apps -H “Authorization: bearer eyJhbGci…”

Here is the the pretty screen, finally!
OAuth2 In Cloudfoundry Apps Manager Apps manager renders the page UAA (login.) Browser Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Apps Manager (apps.) Here is the the pretty screen, finally!

OAuth2 In Cloudfoundry Apps Manager Authorization Code Grant
Typical of web applications Apps manager webapp is the client So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own.

cf target api.cfdomain cf login cf apps OAuth2 In Cloudfoundry CF CLI

Here is the username and password
OAuth2 In Cloudfoundry CF CLI cf login Here is the username and password UAA (login.) CF CLI Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a

OAuth2 In Cloudfoundry CF CLI cf login Here is a token UAA (login.)
Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a

/v2/apps -H “Authorization: bearer eyJhbGci…”
OAuth2 In Cloudfoundry CF CLI cf login UAA (login.) CF CLI Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a /v2/apps -H “Authorization: bearer eyJhbGci…”

OAuth2 In Cloudfoundry CF CLI Resource Owner Password Grant
Typical of CLI, Mobile Apps, non-browser user apps CF CLI is the client So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a

OAuth2 In Cloudfoundry Autoscaling Service (PCF) Autoscaler my-app
So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a I’m getting very busy!

Don’t worry, I’ll create more instances
OAuth2 In Cloudfoundry Autoscaling Service (PCF) Autoscaler my-app So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Don’t worry, I’ll create more instances

OAuth2 In Cloudfoundry Autoscaling Service (PCF) Autoscaler my-app

OAuth2 In Cloudfoundry Autoscaling Service (PCF) UAA (login.)
Autoscaler Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a Time to check status!

Here is my client_id and client_secret
OAuth2 In Cloudfoundry Autoscaling Service (PCF) Here is my client_id and client_secret UAA (login.) Autoscaler Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a

OAuth2 In Cloudfoundry Autoscaling Service (PCF) Here is a token UAA
(login.) Autoscaler Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a

-H “Authorization: bearer eyJhbGci…”
OAuth2 In Cloudfoundry Autoscaling Service (PCF) UAA (login.) Autoscaler Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a /v2/apps/1234/stats -H “Authorization: bearer eyJhbGci…”

OAuth2 In Cloudfoundry Autoscaling Service (PCF) UAA (login.)
Autoscaler Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a CPU at 80%!

-H “Authorization: bearer eyJhbGci…”
OAuth2 In Cloudfoundry Autoscaling Service (PCF) UAA (login.) Autoscaler Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a PUT /v2/apps/1234 -H “Authorization: bearer eyJhbGci…” -d ‘{"instances":2}’

OK, creating more instances
OAuth2 In Cloudfoundry Autoscaling Service (PCF) UAA (login.) Autoscaler Cloud Controller (api.) So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a OK, creating more instances

OAuth2 In Cloudfoundry Autoscaling Service (PCF)
Client Credentials Grant Typical of apps that act without a user’s involvement Autoscaling Service is the client So how is OAuth2 used in Cloudfoundry? Lets walk through some examples: First example, apps manager on PWS. This is typical of securing web applications using the “Authorization Code Grant”. The web app never sees your username and password, can keep the token on the server, and can use the token to make API calls to the Cloud Controller to do things like stop and start apps Next example, CF CLI, in this case you give the CLI your username and password, and it uses the “Resource Owner Password Grant” to get a token. Then the CLI can make API calls to the Cloud Controller In these examples, we have clients accessing a resource on the user’s behalf. The clients are the apps manager webapp and the CF CLI, the resource is the cloud controller API. Last example, the Cloud Controller when you register a new Service Broker, for example when you use the CLI to “cf create-service-broker”. If this Service Broker needs an OAuth client created for it to support Dashboard SSO, which you can set up in the /v2/catalog response, then the Cloud Controller has the authority to act on its own to create the client in UAA. In this case, the Cloud Controller is the client, and UAA is the resource. The user who uses the CLI to cf create-service-broker doesn’t have permission to create clients on UAA themselves. This is an example of using the client credentials grant type, the Cloud Controller gets a token from UAA that represents the Cloud Controller acting on its own. cf login -a

OAuth2 In Cloudfoundry The CF platform has many more examples of using OAuth2 UAA is the key Manages users Manages clients Grants and verifies access tokens All these examples show that Cloudfoundry uses OAuth2 to secure a variety of situations and there are many more examples of this in the platform. UAA is the component makes all of this happen, it manages users, manages clients, grants access tokens, and helps applications verify these tokens. Which brings me to this statement

UAA is the perfect fit for Cloud Native Security*
If you’ve been thinking about Cloud Native Architecture, or microservices, and because you’re here at CF Summit chances are you’ve given this some thought, you might have noticed that Cloudfoundry itself is an example of Cloud Native architecture. Cloudfoundry is composed of applications like the Cloud Controller, UAA, Apps manager, loggregator, gorouter, these are microservices, and they all use UAA to secure all the interactions between them Now notice the asterisk there

UAA for Cloud Native Security
*In CF there’s more to security than just UAA Network security / security groups Cross container traffic / trusted workloads No End to end TLS UAA is for application-level security It works for us, so it’ll work for you* UAA is not the be all and end all to security in CF. We still have network security settings like security groups You probably have cross container traffic disabled or need to think about whether all workloads are trusted There’s currently no end to end encryption, SSL terminates at the load balancer. UAA is for application-level security This is stuff that, as an application developer, you are in control of. And because it works for us (the developers of Cloudfoundry), then it’ll work for you, almost. And I’ll show you why.

So you want to secure your apps
Example You want to host your API application on Cloud Foundry my-cloudfoundry.cn So lets say you want to secure your own applications. In this example, say you want host your API application on Cloud Foundry. It will be accessed by a server-side web app also hosted on Cloud Foundry and a mobile app as well How do you secure it? There’s an app for that, and it’s called UAA Your web app is a client that uses the authorization code grant type The mobile app is another client that uses the resource owner password grant type And the API app can validate tokens by validating the token’s signature This all sounds good but..

Example You want to host your API application on Cloud Foundry my-cloudfoundry.cn So lets say you want to secure your own applications. In this example, say you want host your API application on Cloud Foundry. It will be accessed by a server-side web app also hosted on Cloud Foundry and a mobile app as well How do you secure it? There’s an app for that, and it’s called UAA Your web app is a client that uses the authorization code grant type The mobile app is another client that uses the resource owner password grant type And the API app can validate tokens by validating the token’s signature This all sounds good but.. my-api

Example It will be accessed by a web app hosted on CF my-cloudfoundry.cn browser my-webapp So lets say you want to secure your own applications. In this example, say you want host your API application on Cloud Foundry. It will be accessed by a server-side web app also hosted on Cloud Foundry and a mobile app as well How do you secure it? There’s an app for that, and it’s called UAA Your web app is a client that uses the authorization code grant type The mobile app is another client that uses the resource owner password grant type And the API app can validate tokens by validating the token’s signature This all sounds good but.. my-api

Example It will be accessed through a mobile app as well my-cloudfoundry.cn browser my-webapp So lets say you want to secure your own applications. In this example, say you want host your API application on Cloud Foundry. It will be accessed by a server-side web app also hosted on Cloud Foundry and a mobile app as well How do you secure it? There’s an app for that, and it’s called UAA Your web app is a client that uses the authorization code grant type The mobile app is another client that uses the resource owner password grant type And the API app can validate tokens by validating the token’s signature This all sounds good but.. Mobile app my-api

Perfect! Use UAA my-cloudfoundry.cn browser my-webapp UAA So lets say you want to secure your own applications. In this example, say you want host your API application on Cloud Foundry. It will be accessed by a server-side web app also hosted on Cloud Foundry and a mobile app as well How do you secure it? There’s an app for that, and it’s called UAA Your web app is a client that uses the authorization code grant type The mobile app is another client that uses the resource owner password grant type And the API app can validate tokens by validating the token’s signature This all sounds good but.. Mobile app my-api

Perfect! Use UAA Client for web app  authcode grant So lets say you want to secure your own applications. In this example, say you want host your API application on Cloud Foundry. It will be accessed by a server-side web app also hosted on Cloud Foundry and a mobile app as well How do you secure it? There’s an app for that, and it’s called UAA Your web app is a client that uses the authorization code grant type The mobile app is another client that uses the resource owner password grant type And the API app can validate tokens by validating the token’s signature This all sounds good but..

Perfect! Use UAA Client for web app  authcode grant Client for mobile app  password grant So lets say you want to secure your own applications. In this example, say you want host your API application on Cloud Foundry. It will be accessed by a server-side web app also hosted on Cloud Foundry and a mobile app as well How do you secure it? There’s an app for that, and it’s called UAA Your web app is a client that uses the authorization code grant type The mobile app is another client that uses the resource owner password grant type And the API app can validate tokens by validating the token’s signature This all sounds good but..

Perfect! Use UAA Client for web app  authcode grant Client for mobile app  password grant API app token verification  JWT signature So lets say you want to secure your own applications. In this example, say you want host your API application on Cloud Foundry. It will be accessed by a server-side web app also hosted on Cloud Foundry and a mobile app as well How do you secure it? There’s an app for that, and it’s called UAA Your web app is a client that uses the authorization code grant type The mobile app is another client that uses the resource owner password grant type And the API app can validate tokens by validating the token’s signature This all sounds good but..

Perfect! Use UAA Client for web app  authcode grant Client for mobile app  password grant API app token verification  JWT signature API app can validate token on its own So lets say you want to secure your own applications. In this example, say you want host your API application on Cloud Foundry. It will be accessed by a server-side web app also hosted on Cloud Foundry and a mobile app as well How do you secure it? There’s an app for that, and it’s called UAA Your web app is a client that uses the authorization code grant type The mobile app is another client that uses the resource owner password grant type And the API app can validate tokens by validating the token’s signature This all sounds good but..

Who are your end users? SpaceDevelopers, OrgManagers
Platform users, no problem Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA

Who are your end users? SpaceDevelopers, OrgManagers That sales guy
Platform users, no problem That sales guy Not a platform user, PROBLEM Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA

Who are your end users? jsmith jsmyth cf set-space-role \
Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA jsmith jsmyth cf set-space-role \ jsmyth the-org the-space SpaceDeveloper oops

Who are your end users? My app is too slow jsmith jsmyth
Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA jsmith jsmyth

Who are your end users? I can fix that! jsmith jsmyth
Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA jsmith jsmyth cf login –u jsmyth ... cf scale sales-api –m 10G

The Principle of Least Privilege
You (or the application, process, module, etc) should have the minimum level of access required for performing their job Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA

You (or the application, process, module, etc) should have the minimum level of access required for performing their job Salesguy should not have been added to the platform UAA Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA

Solutions? Create your own authorization server Deploy your own UAA
Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA

So you want to secure your products
Example You want to build a product that’s packaged as a CF service my-cloudfoundry.cn Lets look at another example. Say you want to build a product that’s packaged as a CF service. Apps use the service on their own, without a user involved Communication between the service and the apps that bind to is should be secured via OAuth2 No problem, use UAA You have applications acting on their own means use the client credentials grant Tokens can be verified by checking their signature And you can implement this by by creating a client for every binding, so each app that binds to the service gets a client ID and client secret that they can use to get a token from UAA, and then use that token to access the service my-service

Example When apps bind to the service… my-cloudfoundry.cn Lets look at another example. Say you want to build a product that’s packaged as a CF service. Apps use the service on their own, without a user involved Communication between the service and the apps that bind to is should be secured via OAuth2 No problem, use UAA You have applications acting on their own means use the client credentials grant Tokens can be verified by checking their signature And you can implement this by by creating a client for every binding, so each app that binds to the service gets a client ID and client secret that they can use to get a token from UAA, and then use that token to access the service my-service my-app cf bind-service

Example Create an oauth client my-cloudfoundry.cn POST /oauth/client UAA Lets look at another example. Say you want to build a product that’s packaged as a CF service. Apps use the service on their own, without a user involved Communication between the service and the apps that bind to is should be secured via OAuth2 No problem, use UAA You have applications acting on their own means use the client credentials grant Tokens can be verified by checking their signature And you can implement this by by creating a client for every binding, so each app that binds to the service gets a client ID and client secret that they can use to get a token from UAA, and then use that token to access the service my-service my-app

Example Create an oauth client my-cloudfoundry.cn 201: Created UAA Lets look at another example. Say you want to build a product that’s packaged as a CF service. Apps use the service on their own, without a user involved Communication between the service and the apps that bind to is should be secured via OAuth2 No problem, use UAA You have applications acting on their own means use the client credentials grant Tokens can be verified by checking their signature And you can implement this by by creating a client for every binding, so each app that binds to the service gets a client ID and client secret that they can use to get a token from UAA, and then use that token to access the service my-service my-app

Example So that the app to service communication can be secured by OAuth2 client credentials grant my-cloudfoundry.cn The client_id and client_secret are in VCAP_SERVICES UAA Lets look at another example. Say you want to build a product that’s packaged as a CF service. Apps use the service on their own, without a user involved Communication between the service and the apps that bind to is should be secured via OAuth2 No problem, use UAA You have applications acting on their own means use the client credentials grant Tokens can be verified by checking their signature And you can implement this by by creating a client for every binding, so each app that binds to the service gets a client ID and client secret that they can use to get a token from UAA, and then use that token to access the service my-service my-app

Example So that the app to service communication can be secured by OAuth2 client credentials grant my-cloudfoundry.cn GET /api/foo -H ‘Authorization: bearer eyJhbGci…’ UAA Lets look at another example. Say you want to build a product that’s packaged as a CF service. Apps use the service on their own, without a user involved Communication between the service and the apps that bind to is should be secured via OAuth2 No problem, use UAA You have applications acting on their own means use the client credentials grant Tokens can be verified by checking their signature And you can implement this by by creating a client for every binding, so each app that binds to the service gets a client ID and client secret that they can use to get a token from UAA, and then use that token to access the service my-service my-app

Perfect! Use UAA App to app communication  client credentials Token verification  JWT signature Every app gets their own credentials Super secure right? Lets look at another example. Say you want to build a product that’s packaged as a CF service. Apps use the service on their own, without a user involved Communication between the service and the apps that bind to is should be secured via OAuth2 No problem, use UAA You have applications acting on their own means use the client credentials grant Tokens can be verified by checking their signature And you can implement this by by creating a client for every binding, so each app that binds to the service gets a client ID and client secret that they can use to get a token from UAA, and then use that token to access the service

How do you create clients in UAA?
POST /oauth/clients Token must have scope clients.write Creating clients with authorities Eg the app gets a token with my-service.read scope Requires clients.write and uaa.admin So give your service admin credentials? Ok, so how do you create clients in UAA? easy, just POST to /ouath/clients, but in order to do that you need a token, because UAA is also an OAuth2 resource. You token must have the scope of clients.write to create a new client. But it’s not as simple as that. Our product needs to create clients with authorities, meaning the client can obtain tokens with certain scopes on their own. For example the scope might be myservice.read In order to create clients with authorities, you need to have both client.write and uaa.admin This is the same level of access that the uaa admin client has. So why not let you service have admin access? If someone breaks into your service and gets the credentials, those credentials can be used to do anything in the system. And your service doesn’t need that level of access All your service needs is the ability to create clients with authorities that can be used to access itself, not access the entire platform. Again, we need to follow the principle of least privilege, and so the only solutions are to roll your own authorization server, or deploy your own UAA.

Admin-Level Credentials
my-service client_id: my-service client_secret: 123xyz authorities: clients.write, uaa.admin authorized_grant_types: client_credentials Ok, so how do you create clients in UAA? easy, just POST to /ouath/clients, but in order to do that you need a token, because UAA is also an OAuth2 resource. You token must have the scope of clients.write to create a new client. But it’s not as simple as that. Our product needs to create clients with authorities, meaning the client can obtain tokens with certain scopes on their own. For example the scope might be myservice.read In order to create clients with authorities, you need to have both client.write and uaa.admin This is the same level of access that the uaa admin client has. So why not let you service have admin access? If someone breaks into your service and gets the credentials, those credentials can be used to do anything in the system. And your service doesn’t need that level of access All your service needs is the ability to create clients with authorities that can be used to access itself, not access the entire platform. Again, we need to follow the principle of least privilege, and so the only solutions are to roll your own authorization server, or deploy your own UAA.

my-service CLIENT_ID: my-service CLIENT_SECRET: 123xyz Ok, so how do you create clients in UAA? easy, just POST to /ouath/clients, but in order to do that you need a token, because UAA is also an OAuth2 resource. You token must have the scope of clients.write to create a new client. But it’s not as simple as that. Our product needs to create clients with authorities, meaning the client can obtain tokens with certain scopes on their own. For example the scope might be myservice.read In order to create clients with authorities, you need to have both client.write and uaa.admin This is the same level of access that the uaa admin client has. So why not let you service have admin access? If someone breaks into your service and gets the credentials, those credentials can be used to do anything in the system. And your service doesn’t need that level of access All your service needs is the ability to create clients with authorities that can be used to access itself, not access the entire platform. Again, we need to follow the principle of least privilege, and so the only solutions are to roll your own authorization server, or deploy your own UAA.

my-service CLIENT_ID: my-service CLIENT_SECRET: 123xyz Ok, so how do you create clients in UAA? easy, just POST to /ouath/clients, but in order to do that you need a token, because UAA is also an OAuth2 resource. You token must have the scope of clients.write to create a new client. But it’s not as simple as that. Our product needs to create clients with authorities, meaning the client can obtain tokens with certain scopes on their own. For example the scope might be myservice.read In order to create clients with authorities, you need to have both client.write and uaa.admin This is the same level of access that the uaa admin client has. So why not let you service have admin access? If someone breaks into your service and gets the credentials, those credentials can be used to do anything in the system. And your service doesn’t need that level of access All your service needs is the ability to create clients with authorities that can be used to access itself, not access the entire platform. Again, we need to follow the principle of least privilege, and so the only solutions are to roll your own authorization server, or deploy your own UAA. I got root, yo.

my-service CLIENT_ID: my-service CLIENT_SECRET: 123xyz Ok, so how do you create clients in UAA? easy, just POST to /ouath/clients, but in order to do that you need a token, because UAA is also an OAuth2 resource. You token must have the scope of clients.write to create a new client. But it’s not as simple as that. Our product needs to create clients with authorities, meaning the client can obtain tokens with certain scopes on their own. For example the scope might be myservice.read In order to create clients with authorities, you need to have both client.write and uaa.admin This is the same level of access that the uaa admin client has. So why not let you service have admin access? If someone breaks into your service and gets the credentials, those credentials can be used to do anything in the system. And your service doesn’t need that level of access All your service needs is the ability to create clients with authorities that can be used to access itself, not access the entire platform. Again, we need to follow the principle of least privilege, and so the only solutions are to roll your own authorization server, or deploy your own UAA. This job sucks. cf env my-service

$ uaac target uaa.my-cloudfoundry.cn $ uaac token client get my-service \ -s 123xyz $ uaac client add my-admin-client \ –authorities cloud_controller.admin Ok, so how do you create clients in UAA? easy, just POST to /ouath/clients, but in order to do that you need a token, because UAA is also an OAuth2 resource. You token must have the scope of clients.write to create a new client. But it’s not as simple as that. Our product needs to create clients with authorities, meaning the client can obtain tokens with certain scopes on their own. For example the scope might be myservice.read In order to create clients with authorities, you need to have both client.write and uaa.admin This is the same level of access that the uaa admin client has. So why not let you service have admin access? If someone breaks into your service and gets the credentials, those credentials can be used to do anything in the system. And your service doesn’t need that level of access All your service needs is the ability to create clients with authorities that can be used to access itself, not access the entire platform. Again, we need to follow the principle of least privilege, and so the only solutions are to roll your own authorization server, or deploy your own UAA.

I got root yo. Lets have some fun. Ok, so how do you create clients in UAA? easy, just POST to /ouath/clients, but in order to do that you need a token, because UAA is also an OAuth2 resource. You token must have the scope of clients.write to create a new client. But it’s not as simple as that. Our product needs to create clients with authorities, meaning the client can obtain tokens with certain scopes on their own. For example the scope might be myservice.read In order to create clients with authorities, you need to have both client.write and uaa.admin This is the same level of access that the uaa admin client has. So why not let you service have admin access? If someone breaks into your service and gets the credentials, those credentials can be used to do anything in the system. And your service doesn’t need that level of access All your service needs is the ability to create clients with authorities that can be used to access itself, not access the entire platform. Again, we need to follow the principle of least privilege, and so the only solutions are to roll your own authorization server, or deploy your own UAA.

You (or the application, process, module, etc) should have the minimum level of access required for performing their job Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA

You (or the application, process, module, etc) should have the minimum level of access required for performing their job Giving admin level credentials to applications is dangerous Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA

Solutions? Create your own authorization server Deploy your own UAA
Who are your users? If the end users of your apps are the same users that use the platform, like Space Developers, this is fine. But if the end users are, for example, that sales guy that doesn’t know the difference between bash and bosh, then the end users are not the users of the platform, and using the built-in UAA for this situation can be a problem You definitely don’t want to cf create-user salesguy and give him access to the whole platform just so he can access your app That would violate the principle of least privilege, meaning you should only grant the minimum level of access needed to perform one’s duties So your only solutions are to create your own user database and authorization server, or just deploy your own instance of UAA

How do you deploy your own UAA?
cf push cloudfoundry-identity-uaa.war Yaml config Bootstrap users Provision DB Do the above manually, or as part of a Bosh deployment So lets say you want to deploy your own UAA You can run it as an app, download the war and cf push it There’s a yaml configuration for it You need to bootstrap admin level users and clients You need to provision DB You could to that all manually, or you could do this as a bosh deployment

Running your own UAA Pros: Cons: Principle of least privilege
You can fork it Cons: Overhead Manual upgrades “yak shaving” a bosh release There are pros and cons to running your own UAA The biggest pro is that you get the principle of least privilege. Users and clients in your UAA can never effect anything secured by another UAA. Another pro is that you can fork UAA and modify the code, say to support some identity provider that isn’t SAML 2.0 or LDAP But there are cons. There’s the overhead in running it, you have extra app instances, you need to maintain and test your fork if you forked it, you need to manage upgrades yourself, you need to coordinate its deployment yourself or even go as far as writing your own bosh release for your custom UAA.

Running your own UAA Pros: Principle of least privilege
Systems secured by your UAA cannot affect systems secured by the platform UAA There are pros and cons to running your own UAA The biggest pro is that you get the principle of least privilege. Users and clients in your UAA can never effect anything secured by another UAA. Another pro is that you can fork UAA and modify the code, say to support some identity provider that isn’t SAML 2.0 or LDAP But there are cons. There’s the overhead in running it, you have extra app instances, you need to maintain and test your fork if you forked it, you need to manage upgrades yourself, you need to coordinate its deployment yourself or even go as far as writing your own bosh release for your custom UAA.

Running your own UAA Pros: Principle of least privilege Your UAA
There are pros and cons to running your own UAA The biggest pro is that you get the principle of least privilege. Users and clients in your UAA can never effect anything secured by another UAA. Another pro is that you can fork UAA and modify the code, say to support some identity provider that isn’t SAML 2.0 or LDAP But there are cons. There’s the overhead in running it, you have extra app instances, you need to maintain and test your fork if you forked it, you need to manage upgrades yourself, you need to coordinate its deployment yourself or even go as far as writing your own bosh release for your custom UAA. Your UAA

There are pros and cons to running your own UAA The biggest pro is that you get the principle of least privilege. Users and clients in your UAA can never effect anything secured by another UAA. Another pro is that you can fork UAA and modify the code, say to support some identity provider that isn’t SAML 2.0 or LDAP But there are cons. There’s the overhead in running it, you have extra app instances, you need to maintain and test your fork if you forked it, you need to manage upgrades yourself, you need to coordinate its deployment yourself or even go as far as writing your own bosh release for your custom UAA. Your UAA Platform UAA

There are pros and cons to running your own UAA The biggest pro is that you get the principle of least privilege. Users and clients in your UAA can never effect anything secured by another UAA. Another pro is that you can fork UAA and modify the code, say to support some identity provider that isn’t SAML 2.0 or LDAP But there are cons. There’s the overhead in running it, you have extra app instances, you need to maintain and test your fork if you forked it, you need to manage upgrades yourself, you need to coordinate its deployment yourself or even go as far as writing your own bosh release for your custom UAA. Your UAA Impossible! Platform UAA

Running your own UAA Pros: Cons: Principle of least privilege
You can fork it Cons: Overhead Manual upgrades “yak shaving” a bosh release There are pros and cons to running your own UAA The biggest pro is that you get the principle of least privilege. Users and clients in your UAA can never effect anything secured by another UAA. Another pro is that you can fork UAA and modify the code, say to support some identity provider that isn’t SAML 2.0 or LDAP But there are cons. There’s the overhead in running it, you have extra app instances, you need to maintain and test your fork if you forked it, you need to manage upgrades yourself, you need to coordinate its deployment yourself or even go as far as writing your own bosh release for your custom UAA.

Multitenant UAA So now would be a good time to tell you about multitenant UAA

What is Multitenant UAA
CF v208 + The built-in UAA with subdomains Subdomain maps to Identity Zone Total segregation between Identity Zones API for creating Identity Zones Existing API stays the same Multitenant UAA was released with CF 208 in May We added subdomain support for UAA, where subdomains of uaa map to a tenant, also called an Identity Zone. Identity Zones are like different universes. Like you’ll never see Kirk and Spock fighting Darth Vader. Totally separate universes. You have separate users, clients, identic providers, group mappings You still get SAML2.0 and LDAP support in your Identity Zone, and these configurations are separate from the IdP configurations of the main UAA or other Identity Zones. You get an API for creating Zones, and Zone creation is instantaneous You can reuse the entire UAA API in your Identity Zone, the only thing that changes is the hostname of the request, since you’re adding an extra subdomain infront of .uaa or .login to specify the Identity Zone your targeting.

Zone administrators UAA users with god-like powers in an identity zone
Requires scope zone.[zone-id].admin Instead of targeting zone via subdomain, use X-Identity-Zone-Id header POST uaa.domain.com/oauth/clients  create a client in the UAA zone POST uaa.domain.com/oauth/clients -H “X-Identity-Zone-Id:12345”  create a client in the Identity Zone with id 12345 But wait, there’s more! There is the concept of Zone administrators. I said that things in one Identity Zone cannot effect anything in another Identity Zone. Well Zone administrators is the only exception. Zone Administrators are users in the UAA zone, this means they could also be platform users, that can perform admin actions in another Identity Zone. This is necessary because when you create an Identity zone it starts out empty, there are no users, no clients. There needs to be some actor that can create these things in the new zone. So this is possible if you have zone.zone-id.admin scope AND you’re a user in the UAA zone. We need to do things a little differently when acting as a zone administrator. We can’t just reuse our token in the Identity Zone’s subdomain, the token will be rejected because it’s not issued by that domain. So instead of targeting the zone by subdomain, we just add a header X-Identity-Zone-Id whose value is the guid of the identity zone, the same guid that is in the zone.zoneid.admin scope

Multitenant UAA Pros: Cons: Principle of least privilege
API calls for creating a new tenant (aka Identity Zone) Zone administrators instead of bootstrap users Cons: Overhead Manual upgrades “yak shaving” a bosh release You can’t fork it With Multitenant UAA, you still get the principal of least privilege, but you also get the ability to create new tenants, also known as Identity Zones, with a single API call. And with Zone administrators, you don’t need to setup initial bootstrap users like you do when deploying your own UAA. The cons of deploying your own UAA all disappear. But because you’re using the built in UAA, you cant just fork and modify the code if you need to do that.

Let’s Use It So lets see it work I’ll demo the following script:
# setup hostname myzone.localhost # target my local uaa uaac target # get a token as the identity client uaac token client get identity -s identitysecret # see the token contains zones.write uaac token decode # create an identity zone. no UAAC commands for this so use uaac curl, which is like curl but it adds the token header uaac curl /identity-zones -X POST -H "Content-type:application/json" -d '{"id":"12345","subdomain":"myzone","name":"My Identity Zone"}' # make marissa the zone admin. You need to be admin to do this uaac token client get admin -s adminsecret uaac group add zones admin uaac member add zones admin marissa # get a token as marissa with the zone admin scope. Use the authcode grant and the identity client uaac token authcode get -c identity -s identitysecret --scope zones admin # see the token contains zones admin # create an admin client in the zone. The authorities are the same authorities as the admin in the UAA zone. uaac curl /oauth/clients -H "Content-type:application/json" -H "X-Identity-Zone-Id:12345" -X POST -d '{"client_id":"admin","client_secret":"zonesecret","scope":["uaa.none"],"resource_ids":["none"],"authorities":["uaa.admin","clients.read","clients.write","scim.read","scim.write","clients.secret"],"authorized_grant_types":["client_credentials"]}' # doing things as a zone admin via uaac is cumbersome because we can't reuse the cli commands, # we have to use uaac curl to include the zone id header. # But we've just created an admin client in the zone, so lets use that to do everything else # target the new zone with its subdomain uaac target # get a token as the admin in the zone uaac token client get admin -s zonesecret # now we can do whatever we want # create salesguy for that first example uaac user add salesguy -- -p password # create clients with any authorities for the second example uaac client add -i

Multitenant UAA with UAAC
Setup can be cumbersome When acting as zone admin with X-Identity-Zone-Id header, you can only uaac curl Once you have an admin client in the zone, uaac works great Future enhancements Creating initial users / clients when the Identity Zone is created -z global option to target a zone via header So as you could see, getting things set up using UAAC was a little cumbersome. We needed to use uaac curl quite a few times, pretty much whenever we create an identity zone or are acting as a zone administrator. But once we were able to create that admin client in the zone, uaac worked great, it worked just as if we were targeting another instance of uaa. We’re planning on making things easier though. For uaac we’re looking into adding a global option –z that can be used by a zone administrator to target a zone by header. And we’re also looking at adding another identity zone creation endpoint that allows you to create an identity zone and an initial set of users or clients all in one shot.

Summary UAA is great for securing Cloud Native Applications
Always use the principle of least privilege Don’t add non-platform users to the platform Don’t give out platform admin abilities to other apps You can deploy your own UAA but multitenant UAA is an API call away Tooling needs to catch up But once you get that admin client set up, its easy So to summarize, UAA is great for securing cloud native applications But when securing your own applications, think about the principle of least privilege. Don’t give out more permission than you have to. You can deploy your own UAA to make sure you’re not giving away platform privileges, but multitenant UAA can get you the same guarantee and its only an API call away. Tooling needs to catch up with these new features, but for now, once you can get that admin client setup, the rest is easy.

Stay In Touch So lets see it work I’ll demo the following script:
# setup hostname myzone.localhost # target my local uaa uaac target # get a token as the identity client uaac token client get identity -s identitysecret # see the token contains zones.write uaac token decode # create an identity zone. no UAAC commands for this so use uaac curl, which is like curl but it adds the token header uaac curl /identity-zones -X POST -H "Content-type:application/json" -d '{"id":"12345","subdomain":"myzone","name":"My Identity Zone"}' # make marissa the zone admin. You need to be admin to do this uaac token client get admin -s adminsecret uaac group add zones admin uaac member add zones admin marissa # get a token as marissa with the zone admin scope. Use the authcode grant and the identity client uaac token authcode get -c identity -s identitysecret --scope zones admin # see the token contains zones admin # create an admin client in the zone. The authorities are the same authorities as the admin in the UAA zone. uaac curl /oauth/clients -H "Content-type:application/json" -H "X-Identity-Zone-Id:12345" -X POST -d '{"client_id":"admin","client_secret":"zonesecret","scope":["uaa.none"],"resource_ids":["none"],"authorities":["uaa.admin","clients.read","clients.write","scim.read","scim.write","clients.secret"],"authorized_grant_types":["client_credentials"]}' # doing things as a zone admin via uaac is cumbersome because we can't reuse the cli commands, # we have to use uaac curl to include the zone id header. # But we've just created an admin client in the zone, so lets use that to do everything else # target the new zone with its subdomain uaac target # get a token as the admin in the zone uaac token client get admin -s zonesecret # now we can do whatever we want # create salesguy for that first example uaac user add salesguy -- -p password # create clients with any authorities for the second example uaac client add -i

Stay in touch Me CF Identity PM CF Identity Team Twitter: @fivetenwill
github.com/william-tran CF Identity PM Sree Tummidi: CF Identity Team Issues: github.com/cloudfoundry/uaa Discussion: lists.cloudfoundry.org Lets stay in touch If you have any questions about consuming UAA with Spring, please reach out to me, I’ve got a video on youtube about it from my presentation at SpringOne a few months ago If you want to reach the Product Manager directly, her name is Sree Tummidi, and she’d be happy to know how your using these new features and what your thoughts are If you want to engage the team or the UAA user community, create a github issue or post on the cf-dev mailing list. Thank you for listening, I’ll take questions now.

Enabling Cloud Native Security with Multi-Tenant UAA

Similar presentations

Presentation on theme: "Enabling Cloud Native Security with Multi-Tenant UAA"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Enabling Cloud Native Security with Multi-Tenant UAA

Similar presentations

Presentation on theme: "Enabling Cloud Native Security with Multi-Tenant UAA"— Presentation transcript:

Similar presentations

About project

Feedback