 Hello, everyone. I'm Shree Tumidi and I'm a senior manager of product management at Pivotal. I've been product manager for UAA, but most recently I've moved into a different role as the product lead for security of the platform and in this role I'm overseeing IAM as well as other aspects of security. But today it's all about IAM, so let's get started. So a quick overview of the problems that UAA solves when it comes to cloud foundry, platform and for applications. UAA is an identity server. You can also refer to it as an identity proxy. So in an enterprise you have different ways in which users are authenticated and authorized and those could be disparate systems, but UAA is able to connect to these systems in a standard based approach and is able to present a consistent identity to the platform and for applications on the platform. So these standards are SAML, LDAP, OpenID Connect. So UAA is able to use those standards and federate an identity to different components of the platform and for applications. So it has different roles. On the platform front we have two kinds of platform now. We have the cloud foundry application runtime and we have Kubernetes. So UAA is able to secure them with the tokens that it generates and there are other aspects of the platform like routing, container networking, Bosch itself and UAA has a role to play in that too. I do have like concourse and other things missing but UAA does help concourse and credit hub with its authentication and authorization as well. On the application front, since UAA is a token server, it can be used to secure applications and there are different kinds of applications and workloads that could be running on the platform. So you could have web applications, microservices, functions and plain old services themselves and they could also be using UAA for their identity integration. We do go one step ahead and for applications that run off the platform, if they need to interact with applications on the platform, UAA has a role to play there too because from an identity standpoint, we are using standard space identity so it doesn't really matter where the application is running. So that sort of covers the different bases in terms of where all UAA can be plugged in. So in today's session, I will be covering some recent feature updates to UAA and I'll talk a little bit about what we are doing, the areas that we are investing for in the future. So UAA is now an OpenID Connect certified identity provider and this is something that we achieved a few months back. So the recent version of UAA, I think starting with v60, that's what is listed here, we are an OpenID Connect certified IDP. There are two profiles so there is UAA acting as an identity provider and then we have relying party support too so we have not certified that. What we have certified to begin with is the IDP standard. The next feature is OpenID Connect with Password Grant. So UAA does support federating out to external identity providers using OpenID Connect. So this support already existed but we have enhanced it now to support a different grant type which is Password Grant. The use case basically is if you have an OpenID Connect identity provider, there are two ways that you could be connecting to it. You could use a browser agent and redirect to the IDP and have the user login at the IDP but another way to connect is browser less experience and it comes in very handy when you have to deal with enabling authentication for command line interfaces. So with this particular grant type, UAA is able to do a browser less authentication to external identity providers and this is something that involves UAA connecting to external identity provider and performing an authentication through a back channel as opposed to a front channel of a browser. This feature was contributed by SAP and we have people in the room here so shout out to them for helping us with this use case. So let's walk through what's happening behind the scenes. So let's take the example of the Cloud Foundry command line interface. So everyone has used it. So as an app developer, when you perform a login, you are basically going to take two routes. You could perform a login through the UI for single sign on but now you can actually present credentials, external identity credentials within the CFCLI. So you enter a username password and optionally a one-time code of the external provider, not UAA. So that's the difference here. So we are not collecting the username password for a user in UAA. We are collecting it for the external identity provider. The CFCLI doesn't need to care though. It uses the same flow. It collects those credentials and posts it to UAA's token endpoint and it has the username password and the MFA code or the one-time code. UAA then acts as a client to the external identity provider and presents the same information to the external identity provider using a back channel. Once the IDP validates those credentials, the IDP generates a token and presents it back to UAA. So what you are seeing here is UAA acting as a relying party to the external IDP. Once UAA validates the token, it generates a UAA token for the CFCLI. Once CFCLI receives the token, then it hits the Cloud Controller API to get a listing of applications and since Cloud Controller API trusts UAA tokens, it's able to validate that, validate the signature and other aspects and then provide the resources to the CFCLI. So in this flow, you are seeing like UAA delegate authentication to IDP using back channel. The next feature is identity provider discovery with login hint. So UAA already supports identity provider discovery using the email domain mechanism. So prior to this feature, if you wanted to discover which identity provider to log into, UAA could look up the domain, map it to an external identity provider and know to redirect there. So that is one way of discovering which identity provider you should be going to, but sometimes the application has more context about which identity provider should be used for authentication. So there are scenarios wherein you have a multi-tenant application. Actually, Cloud Foundry is a good example of that. So we have a lot of customers who actually use multiple identity providers to one Cloud Foundry deployment. In that scenario, the application has more context about which identity provider you should be going to. So app could be doing a discovery based on some cookie that is already set or it could be a URL pattern. And then the application can send a hint to UAA saying that, hey, I would like to authenticate using a particular identity provider. In this case, the hint is the IDP alias itself. When UAA sees that request, it obviously makes sure that the request is coming from a trusted application. It does all of its validation. It looks up whether it trusts the identity provider that was passed, like the hint that was passed. And if everything is good, then it will redirect to the identity provider. So this is a feature which helps with discovering which identity provider you should be going to, but with more control on the app side. The next feature is ID token refresh. So UAA already supports token refresh, but previous to this feature, it was only access tokens that could be refreshed, but now we have support for ID token refresh too. So if you take the use case of the Kubernetes command line interface and the Kubernetes API server, they are secured using UAA, ID tokens, not access tokens. So for example, if you are trying to, as a Kubernetes command line user, you try to perform an action like, hey, I want to get some nodes, then the Kubernetes command line interface will ask the Kubernetes API server, hey, can you get me some nodes? And then the Kubernetes API server will validate the ID token. But in this case, if the ID token has expired, then the Kubernetes command line interface will start a refresh token grant flow with UAA, pass its client ID, client secret, and the refresh token. And then UAA is able to perform, like validate those credentials, validate the refresh token, and provide a new ID token. And then the Kubernetes command line interface will send that ID token over to the API server. API server will validate ID token is good, and then pass the response back to the command line interface. So this obviously comes in handy if you're dealing with offline access. The user is probably not in the picture. You're running an automation scenario, and you are dealing with longer lived access. So this is where a refresh token flow comes in handy. So let's switch gears and talk about a new project, which is Permissions. And before I delve into this, let me give a high-level overview of what this project is all about. So this is in incubation right now. It was developed with the vision of providing a consistent authorization experience across all platform components and services. So what does that really mean? We have the Cloud Foundry application runtime, and it has its own authorization built into the API server itself. So it's very hard to extend that feature set. And even if you do that, you are actually building something just for that experience, like for Cloud Controller API. What if you want to use that in different places, like, for example, in a completely different platform like Cloud Foundry container runtime? So authorization is a common concern. It doesn't apply just to Cloud Foundry application runtime. It could apply to services. It could apply to other applications. It could apply to other platforms. So we decided to spin off separate, you know, like a standard authorization service with two use cases in mind. We wanted to develop a role-based access control mechanism. So what that means is you define roles with permissions. They can be associated with users. And then you can make decisions around whether a user can perform a certain action on a certain resource or not. So the use cases were the ability to define custom roles and being able to derive roles from external groups. Why do custom roles matter, though? It matters because if you look at the model today, there are probably six to eight predefined roles in Cloud Foundry, but they are pretty limiting. Say, for example, if you have a space developer access, you can do everything within the space. What if you wanted to just give the ability to manage certain actions related to service instance binding or just to perform some route mappings. You cannot do that. It's like an all or nothing access. So that's not good from, you know, providing the least privileged access. So that's where custom roles come in. So from a status standpoint, this service already has an API that can perform role definition and role evaluation. We are in the process of adding features for the second use case, which is deriving roles from external groups. On the integration of this with existing systems like CAPI, we are planning to first migrate Cloud Controller to V3 before this can be integrated. We basically took this decision because the V2 API has authorization logic pretty much all over code. It's very hard to externalize that into an external service. So we decided that we will first do a migration of Cloud Controller to V3 and then integrate PIRM. In future, we want to integrate PIRM with Cloud Foundry container runtime, and that's under consideration. So platform I am today is you have UAA in application runtime, you have UAA in container runtime, and you have these concepts of roles and tenancy separate in both platforms. So when you think from a customer standpoint, it's very hard to rationalize, you know, like, why am I doing same things in two different places? Why am I repeating setting up roles, setting up access in different ways in two different platforms? So what we envision is we can think of IAM as a common service, which has some common constructs like tenancy and roles, and even tokens, right, like that can be reused across platforms without any special behavior. So what we envision is we have a common IAM experience, we have common concepts, global concepts of tenancy roles and tokens, and they can be used and applied to different resources in container runtime, application runtime, and even in the marketplace because from a customer standpoint, this is one platform and one marketplace. So next is application IAM and what's UAA doing there? So today, when it comes to application IAM, UAA is able to act as a token provider, and it's able to provide tokens to applications and microservices. So these could be end user tokens or service tokens, right? So that's pretty much what is needed from an app IAM standpoint, and we have major deployments that customers have done wherein UAA is being used beyond platform IAM to secure apps also. There is another use case that we support, which is token exchange. So token exchange basically deals with providing limited time, limited use sort of tokens for microservice interactions. So those are the use cases that we deal with on the app IAM front. So if you look at the current state of app IAM, you have, you're using some kind of a UAA service broker, and you are using UAA to configure different identity related settings. So tenants, you are creating identity tenants, you are providing identity provider configurations. On the client side, though, it is a very high touch experience because you have to deal with, you know, as an app developer, do I understand like OAuth, OpenID Connect, which library should I use? It's a burden on the developer having to know about these Federation standards. So it's not as easy as like, hey, I want to turn on authentication to an active directory and boom, I have it. You have to know what are the steps that you have to perform on the application side. So things like how do I validate the token? How do I get more information about the user? How do I enforce permissions? So those are things that you have to know. But what we envision is, we can interplay with the STO on Y capabilities, wherein a lot of these mechanisms that need to be performed on the client side can be done in a standard way within the sidecar. So if you look at the previous picture, you have all these operations that need to be done in the app using an app framework or some library. But in the sidecar approach, all these actions can actually be performed through the sidecar. So basically, think of it as, you know, taking the responsibility away from the application without the app developer needing to code anything. So one side of the equation around tenancy and how policy is set up, that doesn't change much. What changes is the experience of the app developer? Yes, yes. Sure. So the question is, does the app really need to concern itself with the token? What is the app getting? In this model, it can choose not to get anything. As in, the sidecar can perform the validation and provide, like a yes or no decision on whether the request should come through to the application. There are scenarios where you do want to get the token because there is information in the token that an application needs to act on, you know, further, like, beyond what a policy decision is, right? Like there may be user-related information in the token. So in those scenarios, you can have the token be validated on the edge, but still be passed to the application for information. Sure, sure. So definitely, so the sidecar approach standardizes how tokens are validated and yes, it takes that burden away from the app developer in terms of worrying about how tokens should be validated and what is the right way to do it. Think of it also as, you know, it's easier for a platform provider to update anything related to security because they are not now dealing with this proliferation of things being done in different ways and different applications. So it's very easy to maintain a consistent security posture. Does that answer your question? Look into the future. So I'm going to be making some controversial statements here and I want the feedback from the community. One thing that we would like to do with UAA is make a focused effort towards federation. So today, UAA is able to federate to external identity providers. We want to make sure that we tackle all the use cases there and focus our efforts there. So we want to sort of embrace this concept of bring your own identity provider and not rely on UAA's internal user store and native authentication schemes. The reason is if you look at the enterprise sort of, you know, environment, enterprise customers have already invested in a commercial identity offering, right? Like they have an identity system of record. They have a federation system of record. So where we want to add value is consuming existing setups as opposed to creating more features around UAA acting as its own internal user store. So along those lines, we want to improve our interoperability with other cloud identity providers. So one mechanisms that we would like to support in the future is token pass through. So if you look at how UAA manages tokens today, when it receives a token from external identity provider, it asserts and then it generates a token of its own and it doesn't pass the original token. But there are scenarios where you know, customers have asked us for like, hey, I do not want UAA's tokens to be passed through to the applications. I want UAA to be the mediator, but I still want the original token from the identity provider. It's an important use case because that downstream application could be calling out to another API that trusts the tokens from external IDP, not from UAA. So in that scenario, token pass through makes a lot of sense. Another area that we want to invest is service identity. So today, service identity in UAA is a OAuth client. So it's a client ID and a client secret, which is good. It has gotten us far enough in terms of tackling different use cases. But we are getting a lot of feedback around like, hey, I would like service identity to be a certificate as opposed to a credential because certificates have deep roots in enterprises. In enterprise scenario, there is like an enterprise certifying authority, which is provisioning cert identity for the services and the applications. And why can UAA not reuse that as opposed to generating its own set of credentials? So we have plans to invest in this area also and use certs for client authentication as opposed to or in addition to using client IDs and secrets. So there is a standard that is coming up right now, which is PIFI. It is Secure Production Identity Framework for Everyone. So this isn't CNCF right now. And this standard basically helps with service identity interop. So if you see Istio also uses PIFI certificates for services and we would like to use those as a means of asserting client identity in addition to client ID and secret. Finally, enhancing security for tokens. So we would like to support something called token binding to TLS channel. So one of the drawbacks of using tokens is they can be replayed. So if you get hold of a token, you can, if you're a malicious actor, you can potentially use that token in a different scenario and a resource server doesn't really care where it came from as long as the token is valid, right? So how do you protect yourself against token replay scenarios? So we can actually, there is a spec out there. There is a standard for binding tokens to the TLS channel itself, so it cannot be replayed. So if it is being reused in a channel that it was not received over, then the resource server can reject it. It will not allow that authorization to happen. Sure. So the question is, if you do not have an identity provider to use, especially in development environments like a CF dev kind of a scenario, how will things work? So one idea that we have is, and we'll definitely float this and get more feedback from the community, but one idea that we have is it can be used in non-proud scenarios in a limited use fashion to have a better getting started experience. So you will still have it. I think what we do not want to get into is UAA as a system of record in production scenarios. So definitely from a, hey, I want to get started. I would like some bunch of users to be pre-created in the system, and I would like to use those in my dev or pre-proud environments. You can do that. I think what we are trying to not go after our support is using it in at-scale scenarios. There are open-source options. I do not want to give examples here, but we can catch up separately. There are definitely open-source options you can use, but there may be some licensing considerations there and stuff, but there are open-source options out there for identity servers, yes. But I think it will still come back to you. You will have to pay for support anyway. Yeah, so I can see, actually, let me repeat the question. So the question is, client certificates, can we use SSH keys as a means of authenticating? So you could potentially do that. So we see two use cases. One is managed identity that we can be pushing to applications that run on the platform, which could be a standard like Spiffy, but there is sort of external identity that is already plugged in, and yes, we would like to interoperate with those scenarios too. But that would involve setting up trust somehow, because if UAA needs to trust that set of keys, then similar to how SSH keys are exchanged, you need to have trust set up on the server side for you to be able to validate that credential. So, yes. Finally, we are always open to more help in the community. So we have these active projects, UAA and permissions, and there are different ways to contribute. You can go through a dojo program or you can submit PRs. There are other communities that are coming up in this space. So we have the SDO security working group, and it is dealing more on obviously with service identity and identity within the service mesh, and it's a pretty vibrant community. And we are trying to work with them to bring more of the SDO security capabilities to Cloud Foundry. There is the Kubernetes, and then finally, there is the safe working group also. This is for authorization interop, and it's a CNCF sandbox project. It's called safe access for everyone, deals with security and authorization interop in the Cloud. Questions? Apparently, I don't speak loud enough. Sorry, is this work done? Is it in CFCR? Is it work in progress? So the question is the Kube CTL ID token refresh, is this work already done? So yes, on the UAA front, it is completed, and there is the latest version of UAA supports this flow. It needs to be pulled into a CFCR. So from the UAA standpoint, it exists. That support is already there, and then CFCR needs to just pick up that version of UAA, and it should be able to use this integration. And so when the token comes back, I think it's on the next slide you were referring to. How does it map the notion of namespaces and the roles, the Kubernetes roles? That's not covered in this presentation, but from mapping of roles, Kubernetes roles to what is in the ID token claims, at least the way Pivotal is performing this integration is UAA ID token can contain external groups from an Active Directory, for example. Those groups can be mapped to Kubernetes roles like a cluster admin. So that's, you would need to have that mapping in place on a per cluster level, and then that will be enforced by the Kubernetes API server. All right, so UAA is only going to provide identity like this person is, and they're allowed to access it in general, and bit like Cloud Controller, if they're going to go to the Kubernetes system to decide what you're then allowed to do. Yes, so the Kubernetes API server is acting as a resource server. UAA is providing the identity, but the identity and the claims, but the enforcement of what the user can access is actually happening in Kubernetes. Okay, I think we're slightly running out of time. I think Shree would be around for additional questions. Yes. Thank you very much, Shree. Thank you.