enabling cloud native security with oauth2 and multi-tenant uaa

Enabling Cloud Native Securitywith Multi-Tenant UAA

William Tran, Pivotal

Agenda

• Introductions• Why use UAA for Cloud Native

Applications• Advantages of Multi-tenant UAA• 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

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

About OAuth2

• Delegated Authorization• 4 Actors

– The Authorization Server– User– Client– Resource Server

• Clients act on behalf of users– Authorization Code Grant– Resource Owner Password Grant– Implicit Grant

• Clients act on their own– Client Credentials Grant

OAuth2 In Cloudfoundry

• Apps Manager (PWS or PCF)


• Apps Manager– Go to apps.cfdomain in the browser

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser


• Apps Manager– Apps manager redirects you to UAA

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser

Not logged in!


• Apps Manager– Apps manager redirects you to UAA

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser


• Apps Manager– UAA asks for username and password

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser

Please log in


• Apps Manager– User logs in

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser

Here is the username and

password


• Apps Manager– UAA redirects back to Apps Manager with a

one time code

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser

Here is an authorization

code


• Apps Manager– Apps Manager gives the code back to UAA

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser

Here is the same authorization code


• Apps Manager– UAA exchanges the code for an access

token

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser

The code is the same, here is a token


• Apps Manager– Apps manager uses the access token to

access the CC API

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser

/v2/apps -H “Authorization: bearer

eyJhbGci…”


• Apps Manager– Apps manager renders the page

UAA(login.)

Apps Manager(apps.)

Cloud Controller

(api.)Browser

Here is the the pretty screen,

finally!


• Apps Manager– Authorization Code Grant– Typical of web applications– Apps manager webapp is the client


• CF CLI

cf target api.cfdomaincf logincf apps


• CF CLI– cf login

UAA(login.)

Cloud Controller

(api.)CF CLI

Here is the username and

password



UAA(login.)

Cloud Controller

(api.)CF CLI

Here is a token



UAA(login.)

Cloud Controller

(api.)CF CLI

/v2/apps -H “Authorization: bearer

eyJhbGci…”


• CF CLI– Resource Owner Password Grant– Typical of CLI, Mobile Apps, non-browser

user apps– CF CLI is the client


• Autoscaling Service (PCF)

my-appAutoscaler

I’m getting very busy!



my-appAutoscaler

Don’t worry, I’ll create more instances



my-appAutoscalermy-app



my-appAutoscalermy-app

my-app



UAA(login.)

Cloud Controller

(api.)Autoscaler

Time to check status!



UAA(login.)

Cloud Controller

(api.)Autoscaler

Here is my client_id and client_secret



UAA(login.)

Cloud Controller

(api.)Autoscaler

Here is a token



UAA(login.)

Cloud Controller

(api.)Autoscaler

/v2/apps/1234/stats -H “Authorization: bearer eyJhbGci…”



UAA(login.)

Cloud Controller

(api.)Autoscaler

CPU at 80%!



UAA(login.)

Cloud Controller

(api.)Autoscaler

PUT /v2/apps/1234 -H “Authorization: bearer eyJhbGci…”

-d ‘{"instances":2}’



UAA(login.)

Cloud Controller

(api.)Autoscaler

OK, creating more

instances


• Autoscaling Service (PCF)– Client Credentials Grant– Typical of apps that act without a user’s

involvement– Autoscaling Service is the client


• The CF platform has many more examples of using OAuth2

• UAA is the key– Manages users– Manages clients– Grants and verifies access tokens

UAA is the perfect fit forCloud Native Security*

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*

So you want to secure your apps

• Example– You want to host your API application on

Cloud Foundry

my-cloudfoundry.cn


• Example– You want to host your API application on

Cloud Foundry

my-cloudfoundry.cn

my-api


• Example– It will be accessed by a web app hosted on

CF

my-cloudfoundry.cn

my-api

my-webappbrowser


• Example– It will be accessed through a mobile app as

well

my-cloudfoundry.cn

my-api

my-webappbrowser

Mobile app


• Perfect! Use UAA

my-cloudfoundry.cn

my-api

my-webappbrowser

Mobile app

UAA


• Perfect! Use UAA– Client for web app authcode grant


• Perfect! Use UAA– Client for web app authcode grant– Client for mobile app password grant


• Perfect! Use UAA– Client for web app authcode grant– Client for mobile app password grant– API app token verification JWT signature


• 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

Who are your end users?

• SpaceDevelopers, OrgManagers– Platform users, no problem


• SpaceDevelopers, OrgManagers– Platform users, no problem

• That sales guy – Not a platform user, PROBLEM


jsmith jsmyth

cf set-space-role \jsmyth the-org the-space SpaceDeveloper

oops


jsmith jsmyth

My app is too slow


jsmith jsmyth

cf login –u jsmyth ...cf scale sales-api –m 10G

I can fix that!

The Principle of Least Privilege

• 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

Solutions?

• Create your own authorization server• Deploy your own 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

my-service


• Example– When apps bind to the service…

my-cloudfoundry.cn

my-service my-app

cf bind-service


• Example– Create an oauth client

my-cloudfoundry.cn

my-service my-app

UAAPOST

/oauth/client


• Example– Create an oauth client

my-cloudfoundry.cn

my-service my-app

UAA 201: Created

my-cloudfoundry.cn


• Example– So that the app to service communication

can be secured by OAuth2 client credentials grant

my-service my-app

UAAThe client_id and client_secret are in

VCAP_SERVICES

my-cloudfoundry.cn


• Example– So that the app to service communication

can be secured by OAuth2 client credentials grant

my-service my-app

UAAGET /api/foo

-H ‘Authorization: bearer eyJhbGci…’


• Perfect! Use UAA– App to app communication client

credentials– Token verification JWT signature– Every app gets their own credentials

• Super secure right?

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?

Admin-Level Credentials

my-service

• client_id: my-service• client_secret: 123xyz• authorities: clients.write,

uaa.admin• authorized_grant_types:

client_credentials


my-service

• CLIENT_ID: my-service• CLIENT_SECRET: 123xyz


my-service


I got root, yo.


my-service


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


I got root yo. Lets have some fun.



• Giving admin level credentials to applications is dangerous

Solutions?

• Create your own authorization server• Deploy your own 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

Running your own UAA

• Pros:– Principle of least privilege– You can fork it

• Cons:– Overhead– Manual upgrades– “yak shaving” a bosh release


• Pros:– Principle of least privilege

• Systems secured by your UAA cannot affect systems secured by the platform UAA



Your UAA



Your UAA

Platform UAA



Your UAA

Platform UAAImpossible!


• Pros:– Principle of least privilege– You can fork it

• Cons:– Overhead– Manual upgrades– “yak shaving” a bosh release

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

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

Multitenant UAA

• Pros:– 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

Let’s Use It

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

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

Stay In Touch

Stay in touch

• Me– Twitter: @fivetenwill– github.com/william-tran– [email protected]

• CF Identity PM– Sree Tummidi: [email protected]

• CF Identity Team– Issues: github.com/cloudfoundry/uaa – Discussion: lists.cloudfoundry.org

enabling cloud native security with oauth2 and multi-tenant uaa

Software