UAA, as a core component of Cloud Foundry, is responsible for authenticating and authorizing requests between platform users (e.g. those that push apps) and platform components (e.g. the cloud controller). But when it came to doing auth for the apps you push and the end users of those apps, using the built-in UAA wasn't the best fit, and you could easily end up shooting yourself in the foot. Until now. This talk will guide you though UAA's new multi-tenancy features, and show you how to use the built-in UAA to create arbitrary authorization scenarios for your products without the danger of affecting the security of the core platform. With this level of freedom, you'll have complete and fine-grained control over who is allowed to access your product's components, and how those components are allowed to interact with one another.

1. Enabling Cloud Native Security
with Multi-Tenant UAA
William Tran, Pivotal

2. Agenda
• Introductions
• Why use UAA for Cloud Native Applications
• Advantages of Multi-tenant UAA
• How to get started

3. Introductions

4. 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

5. 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

6. 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

7. OAuth2 In Cloudfoundry
• Apps Manager (PWS or PCF)

8. OAuth2 In Cloudfoundry
• Apps Manager
– Go to apps.cfdomain in the browser
UAA
(login.)
Apps
Manager
(apps.)
Cloud
Controller
(api.)
Browser

9. OAuth2 In Cloudfoundry
• Apps Manager
– Apps manager redirects you to UAA
UAA
(login.)
Apps
Manager
(apps.)
Cloud
Controller
(api.)
Browser
Not logged
in!

10. OAuth2 In Cloudfoundry
• Apps Manager
– Apps manager redirects you to UAA
UAA
(login.)
Apps
Manager
(apps.)
Cloud
Controller
(api.)
Browser

11. OAuth2 In Cloudfoundry
• Apps Manager
– UAA asks for username and password
UAA
(login.)
Apps
Manager
(apps.)
Cloud
Controller
(api.)
Browser
Please log in

12. OAuth2 In Cloudfoundry
• Apps Manager
– User logs in
UAA
(login.)
Apps
Manager
(apps.)
Cloud
Controller
(api.)
Browser
Here is the
username and
password

13. OAuth2 In Cloudfoundry
• 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

14. OAuth2 In Cloudfoundry
• 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

15. OAuth2 In Cloudfoundry
• 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

16. OAuth2 In Cloudfoundry
• 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

17. OAuth2 In Cloudfoundry
• 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…”

18. OAuth2 In Cloudfoundry
• Apps Manager
– Apps manager renders the page
UAA
(login.)
Apps
Manager
(apps.)
Cloud
Controller
(api.)
Browser
Here is the the
pretty screen,
finally!

19. OAuth2 In Cloudfoundry
• Apps Manager
– Authorization Code Grant
– Typical of web applications
– Apps manager webapp is the client

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

21. OAuth2 In Cloudfoundry
• CF CLI
– cf login
UAA
(login.)
Cloud
Controller
(api.)
CF CLI
Here is the
username and
password

22. OAuth2 In Cloudfoundry
• CF CLI
– cf login
UAA
(login.)
Cloud
Controller
(api.)
CF CLI
Here is a token

23. OAuth2 In Cloudfoundry
• CF CLI
– cf login
UAA
(login.)
Cloud
Controller
(api.)
CF CLI
/v2/apps -H
“Authorization: bearer
eyJhbGci…”

24. OAuth2 In Cloudfoundry
• CF CLI
– Resource Owner Password Grant
– Typical of CLI, Mobile Apps, non-browser user
apps
– CF CLI is the client

25. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
my-appAutoscaler
I’m getting very busy!

26. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
my-appAutoscaler
Don’t worry, I’ll create
more instances

27. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
my-appAutoscaler
my-app

28. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
my-appAutoscaler
my-app
my-app

29. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
UAA
(login.)
Cloud
Controller
(api.)
Autoscaler
Time to check
status!

30. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
UAA
(login.)
Cloud
Controller
(api.)
Autoscaler
Here is my
client_id and
client_secret

31. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
UAA
(login.)
Cloud
Controller
(api.)
Autoscaler
Here is a token

32. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
UAA
(login.)
Cloud
Controller
(api.)
Autoscaler
/v2/apps/1234/stats
-H “Authorization: bearer eyJhbGci…”

33. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
UAA
(login.)
Cloud
Controller
(api.)
Autoscaler
CPU at
80%!

34. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
UAA
(login.)
Cloud
Controller
(api.)
Autoscaler
PUT /v2/apps/1234
-H “Authorization: bearer eyJhbGci…”
-d ‘{"instances":2}’

35. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
UAA
(login.)
Cloud
Controller
(api.)
Autoscaler
OK, creating
more
instances

36. OAuth2 In Cloudfoundry
• Autoscaling Service (PCF)
– Client Credentials Grant
– Typical of apps that act without a user’s
involvement
– Autoscaling Service is the client

37. 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

38. UAA is the perfect fit for
Cloud Native Security*

39. 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*

40. So you want to secure your apps
• Example
– You want to host your API application on Cloud
Foundry
my-cloudfoundry.cn

41. So you want to secure your apps
• Example
– You want to host your API application on Cloud
Foundry
my-cloudfoundry.cn
my-api

42. So you want to secure your apps
• Example
– It will be accessed by a web app hosted on CF
my-cloudfoundry.cn
my-api
my-
webapp
browser

43. So you want to secure your apps
• Example
– It will be accessed through a mobile app as well
my-cloudfoundry.cn
my-api
my-
webapp
browser
Mobile
app

44. So you want to secure your apps
• Perfect! Use UAA
my-cloudfoundry.cn
my-api
my-
webapp
browser
Mobile
app
UAA

45. So you want to secure your apps
• Perfect! Use UAA
– Client for web app  authcode grant

46. So you want to secure your apps
• Perfect! Use UAA
– Client for web app  authcode grant
– Client for mobile app  password grant

47. So you want to secure your apps
• Perfect! Use UAA
– Client for web app  authcode grant
– Client for mobile app  password grant
– API app token verification  JWT signature

48. So you want to secure your apps
• 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

49. Who are your end users?
• SpaceDevelopers, OrgManagers
– Platform users, no problem

50. Who are your end users?
• SpaceDevelopers, OrgManagers
– Platform users, no problem
• That sales guy
– Not a platform user, PROBLEM

51. Who are your end users?
jsmith jsmyth
cf set-space-role
jsmyth the-org the-space SpaceDeveloper
oops

52. Who are your end users?
jsmith jsmyth
My app is too
slow

53. Who are your end users?
jsmith jsmyth
cf login –u jsmyth ...
cf scale sales-api –m 10G
I can fix that!

54. The Principle of Least Privilege
• You (or the application, process, module, etc)
should have the minimum level of access
required for performing their job

55. 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

56. Solutions?
• Create your own authorization server
• Deploy your own UAA

57. 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

58. So you want to secure your products
• Example
– When apps bind to the service…
my-cloudfoundry.cn
my-service my-app
cf bind-service

59. So you want to secure your products
• Example
– Create an oauth client
my-cloudfoundry.cn
my-service my-app
UAA
POST
/oauth/client

60. So you want to secure your products
• Example
– Create an oauth client
my-cloudfoundry.cn
my-service my-app
UAA 201: Created

61. my-cloudfoundry.cn
So you want to secure your products
• Example
– So that the app to service communication can be
secured by OAuth2 client credentials grant
my-service my-app
UAA
The client_id and
client_secret are in
VCAP_SERVICES

62. my-cloudfoundry.cn
So you want to secure your products
• Example
– So that the app to service communication can be
secured by OAuth2 client credentials grant
my-service my-app
UAA
GET /api/foo
-H ‘Authorization:
bearer eyJhbGci…’

63. So you want to secure your products
• Perfect! Use UAA
– App to app communication  client credentials
– Token verification  JWT signature
– Every app gets their own credentials
• Super secure right?

64. 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?

65. Admin-Level Credentials
my-service
• client_id: my-service
• client_secret: 123xyz
• authorities: clients.write,
uaa.admin
• authorized_grant_types:
client_credentials

66. Admin-Level Credentials
my-service
• CLIENT_ID: my-service
• CLIENT_SECRET: 123xyz

67. Admin-Level Credentials
my-service
• CLIENT_ID: my-service
• CLIENT_SECRET: 123xyz
I got root, yo.

68. Admin-Level Credentials
my-service
• CLIENT_ID: my-service
• CLIENT_SECRET: 123xyz
This job sucks.
cf env my-service

69. Admin-Level Credentials
$ uaac target uaa.my-cloudfoundry.cn
$ uaac token client get my-service
-s 123xyz
$ uaac client add my-admin-client
–authorities cloud_controller.admin

70. Admin-Level Credentials
I got root yo. Lets
have some fun.

71. The Principle of Least Privilege
• You (or the application, process, module, etc)
should have the minimum level of access
required for performing their job

72. The Principle of Least Privilege
• 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

73. Solutions?
• Create your own authorization server
• Deploy your own UAA

74. 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

75. Running your own UAA
• Pros:
– Principle of least privilege
– You can fork it
• Cons:
– Overhead
– Manual upgrades
– “yak shaving” a bosh release

76. Running your own UAA
• Pros:
– Principle of least privilege
• Systems secured by your UAA cannot affect systems
secured by the platform UAA

77. Running your own UAA
• Pros:
– Principle of least privilege
Your UAA

78. Running your own UAA
• Pros:
– Principle of least privilege
Your UAA
Platform UAA

79. Running your own UAA
• Pros:
– Principle of least privilege
Your UAA
Platform UAA
Impossible!

80. Running your own UAA
• Pros:
– Principle of least privilege
– You can fork it
• Cons:
– Overhead
– Manual upgrades
– “yak shaving” a bosh release

81. Multitenant UAA

82. 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

83. 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

84. 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

85. Let’s Use It

86. 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

87. 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

88. Stay In Touch

89. Stay in touch
• Me
– Twitter: @fivetenwill
– github.com/william-tran
– wtran@pivotal.io
• CF Identity PM
– Sree Tummidi: stummidi@pivotal.io
• CF Identity Team
– Issues: github.com/cloudfoundry/uaa
– Discussion: lists.cloudfoundry.org