 I'm Shree Dumidi, and I'm the product manager for UAA. I've been with Pivotal for three years, basically responsible for product management of UAA and other identity initiatives at Pivotal, including the single sign-on service. So as part of the talk today, I'll be providing an overview of UAA in terms of its role in Cloud Foundry and how it is securing Cloud Foundry, followed by some recent feature updates, Roadmap, and then finally some housekeeping, and I'll try to leave time for Q&A. So in order to explain what is the role of UAA in terms of securing the platform, let's start off with the most known interface, which is the Cloud Foundry command line interface. So everyone over here has used the CFCLI. So as an app developer, when you specify your username and password through the CF login process, let's try to figure out what happens behind the scenes. So CFCLI, as a client, is actually going to first invoke UAA. And in this case, it's going to be the token endpoint. And it's going to pass the username, the password, the client ID, and the client secret. With CFClient, it's a public client, so the secret is essentially empty. So when UAA receives that information, what it does is it authenticates the user. And then it basically generates a token which represents the identity of the user in the context of that client. And it generates that token and sends it over to the CFCLI. So far, so good. Now, when as an app developer, you perform an action or a command like CFApps, so that is essentially to get a list of applications, what the CFCLI does is it actually takes the token, makes a request to the Cloud Controller API, and it passes that token in a header. So it's referred to as an authorization header. And basically, when the Cloud Controller API receives this particular request, it validates the token. Now, the kind of things that propagate in the token are the user's identity and some core screen permissions, like are they an admin or not. So in the previous presentation, there was talk about some new permissions, like global auditor and read-only access. So those kind of things flow in the token. But then beyond that, if Cloud Controller has to perform some fine-grained decisions, like is this user a space developer, that's within the purview of Cloud Controller. Now, when Cloud Controller performs the validation of the token, it basically responds to the CLI in this case, the app listing. So the previous example was wherein there was a user involved, there was a client, and there was the Cloud Controller API. There is another kind of interaction that UAA secures is essentially component to component. So something like the CF router, which is there in two flavors, you have the Go Router and you have the TCP router. There is a routing API, which is available for the router to perform actions like registration and deregistration of routes. So in that particular scenario also, UAA is securing that interaction. So CF router as a client is actually going to interact with UAA and present its client credentials. It's a client ID and a client secret. And when UAA receives it, it validates that client ID and secret and then generates a token, which is then passed to the CF router. But things don't end there, because now the CF router takes that token and makes a request to the routing API to perform like a register or unregister of route. And then the routing API validates the token. And once it's good, then the action is completed. In this case, registration or unregisteration of a route. So we looked at how UAA is used within CF, but what makes up UAA? So when you deploy a CF as a CF release or a CF deployment, there are various components that get deployed, and UAA is one of them. UAA is packaged as a Bosch release, and there are multiple jobs within UAA. Obviously, the main one is the UAA server, which is running within Tomcat. And it's essentially a JVM process. But along with UAA or alongside UAA, within the same Tomcat process, there is something called a STATS-D, and it is responsible for metrics. So the metrics that UAA emits are actually encapsulated and routed via the STATS-D component. So an extension to this metrics in general is the collection-wise, there are two other jobs. There is the STATS-D injector and the Metron agent, which collectively are pushing the metrics out of UAA into a collection point, which is governed by the aggregator architecture. So things could be streamed over a SecurSys log channel, or you could have things being collected via different nozzles. So beyond that, there are other jobs within this VM. There is something called as Rout Registrar. So as the name suggests, it is for registering UAA's route with the router so that it is discoverable. But then that's for external routing. Now, in the previous example, I explained that a component like router is also interacting with UAA. But from a latency and a performance point of view, you don't want those things to go out and come back in through the router. So we have console for internal service discovery, which seems like it's going to get replaced by Bosch DNS soon. So that will be replaced. But right as of now, when you install UAA, there is a console job. Now, let's take a look at the things outside of this UAA VM that UAA is interacting with. UAA has a database dependency. We support Postgres MySQL, and we recently added support for SQL Server. And so that's the UAA database. UAA database obviously comes with its own set of tables which allow an internal user store. So you can register user accounts in UAA. But that's not a typical deployment in an enterprise. Because in an enterprise, you already have a source of truth, which could be Active Directory. Or if it is a federated setup, you could be dealing with a SAML identity provider or an OpenID Connect identity provider, which is essentially the new bus. So things like Google's identity provider is OIDC. So UAA has the ability to connect out to these essentially user stores or federated identity stores to get the identity. On the other side is, how does UAA interface with the applications? So you need to have familiarity with OAuth and OpenID Connect to understand this. But the interface between the application or the API and UAA is OAuth OpenID Connect typically. But UAA is also a SAML identity provider. What that means is, in addition to securing applications which are basically relying on UAA to get a token, they can also rely on UAA to get an assertion. So UAA supports a SAML identity provider profile as well, which means that applications can rely on UAA to get a SAML assertion which encapsulates the identity. Beyond that, we have an admin interface for user and group management. So we follow a standard called SCIM, which is called System for Cross Domain Identity Management. And then we have REST APIs for all of our management in general. So if you're managing identity providers, zones, groups, users, there is a REST API for that. UAA and multi-tenancy. I don't have to explain multi-tenancy here. Basically, UAA is multi-tenant, but it's logical multi-tenancy as in it's logical separation. So let me explain this with use case. Suppose you want to use UAA to secure your applications, but you want to maintain this boundary, which could be basically based on your environments. So you have your dev pre-prod and prod environment, and you want to use separate authentication domains for that. That could be one reason why you want separate tenants, which are referred to as identity zones. Or as an enterprise, you could have internal-facing applications and external-facing applications. So your internal applications, you may want to keep on one authentication domain, and your external applications, you want to apply a separate security policy and keep it completely separate. So UAA supports that model, wherein you can create multiple identity zones. Now, each zone is a UAA in itself. So what each zone represents is pretty much everything that UAA relies on for its functioning. So users, groups, clients, identity providers, group memberships, mappings, it's all per zone. Now, what you need to understand is as part of CF deployment, a UAA is already getting pushed. So the default zone, which is accessible typically at login dot or UAA dot system domain, that is used for securing CF itself. So when I say CF itself, it's used for securing the router, the Cloud Controller API. But then beyond that, you can create more zones. So you can actually, as an operator, expose the same UAA that is being used for securing the platform to actually secure apps as well by creating one or more identity zones. Quick look at the token format, because we'll be going into the detail of that later on. UAA out of the box supports Jot, which is JSON web token. It mainly has three parts as driven by the standard. So there is the header, the body, and the footer. And if you decode this, the header is carrying meta information about how is the token signed. So it will carry information like the algorithm and the key ID. So the ID of the key with which the Jot was signed or the token was signed. The type is Jot, in this case. Obviously, the main information, which is the claims about the user or a client, will flow within the body. Some important aspects here are subject, which refers to the identity. In this case, it's a user. So it's the user identity. And then you have something called as origin. In this case, you see that it says UAA. That means that the user authenticated with the internal user store. So anytime the user authenticates with the internal user store, then it will say UAA. But if it were LDAP authentication or some other provider, like SAML or OpenID Connect, it will be that provider alias. Now, why do you need this kind of information in the token? Well, if you're making downstream authorization decisions wherein you want to trigger a piece of functionality within the app only if the user came in through a certain provider, you can do such things by basically looking at the token because it came from a trusted party. Client-side integrations for UAA. You all are aware of this. We have UAAC, which is Ruby Gem. And it is backed by a library, the UCF UAA lib. We do have plans to rewrite this in Go. So we've started a project in incubation. It's called the UAA CLI. It's a command line interface, basically return in Go. And we have plans to have the MVP basically cover at least all the functionality that UAAC provides. Beyond that, Spring Security OAuth is something that a lot of our customers are using for integrating with UAA. So Spring Security OAuth provides basic OAuth client functionality. So what that means is, if you have an application which needs to communicate with UAA to get tokens, you can use Spring Security and not have to worry about anything OAuth related. It is, however, undergoing a major rewrite. So please refer to the link that I've put in the presentation here. So if you follow Spring IO, they are doing a major rewrite as part of their M5O series. So they are adding support for Core OpenID Connect. But they are rewriting a lot of things, so something you need to plan for. CF Java Client is essentially an admin interface. So it implements all of the UAA APIs. And you would want to use it if you want to do user management, identity zone management, or provider management within your own tool. And this Java Client allows you to do that. Finally, we recently added support for UAA JavaScript SDK. So this would be of interest if you are writing a single-page application, which is JavaScript-only, runs within the browser, no backend. And as a developer, if you don't want to really understand the intricacies of OAuth, this is the SDK to use, because you just call a method, you register a set of things, and you're good to go. Now, there is a spec out there, which is referred to as the OpenID Connect session management. So for folks over here who are familiar with SAML, there is something called as the single logout profile. So what that means is, with respect to single sign-on, you have multiple applications that a user is accessing. But if the user logs out of one application, if your compliance policy is to log them out of all applications at that time, then you need to have a single logout in place. So SAML supports that, and OpenID Connect through this RFC supports that. So we have plans to add that support within RSDK. Moving on to feature updates, so I have not covered everything. So I've tried to stick to the major updates that we've done in the past few months, major ones being client and secret rotation, sorry, keys and client secret rotation. So UAA relies for its functioning. It relies on different key material. So for example, tokens are signed with a key. And if UAA is acting as a SAML identity provider or as a relying party, it needs to sign out ongoing authentication requests or sign assertions. So these keys, prior to this functionality, were not rotatable. Or even if they were rotated out, you would face downtime. So the way we implemented this feature is you add your new key. And this can be added via the API. So there is an Identity Zone API for management of all Identity Zone configuration. So you specify the new key there, and then you switch the key ID for active key. So the moment you do that, what happens is UAA starts using that key for all of its operations. But the old key is still there. And the reason it is still there is because all the outstanding tokens that have been signed, they should still function, because otherwise your apps will start facing downtime. So there will, however, be situations wherein a key compromise has happened, and you don't want the old key to function at all. In those situations, you should immediately get rid of the old key. But if you want that graceful rotation, then you should follow this process of introducing the new key, make it active, and then get rid of the old key after some time. We follow a similar model for OAuth client secrets also. So today, what we support is each client has not one, but you can have two secrets. So if you were to rotate out a secret, you will add the new secret, and client authentication will work with both the secrets, and then eventually you can remove the old secret. And all these activities can be performed through the API, so they are fully automated. One important thing to note is default zone, all of the key management is via the manifest, not via the API. But for all other zones, you can use the API. OpenID Connect enhancements, we've recently done a lot of enhancements around OpenID Connect support. So UAA is both an identity provider and a relying party. So as an identity provider, we've added discovery support. What that basically means is all relying parties can discover configuration, OpenID Connect IDP configuration for UAA without having to statically support or hook that up into a relying party. So that configuration is available at well-known configuration, OpenID configuration, under the base domain of the UAA. As a relying party, we have added support for onboarding external providers like Google, Azure. So Azure, for example, supports OpenID Connect and SAML, so we can connect with both. So Azure can expose Active Directory via OpenID Connect connection also. And Ping Identity is one more heavily used enterprise product for federation, and it also supports OpenID Connect. So we've tested with all three of them for our OpenID Connect relying party. Any time we are connecting to an external provider, we have to basically map attributes. Like, how will we read information from that provider? So we do this in a standards-based manner. We've done this with LDAP and for SAML, use specify attribute mappings in order to read information from the external IDP. And we also support mapping external groups to UAA scopes. So this is a pattern that we've supported for all kinds of providers, and we support this with OpenID Connect, too. Future work-wise, we have plans to get OIDC certified. So there are a lot of things in there in that certification. You need to have identity provider support, relying party support, and then OpenID Connect session management. We have plans to apply for that and get listed. Backup and recovery. So backup and recovery is basically a process through which you can backup the state of CF. And part of that state is the UAA database, right? And you can restore it in a disaster site, disaster recovery site. So as an operator, the way we have simplified the backup and recovery procedure or backup and restore procedure for CF is there is something called as the Bosch BBR. So UAA implements this framework through which basically there are different series of things that have to happen of starting with a pre-backup lock, then you do the backup, then you unlock, and then on the recovery site, you perform a pre-restore lock, then you restore, and then you unlock. So these things are actually triggered by the operator through a jump box. And that jump box relies on a separate virtual machine, which is called the BBRVM, to maintain the state. And that is where all the backups are taken. So what happens is when the operator kicks off this process, the Bosch BBRVM is going to invoke the lock functionality on UAA. Now what that will do is put UAA in a limited functionality mode. Other components, like Cloud Controller, they are container networking. They do it a different way. They don't go into a limited functionality mode. But with UAA, what we do is we keep some functionality available, because we don't want to take a downtime for apps that rely on UAA for authentication and authorization. So when you go into a limited functionality mode, login and token acquisition flows are still available. All gets are available, because it's a read-only mode, so that doesn't really hurt. And this set of endpoints and the methods that you want to allow are actually configurable. So as an operator, if you decide that, no, I do not want even login functionality to be there, that's your decision. But something that I would advise against, because especially if you are using UAA, not just to secure CF, but for apps, you don't want to take a downtime for applications. One important thing, so the backup and recovery is supported for MySQL and Postgres. We will add support for SQL Server as well, but as of the MVP, MySQL and Postgres are supported. So earlier, I was explaining UAA support for Jot tokens. We have added support for opaque tokens also. So as the name suggests, it's an opaque string. Now, the good thing about Jot is that it can be validated offline. This is really important, especially we are dealing with distributed systems. You don't want this latency overhead of always having to call back into UAA to validate tokens. So with Jot, you get offline validation with opaque tokens, you don't. But then there is a place where opaque tokens do make sense is when you want immediate revocability, because you want that like any time a token has been generated by UAA, and it's being used by a resource server like an API for access checks, you want to make sure that that access is still good. And you want to get that latest state centrally from the server. So in those situations, it does make sense. With opaque tokens, you get claims confidentiality, because with Jot, it's a base 64 encoded string, but not necessarily encrypted. UAA doesn't encrypt Jot. But with opaque tokens, a client will never be able to figure out what is within the token, because it's an opaque string. Only clients as in resource servers or APIs will be able to exchange that opaque token for actual claims. Persistence-wise, opaque tokens are always persisted. If you do want Jot to be revocable, we have added that support, wherein Jot can also be optionally persisted. So this is a flag that you need to turn on at a UAA identity zone level. Revocability of tokens. So Jot tokens are revocable if they are persisted, and opaque tokens are always revocable. Future work-wise, today we do not put any limits on the number of opaque tokens that are generated per user and client combination. So this is something that we understand is limiting, because especially as your usage of UAA grows and the footprint grows, so will the number of opaque tokens in your storage. So we plan on adding policy around how many opaque tokens can be generated per user and client combination. Token exchange is one more important feature that we recently added. So as the name suggests, token exchange is basically exchanging one kind of token for another kind. So but what are these different kinds of tokens? So one is SAML. So if you have a SAML assertion and you want it exchanged for a OAuth access token, that's something that token exchange allows you to do. But token exchange also allows you to exchange a Jot for another Jot from UAA. So all well and good. You can do token exchange. But what is the use case that is being solved? So there are two important aspects to it. As an enterprise, you are going to deal with the reality, which is you will have legacy applications, which are still dealing with SAML. And you will have Greenfield applications that you may have written to understand OAuth. But how do they all interoperate with each other? Because again, just because you wrote Greenfield apps doesn't mean that you'll drop support for legacy apps. So what token exchange allows you to do is you can actually, from a legacy app, if it is in possession of a SAML assertion and that legacy app needs to make a call to a Greenfield API, then that SAML assertion can be exchanged for a OAuth token so that you can make that downstream API call. Now, from a configuration perspective, if you want to do this exchange, you have to register a client. And the grant type should be SAML bearer or Jot bearer, depending on what you're trying to exchange. Scopes is an important aspect because whatever you set in the scopes is what will end up in the token. So like any other thing in UAA token-wise, what ends up in the token is an intersection of user's permissions and client's permissions. So with respect to token exchange also, the final token that is generated is an intersection of what was the original SAML assertion, what were the permissions in there, and then what is the client allowed to do. So as part of the actual request, you would be passing the client ID, the secret, and the assertion, Jot or SAML, and the response will be a UAA access token. Now, we just don't take the token and generate your new access token. We perform all the validations before we do that. We have taken it a step further, token exchange, and we allow exchanging tokens within UAA boundary also. Now, this can get a bit confusing. So again, let me explain with an example. Think of an edge application which is making a bunch of microservice calls wherein one microservice could be invoking another microservice and then another microservice. Now, there are multiple ways to secure that kind of communication, but the best way is to always maintain the state of the user, right? But when you're doing that, you don't want to pass the original token all the way downstream because you want to follow the principle of least privilege wherein when an API makes another API request or a microservice makes another microservice request, you want to pass only what is required for that call. So token exchange can help you here because what it can do is you pass that token with more scopes to UAA and it will exchange it for a token with limited scopes that you can then pass downstream. So this way, you are decreasing the footprint of having the token misused for other things because the scopes are limited in the token. Roadmap-wise, there has been a lot of talk about scaling and metrics for other components of CF. We have plans to invest in the performance and scaling aspects of UAA as well. We have started off this work wherein we are essentially, as part of UAA, there are three kinds of metrics that are being generated. Request metrics, database metrics, and VM and JVM metrics. So we have two goals here and one number one goal is that we want to benchmark performance of UAA wherein we can baseline and say that, okay, say two VMs can give you this kind of performance, this level of concurrency and an indicator for when to scale out. So this is something which will be beneficial to operators in terms of scaling out UAAs horizontally. And another aspect is the stability aspect. We don't want to put out UAA releases which regress on performance and this has happened in the past wherein we did some refactoring and turned out that the user's API is dead slow. So our goal is that we want to CI performance-wise wherein every new release that we put out to the community, we want to make sure that we don't regress on performance. So that's something that we want to achieve in terms of performance goals. What you see here is actually a Datadog dashboard which shows you the metrics that we are collecting. So you don't have to use Datadog, but this is one way to visualize these metrics. Multi-factor authentication is something that we are already working on. Initially, the plan is to add support for Google Authenticator followed by other factors like Ubiqui. The way this is going to function is we can enable multi-factor authentication at a identity zone level. What that means is every user who is trying to authenticate has to go through multi-factor authentication period because the policy is applied at a zone level. The token that will be generated will actually have a claim which says AMR which is authentication method reference is MFA. What that means is this user authenticated using a MFA credential. It's an important piece of information because, again, you want to apply policy around did the user perform a multi-factor authentication before accessing a certain app or API. So you can feed this into your fine-grained permission system to leverage it for policy-related decisions. We do have plans to enable MFA at app level, too, wherein not every user has to register for MFA. Only for certain apps, you will have MFA enabled. And only if the user is accessing that application will a step-up authentication happen, wherein the user will be challenged for a MFA credential as part of accessing the app. So this will not happen as part of the MVP, but we have plans to add support later on. So I put this slide in. It's not directly connected to UAA, but something that is close in terms of identity-related decision-making. So we are kicking off a new project which has already been kicked off. It's an incubation. It's called the Permissions Project PIRM. And it's an incubation. It's for solving the fine-grained authorization needs for Cloud Foundry. And they have two charters. One is that the ability to map existing CF roles to external groups. So I mean, you all are aware that in enterprises, typically, access management is done via group memberships. You don't grant access to an individual user. You always do it on a group basis. So we want to leverage that standard for Cloud Foundry roles as well. So UAA has the ability to read group memberships for a user from LDAP, SAML, or OIDC. The idea is that we can feed this into this PIRM system and have it evaluate policy and grant the right kind of access. There is also subsequent work that is going to happen around creating custom roles. So today, roles are limiting. There is only space developer and probably five other roles. But again, from a security perspective, least privilege. You want to give only the access that should be given. You do not have to give the entire space developer access just because they have to view logs. Why do you want to give them the access to push applications, for example? So custom roles will solve that problem for you. MVP for PIRM is to migrate off the Cloud Controller roles to this new model. And behind the scenes, it will be UAA, which will be providing all the identity related information to PIRM as a policy engine. So definitely, we like your feedback. So please feel free to reach out. I'm not sure if the group, there is a group formed already. But this will be part of the runtime PMC. So you can use that handle to provide feedback. Housekeeping. So we are at the end. And UAA project updates, they are available as part of Elastic Runtime PMC. The meetings happen bi-weekly. So notes are shared. It's part of the GitHub repo. So if you want to follow UAA project updates, please subscribe to that repository. And security issues, everyone's focused on security. So if you find any security issues with UAA, please report them to security at cloudfoundry.org. And all things which are deemed CVs and that get patched will be published at that URL. And we do give credit. So it's not like we just say that, oh, something was fixed. We actually say the name of the person who reported it. So I'm not sure what I'm saying. You need to find all the security issues. But I'm just saying you get the credit for it. Finally, a shout out to the team. I have, I think, one member from the team, Shash's here. So none of this would be possible without. An amazing team. And it's not just pivotal employees. So we have people from Dojo contributing to UAA. We have two people from G, Bharat and Henry. And we also have Mikhail, who is from VMware. And we have, I think, people from SAP out here. So they've contributed a lot in terms of, especially, SAML support. The token exchange actually came from SAP. And we are hoping to have them as part of the Dojo program as well. But overall, it's purely a community-driven thing. It's not pivotal. It's pivotal, G, E, SAP, doing a lot of contributions to this project. Yeah, it's Q&A. And there will be an open house tomorrow. And it'll be at creation station on the third floor. It's at 320. There is also another talk on UAA and microservices. That's also tomorrow at 2.40. So thank you all for coming. Any questions? I tried to cover a lot. I do understand that. I will be sharing the slide deck. Just feel free to reach out at the open house if you have any other questions. But happy to take any questions right now. Hi. Hi. So one thing you didn't mention was this user token flow. You talked about the directly browser flows, the token exchange flows. For what scenarios would you see the user token flow? Are you referring to the user token grant type? Yeah, yeah, exactly. So the question was about a new grant type that has been introduced in UAA. It's called the user token grant type. And it's an interesting question. I think it's not either or. It could be depending on the situation. But what the user token grant flow allows you to do is, as a user, you can pre-authorize access for a given application. And that pre-authorization actually is a refresh token. So let me try to explain it in some more detail. So I'm pretty sure you've used GitHub access tokens wherein you go into GitHub's UI. And you say that, OK, I want to have leverage GitHub access in a script that I wrote. And I want to plug in the token. So what you would do is you would go into the UI and say that, OK, I want these scopes, generate me a token. And in order to do that, you will actually authenticate and authorize that access. And the end result will be a token that you will go and plug into your CI system. And then your CI system will be able to leverage that token for its access needs. So that user token grant type does that. So with the user token grant type, you can code a UI or some kind of a management system through which a user can go in and pre-approve applications for access. And that pre-approval results in a token that can then be plugged into your CI systems or scripts or CLIs. Now with UA's implementation, that token is a refresh token. It's not an access token. Because refresh tokens are longer lived. The whole idea is for automated access. So we generate a refresh token at the end of that flow. And that token can then be intern plugged in. So that's how you would use that flow. Token exchange is more in flow. I want to exchange one kind of token for another token. I hope that helps. Any other questions? Yeah, another one. For the, you also showed this JSON web token exchange, so this token exchange. Then did I get it correctly? So that means concerning the scopes that are in a token, they always get reduced. Or is there also an option where you can say, OK, I want to re-impersonate the user and match again the scopes that are assigned to a certain client? You want to do it at the request time rather than at registration time? Well, the point is if we are looking at microservices and I have a communication between one microservice to another microservice. I mean, with microservices, I'm trying to decouple them. I give them a known persistence. I give them a known web container, et cetera. And that means I would also like to do that security-wise, that I say, OK, the offerizations that are required by that web microservice, they're also decoupled. And that would mean I need to have a mechanism to increase the number of scopes or have a different set of scopes. I see. So this is one of the things where we are using the user token grant. OK. Yeah, because then if you have the UAE user scope, then this exactly allows you to do that. But that requires two HTTP messages to the UAE. Sure. And therefore, the question is if we would now go for the JWT token flow, would it allow us to do it with one message? Would it allow you to do what? To do it with one HTTP call instead of having two as we have it with the user token grant. But the token exchange is one call, though, wherein you make a call to the token endpoint with a client ID a secret and the token. But the question, yeah, I mean, when I'm comparing the user token grant with the JSON web token grant, then the user token grant that requires two HTTP messages, the first one to get a refresh token, the second one to get an access token, and the JWT token flow, that allows it to do it with one message. OK, OK, I get the question. So the question is, basically, can I just request a subset of the scopes? Because probably the user token grant type does allow you to do that. So in the token exchange flow also, even though the client may be authorized for 10 scopes, as part of that exchange, you can specify only the three scopes that you need for the downstream interaction. So it's possible. We could probably take that offline. I mean, yeah, thank you. Thank you all for coming. Thanks.