 Hello, everyone. Everyone settled in. I'm the only person standing between you and lunch. So we'll get started. I believe 1.15 is lunchtime. I'm Shree Tumidi, and I'm a product manager at Pivotal, working on both open source and proprietary identity products, and currently working in the capacity of a senior manager of product management. And you can follow me on Twitter at Shree Tumidi. So today, we are here to discuss new features that have been introduced in UAA in the past couple of months, and also where we are going with UAA. I mean, I believe every one of you by now has heard about, like, STO and Kubernetes, and are basically trying to understand where does identity fit into all of this. So I'm hoping I can cover some of that today. So the agenda is to basically not throw new features at you, but just first of all, give you an overview of UAA, followed by new features, talk about Kubernetes, STO, and then some roadmap-related things followed by Q&A. So we'll get started. There's a lot on this slide. So I want you to read bottom to top. Any time we think about IAM and we are dealing with a cloud platform, there are two aspects to IAM, or identity and access management IAM for short. One is on the platform front, because we have to make sure that the right personas and the right systems have access to the platform and what that means. And the platform itself is made up of different things. And it's layers of things. So at the lowest level, you have Bosch, which is the infrastructure orchestration layer. It helps Cloud Foundry be multi-cloud. And we have to think about when operators come into Bosch, what is the security experience we want? Making sure that they, whoever is coming in, is proving their identity and is only able to do things that they are allowed to do. If you move one layer further, then you have Kubernetes, which is the new thing on the foundation front. So if you've heard about CFCR, which is a Cloud Foundry container runtime, it's essentially Bosch-managed Kubernetes. So you can deploy on-demand Kubernetes clusters. But then obviously, we have to think about, again, who's allowed to perform those operations? Who's allowed to create clusters? Who's allowed to push workloads to the cluster? And then we have the on-demand brokers, which provide a standard interface for how services are exposed in this ecosystem. So again, IAM for those. And then you move up one layer further. We have the core Cloud Foundry components, which make Cloud Foundry what it is. So we have the core container runtime, which is Diego routing. Routing has its own API and container networking for East-West traffic, logging, and then finally a Cloud Controller API, which exposes these things to operators and developers. So we are talking about a lot of things here that need to be secured. But the core aspect here is we need to perform identity and access management in a standard manner. But it doesn't end there. Because now, as customers, the whole point of creating a platform and deploying it on-premise or using it from the Cloud is that you want to push workloads. So we have to think about workload IAM or app IAM. I'm going to be using the term workload as a way to represent any kind of application or API or task or function that you plan on running in the Cloud. So that's what workload IAM is. But again, there are two classifications there. You are going to have apps or workloads which run on the Cloud. It could be running within a Kubernetes cluster, or it could be running in Cloud Foundry, or these could be external. I mean, the reality in any enterprise is that things are not running in one kind of environment. They are not running in isolation. You are always dealing with hybrid environments. So you have applications which are in your managed Cloud. But then you also have applications and services which are outside that perimeter. So we want to follow the model of zero trust. Like trust nothing, have explicit policy in place for identity and access management. So from that point of view, when we set out to solve the identity challenge, the one thing that we thought about was, let's create a standards-based approach to doing this. There are already standards out there for how identity is expressed, how users authenticate, how identity information and claims are propagated across trust domains. So that's where UAA comes in. So what UAA is doing is it is abstracting out everything identity-related. And it is providing you a standards-based approach to consuming identity and access-related functionality. So on the far right side, you have users in an enterprise who could be in Active Directory, which is LDAP, or it could be a federated identity store. So it could be SAML or OpenID Connect. But now think about a platform operator experience or an app operator or app developer experience. Do you want to go and learn all those protocols that I hope not? I mean, if you look at the SAML spec, it's probably like 30 pages long. And by the time you're done with it, you will ask yourself, why did I go through it? And what exactly am I supposed to implement? So what we want to do is provide you a standard interface and do basically proxying of protocols so that you do not have to know about all the different protocols that exist out there. So SAML being the oldest one, but then we have OpenID Connect-based identity providers as well. So what we give as a standard authentication and authorization interface or identity interface to platform and apps is actually OAuth and OpenID Connect. It is a much newer standard and I would say a much more lightweight standard in terms of expressing identity and performing authentication and authorization. So I'm pretty sure you all are familiar with JWT, which is the JSON web token. It is a way to propagate identity. And it's pretty much a standard set in OpenID Connect. So if you are using OpenID Connect, the token format is always JWT. But OAuth does not specify that because it deals mainly with access, not the identity. So to sum it all up, what UAA is really doing for you is it is providing a standards-based identity both at a platform level as well as at your app level, be it internal apps or external apps. Some basic concepts about UAA before we get into all the features and road map. Users in UAA can come in two shapes. One is they could be internal or they could be external. So when I say external, these are your existing user stores. So it could be like an LDAP, SAML, or an OpenID Connect compliant identity provider. Now another big puzzle piece is permissions. OK, I'm a user. I prove my identity. But what am I allowed to do? So that is something that we govern via something called as groups. So users get associated with groups. And applications also get associated with groups. So this is a confusing part. Is applications get associated with groups wherein if a user is acting through an application, the application is only allowed to do things which are set at an app level as a permission. So a typical example, say, for example, you have Facebook and you want to use your Facebook account to log into some news website or something. The first thing that will pop up is, hey, do you want this website to receive your profile? But then do you want this website to receive your friend list? But then you get to check the boxes. I want to allow probably profile information, but not the ability to access all my friends. I hope not after the Facebook debacle. So basically, you will see that you are setting access at a user level as well as the application level. And both of them together govern what a user is allowed to do in a given application context. Finally, in any organization, access is driven through groups. So a user gets access to applications based on the groups they are in. So that is a very typical way of performing access management in an enterprise. So a UAA supports this model wherein UAA groups can be derived or mapped to external groups. So it gives you another layer of sort of defining your application-specific roles or permissions. And as I mentioned before, UAA can also connect to LDAP, SAML, or OpenID Connect-based providers. So this is just like a very basic flow of everyone here is familiar with the CF command line interface. And this is just to show, OK, I talked about identity, did a lot of hand-waving around protocols, but what's really happening at the ground level. As an app developer, when you access the CFCLI, the very first thing you have to do is you have to log in. And you provide your username and password. That is actually something which the CFCLI, as a client, passes on to UAA so that UAA can, first of all, authenticate the user. And then it also validates the identity of the CFCLI itself so that it knows that the request has been made by a trusted application. So once it has done all of that authentication and validation of the client, it generates a token, which is a JWT format. And it throws it to the CFCLI. And then the CFCLI is essentially a very thin application. It doesn't have basically any kind of heavy backend or anything. It is interacting with the Cloud Controller API. So what the CFCLI does is it takes the token and say, for example, you want to do a listing of the applications in your space. It is going to call the V2Apps endpoint. But when it does that, it is actually going to pass the token that it received from UAA. And that is what tells CAPI, or Cloud Controller API, what the identity of the user is. So when Cloud Controller API receives the token, it actually validates the token before it does further processing and provides an app listing. So there is some complexity that I've left out of this picture, which is a Cloud Controller does its own authorization, which is based on spaces and orgs. And so that is done after the token validation is successful. So new features wise, the first thing or the most important thing that we've done in the past few months is we've added Google Authenticator support. I'm pretty sure you all are familiar with the Google Authenticator app, which generates one-time codes, which is based on the TOTP or the time-based one-time password. So from a UAA perspective, we are looking at two personas. One is the administrator persona, and one is the end user persona. So this end user could be a developer or an app end user. It could be any user who is accessing an application protected by UAA. From an admin perspective, what they do is if they want to enable multi-factor authentication, you would do so at an identity zone level. So identity zone is a tenant in UAA. So when you deploy UAA, you get a default identity zone, but you can create more tenants or identity zones. So MFA can be, or Google Authenticator, which is a form of MFA, it can be turned on at an identity zone level. Administrators can also reset users' MFA. So in case of a lost device or a compromised device, an administrator can go in and reset the user's status so that they can re-enroll for MFA. On the user front, there are a few things that happen. So users' experience is driven either by an application they access or a command line interface. So let's drive home the use case with the CFCLI. So for example, you access the CFCLI, the very first thing you do is you have to log in, right? You enter your username and password, but authentication is not complete at that time because the administrator has turned on MFA at the identity zone level, right? So at that time, there is an in-line registration that a user has to perform with Google Authenticator. So you basically scan the QR code with the Google Authenticator app and you are set to generate one-time passwords. So next step you do is... So this is the UI flow wherein the UI is going to prompt you for, hey, enter the Google Authenticator code. If it is the Cli, the Cli will provide an additional prompt for username, password, and the one-time code. So unless you enter the one-time code, you won't be able to access whatever you set out to access. So it could be an app listing or you could be accessing a web application. The token will not be generated until the MFA is complete. So this exists today in preview mode. There is one last thing that we are working on from a MFA perspective is encryption at rest for the credentials. So that's something that we'll provide in the next release and then it will be generally available. So what about the future use cases with MFA? One thing that has come up repeatedly is step-up authentication for users. So a lot of the times we've heard that I don't want to generate, I don't want to enable MFA for the whole user community. At the end of the day, it introduces friction in the login experience and you would rather do it on a need basis. And depending on whether you are doing really privileged actions within a system, right? So we would like to do step-up authentication for users so that we don't enable it for all the users. So again, taking like the Cloud Foundry example, we could potentially turn on MFA in the future only for administrators, but not necessarily for all the developers. Now, if you are an organization and from a compliance perspective, you have to have MFA turned on for everyone, then you could do zone level, opt into zone level MFA. But if not, you want to turn it on only for administrators, you could do so in the future, not right now. Another feature that we've added is OpenID Connect Session Management. So that's a handful. Basically, at its heart, what we are providing is a single logout for applications. So let me give you sort of like a simplistic picture of this first. You have multiple apps that a user is accessing. So if you work with SAML and single logout, it's a very similar kind of a flow. If a user logs out of one application, you want to log the user out of all the applications. So how do you achieve something like that? So there is a spec out there called OpenID Connect Session Management, and it provides a way for achieving that using JavaScript. So when a user initiates a logout at an application, this happens today. The top part happens today. The application invokes like a logout endpoint on UAA. UAA session is cleaned up, and in case you were using some other SAML identity provider behind the scenes, we will invoke the single logout on the SAML side as well, and your session will be cleared. What did not exist previously was how do other apps get notification that application logout has happened? So what happens is the other apps, or pretty much all the apps who are using this particular JavaScript library, repeatedly check for the state of the session on the UAA front end. So this is the mind-bending part of the protocol, which is there is something called as HTML5 post message so that when you use that mode, the network traffic, there is not a lot of traffic going back and forth between the app and UAA, because with HTML5 post message, you can, within the browser and a trusted domain, you can check for UAA session without actually invoking the backend. So the app invokes like a check session endpoint on UAA, and then the session state in this case will be propagated to the app and the apps like some other app has initiated logout. So this app would know immediately that, hey, logout has been initiated, so I need to logout as well. So that's how we achieve single logout. So all of this is open source. We've introduced a new library. It's called UAA Singular, and it has been NPM packaged as well, so it's easy to sort of bring into your JavaScript apps, and it works only for single page applications. So if you're using an implicit client or an implicit flow, you can use this library for single logout. Okay. So UAA and Kubernetes. From a UAA perspective, what we set out to achieve was platform IAM for Kubernetes. So in Kubernetes, there is already the concept of a user or a service account, but if you want to sort of bring your own enterprise identity, how do you do that in a consistent manner? So what Kubernetes exposes is open ID connect interface. So with Kubernetes, if you are an open ID connect compliant identity provider, then you can plug in that identity provider into Kubernetes. So this works really well for UAA because UAA is an open ID connect compliant identity provider, but the benefit of UAA is that it does not support just open ID connect, but it can sort of federate over to like a SAML or it could federate over to Active Directory, just simple Active Directory as well. So with UAA, you basically get the benefits of, hey, like there is a consistent way to do IAM across Cloud Foundry and Kubernetes with UAA, and the UAA interface to Kubernetes is open ID connect. So how do you achieve this? So the way we tested this was with MiniCube and we'll provide all of this information separately as well as a doc article, but what you do is first of all, you need to tell Kubernetes what the identity provider is. So UAA supports something called as the OIDC discovery protocol through which a relying party like Kubernetes can discover metadata about UAA. So you need to specify the issuer URL, which is the UAA base URL forward slash OAuth token. You need to specify username claim. In this case, the username flows in the jot as user underscore name. So you need to map that. You also need to map your group's claim and I'll get into the detail of that, but in case of UAA, all the permissions and groups flow in scopes. So there is a scope field in the jot token, so you need to map that to scope. And then finally, there are two other things. What is the client ID? So you need to set up a client for a Kubernetes cluster in UAA and in this case I've called the client MiniCube and a groups prefix. So on the Kubernetes front, it allows you to introduce like a namespace for all the groups that you are propagating to Kubernetes. So I've used the groups prefix of OIDC. So on the coop config side, what you have to do is you have to specify a client ID, a client secret, the ID token, the issuer URL, and an optional refresh token. So one question that we've gotten repeatedly is, hey, like should I use the access token or the ID token because they both look very similar in UAA because they both are jot and the answer is you can use anyone. You can use an ID token or an access token, but please make sure that you do the mapping right because an ID token doesn't contain a scope's claim. It can contain external groups' claims. So you need to do the mapping right. So finally, like if UAA is asserting on an identity, the next step is what can the identity do in Kubernetes? So in Kubernetes, there is a role model already established. It's in place. Kubernetes supports different kinds of authorization. In an enterprise, the highly recommended system is role-based access control, which is simple, easy to understand, and gives you a lot of visibility into your access. So on the Kubernetes front, if you use the cluster binding command, cluster role binding command, you will be able to map a cluster role to a group of the user. So over here, I'm saying that if there is a user group of org admin, then make them a cluster admin in Kubernetes. So once this cluster role binding is in place, everyone who logs in and has a group membership of org one admin, they will be able to go in and perform operations as a cluster administrator. So you could do this at a user level also, or you could do it at a group level. So individually, I could go in and basically say that Sri gets to be a cluster admin as opposed to a group membership. But again, that model does not scale. You want to do this at a group level. The next thing is, so we talked about platform IAM with Kubernetes, what about app IAM? And what do we do today? So how UAA today is used to secure apps is you can create multiple tenants in UAA and you can use that identity zone or tenant to secure your apps, right? So like Pivotal has written their own service broker for UAA. It is called the Pivotal single sign-on service, but so have other foundation members like GE and SAP. So they also have like their own service brokers. But this approach works really well if your app framework supports OAuth and OpenID Connect on the client side. So if you've used Spring Boot, Spring Boot inherently uses Spring Security and it provides you a way to perform OAuth and OpenID Connect based authentication in a very easy way because you just use annotations and you're good to go. So if you're using a service broker, the service broker is basically creating tenants. You can onboard identity providers like SAML identity provider and others. You can perform group mappings. And on the developer side, as a developer, you can use Spring Boot to basically integrate with UAA and get security for your apps. Where it does not work well is obviously if you are not using Spring Boot, then you need to bring your own OAuth library or OpenID Connect library which is fine. It is still a standard. But then your application developers have to understand what is OAuth and OpenID Connect and what are the best practices. So this is where we are looking at STO as a means of getting basically polyglot app IAM without the need for app developers to code in security into the applications. So this is a very, very high level diagram. Like there is a lot more to STO. There are a lot of components out there. STO itself is made up of three things. There is pilot mixer and auth piece. But this is a simplistic representation. We don't have a lot of time to cover everything here. So we have UAA. So UAA is identity provider and identity proxy and its job is to assert identities and any other subjects. It could be a system or an app as well. In STO's model, the way it achieves polyglot capabilities is via a sidecar. And that sidecar is, as the name suggests, sits next to your application and it intercepts the traffic that is coming to your application and performs some common things. And one of the common things being security so that your app developer doesn't have to care about security related things. So with respect to identity and STO, what we want to do is a few things. One is STO by itself provides MTLS. So it provides mutual TLS between apps and services. So there is MTLS communication already in there. So we don't have to do much about that. But the community is right now working on a few things. There is the end user authentication features being added. What that means is you can write a declarative policy which says that, hey, I want to secure this application with Active Directory and I want to allow only certain users who are in a certain group to come in and access the application or the API. If you were to do it in the old way, then you would have to basically write some code in your application to achieve that. But with STO, you just write a policy. So if you look on the right side, we tested the Jot Validation Policy. So if you're familiar with the STO command line tool, it's very straightforward. I mean, there are only two things. You can either create a policy or delete a policy. So you do like a STO CTL create and I've created a Jot Validation Policy here. And with respect to a Jot Validation, you need to specify the issuer, the audience, and the keys URI so that the Jot can be validated. So this is an example of a policy. So there are other policies which STO supports like authorization. So STO supports like role-based access at service and method level. So what that means is if you have a REST API and you want to secure all your GETs and you want to allow a certain persona to perform GETs but not posts. So you could do method level security. You could do that today with spring security if you use like pre-authorized filters, but STO just makes it much easier and makes it policy-driven. So our hope is that we can bring more of STO capabilities into the platform, into our platform, both on Cloud Foundry and the Cloud Native Experience as well as in the Kubernetes Experience, the CFCR. I just want to do a quick time check here. Okay, so we only have one minute and I have two slides. So I'll get through it fast. So roadmap. So I'm pretty sure like you all are using UAA today and a lot of feedback that we've gotten from like our big customers, right? Like I'm talking big banks and retail and we have all kinds of customers is that they don't like this approach of like UAA being shipped in every deployment and UAA being shipped in different layers. So Bosch has its own UAA. When you deploy or do a CF deployment you get another UAA. Now there is going to be CF container runtime and it's going to have its own UAA. Where does it end? Now we will introduce functions and does it get its own UAA? It becomes a nightmare in terms of like managing all these UAAs at an enterprise scale. So what we would like to do is at least on the open source front basically start with like a reference architecture of how to run a shared IAM service. Now shared IAM service is not just UAA but it involves like other security services like CredHub which is for credential management and permissions as well which is another project that we've kicked off in incubation and it deals with fine grain authorization. So there are two dimensions to this solving creating a shared IAM service. One is the product dimension that having a common UAA across platform and all aspects of the platform and for apps as well and being able to do that across foundations. So a typical sort of like a Cloud Foundry customer is going to not have one foundation but like multiple foundations because they want to have like a disaster recovery setup but also they want to get multi-region support, right? So in those situations if you were to have a shared IAM layer which is resilient then you are basically able to reduce your operational burden, right, of being able to replicate the same configuration in so many places. So that's where this reference architecture is going to help you out. So what we want to do as the UAA team in this case is test out these different configurations and provide that reference architecture and one of the biggest things we have to do is pick a persistence layer which are layers because we have to be multi-cloud so we cannot just pick like Google's like distributed database and expect customers who don't want to use say Google and want to use Microsoft. So we want to provide like options. This, I'm going to share these slides so I'm not getting to the details of these but this is what the team is working on right now. We are doing, we are extending our OpenID Connect support so today we support OpenID Connect via the UI and we are adding a native support as well wherein we can collect the username and password and pass it on to the OpenID Connect provider. On the interface front, we want to revamp our UI and we also want to revamp our CLI. There is a lot of improvements that we could do there and we would like to get into that. Finally, there has a lot that has happened since I last presented at the summit and now there have been a lot of communities that have gotten kicked off around security. It's not just Cloud Foundry anymore, there is Kubernetes out there, there is STO and recently we kicked off another, I would call it a working group. It's called SAFE, SAFE Access for Everyone and the charter for this group is Authorization Interop. Today, there is only one standard for authorization which is Zakamal, it works, but it doesn't work also, it's very heavy and what we have set out to do is first of all, figure out what providing a reference architecture again for authorization in a hybrid environment and what that means and basically go from there and see if we want to create a standard around it. Questions? Yes, yeah, okay. So the question was what are the reporting capabilities that exist in UAA today? So in UAA, we have audit events that get generated for all administrative and access and so those events can be streamed via Syslog. So in Cloud Foundry, there is a component called Logurgator which is able to sort of stream out all the events not just from UAA but from other system components as well and you can then have like a SIEM product like Splunk or some other product wherein you can do correlation and you can have reporting there but out of the box, we do not provide any reporting capabilities, so to speak. You can plug in your own reporting into UAA through the Syslog channel. Does that answer? Okay, awesome. Any other questions? Rajesh? Yeah. So the question is like, is the reference architecture on the roadmap or are we asking for feedback right now? So it's on the roadmap because we want to test out what we propose and make sure that it can work at enterprise scale and it can work in a multi-cloud environment. So the point of creating a reference architecture in the open source is to help the community but then we would like to take that reference architecture on the pivotal side and sort of weave that into our enterprise offering so that pivotal customers in this case just get that support out of the box. Sure. So the question is not all apps are in the cloud. It's a hybrid environment. So do we need to use the same service? The answer is it depends because if those applications have to interact with apps and APIs on the platform, there should be some trust set up because they all either are trusting common token server like UAA or UAA is capable of performing a token exchange with a provider that the external apps trust. So and we support both the models. So one of the goals of the shared IAM service is to be able to provide that service to apps off the platform also. And we do that today with the service that we provide as part of pivotal. But since we use standards, nothing is stopping the external app developers from leveraging the same server as long as you can talk the standard or you can use the token exchange to get a compliant token to make a downstream call. Okay. Thank you everyone. First coming time.