 Hello everyone, I'm Shree Tumidi and I'm the product manager for UAA and I've been with Pivotal for three years, mostly managing UAA and also the proprietary identity service for Pivotal, which is the Pivotal single sign-on service. So let's get into the agenda for today. So this is by no means a UAA overview talk. We only have 30 minutes and if I were to get into some kind of an overview, I think it would take upwards of an hour. So today we are going to be focusing on feature updates that we have done in the past couple of months and a look at the 2017 roadmap and the major features that are planned for UAA and finally some housekeeping things and followed by Q&A. So let's get started. So I said no overview, but just to make sure that people are in the right room, I'm going to explain what UAA is and then you can figure out whether to stay or not. So the what, why, and the how. So what is UAA? I used to think that it is user authentication and authorization, but when I joined I was told that it is user account and authentication. So I don't know how that ended up being the name, but I tend to refer to it as user authentication and authorization. Why do we have it as part of CF? So mainly initially when the project was kicked off, it was with the intent to secure Cloud Foundry and the different interfaces which make up Cloud Foundry. So there is the Cloud Controller API and then we have different system components like Diego, aggregator and the intent was to secure the platform from an authentication and authorization perspective. But over time we have added features in UAA in order to make it like a first-class service which can be used for securing workloads that run on the platform. It actually doesn't really matter whether workloads run on the platform because we follow standards-based approach to authentication and authorization. So wherever your APIs and apps are running as long as they trust UAA as their identity server, we can secure it. And how do we do it? So we do this based on open standards. So there have been a lot of standards in the industry around authentication, authorization and user management. We chose to stick with the standards listed out here. So there is OAuth for delegated authorization, OpenID Connect for identity, single sign-on, SAML which is also again for single sign-on, but it is a much older protocol, LDAP because we need to. I wouldn't recommend securing things with LDAP, but we have to do that for some of our customers. And then finally SCIM which is System for Cross-Domain Identity Management and it comes into play when you are using identities which are internal to UAA and how users are onboarded to UAA. So let's get into the feature updates. Some of these things were added to the product a long time back, but we haven't done a lot of blogging around some of the core features, so I'm going to take this opportunity to basically present the latest feature updates. So starting off with OpenID Connect Enhancements. So I'm not sure if you're aware, but UAA is an OpenID Connect Identity Provider. It's similar to how Google supports single sign-on and it supports the OpenID Connect Identity Provider profile so does Azure and now so does UAA. This was added some time back, but lately what we've added is something called as the discovery support. Now you might wonder like what is this discovery support, what are we discovering here? So if you are familiar with SAML, any time you are onboarding a SAML Identity Provider there are two ways in which you can onboard the Identity Provider. One is by just providing the metadata which is like an XML file which represents the configuration for your Identity Provider. The other way is to provide a URL which if you hit the URL you can basically get the latest of the Identity Provider configuration. So on those lines, OIDC or OpenID Connect also supports a discovery profile through which you can download the latest metadata and you can discover information about the Identity Provider. So with respect to UAA, it is available at login system domain well-known configuration for OIDC and as with any feature of UAA, this is multi-tenant as well. So if you were to have created like a separate zone for UAA then that configuration would be available at that subdomain.login system domain and every identity zone in UAA is essentially an OpenID Connect Identity Provider. So that's about the Identity Provider support but as with any Federation protocol there is another aspect to it which is the Relying Party support. So from a Relying Party perspective what we are doing is for existing OpenID Connect providers out there we are able to trust the authentication and the claims coming from those providers. So we have tested this integration with Google Azure. We ourselves didn't test Ping, one of the partners did. Actually Foundation members GE uses Ping heavily and they were able to test the OpenID Connection, sorry, configuration with Ping. So coming to the details of the configuration itself we have support for attribute mappings. This comes into play especially for custom attributes because OIDC has a standard user schema. So if you look at the RFC you will see that there are the extended user attributes but beyond that if a provider wants to share custom attributes which need to flow through to the application so things like some employee ID or a location of the user. So those kind of things can be mapped to a schema in UAA which is referred to as an attribute mapping and it's very valuable for applications wanting to receive that information from again like the perspective of just receiving a user profile or to make some downstream authorization decisions. So we also support something called as mapping external entitlements to UAA scopes. So you all are aware that in UAA we have this concept of permissions which are referred to as scopes and these scopes basically define what the access is to a certain API or it could be some resource. So what we can do is we can map the entitlements which is external group memberships to UAA scopes. So if suppose you onboard Azure and you want to share some external group information but you want to create a mapping policy which says that if the user is an admin in the Azure directory then I want to provide this so and so UAA scope from an API security perspective you can do that. We also support persistence for these particular attributes. Now from an organization perspective you may not want to create another claims store for users. You want to use like the external provider as the definitive store for user attributes but there are situations wherein you want to have the applications call back into UAA to load more information about the user. So in OpenID Connect there is an endpoint called the user info endpoint and if you choose to select persistence for the external claims then they get persisted in UAA. So if you do not have any stringent compliance considerations around where claims are replicated you can choose to persist them in UAA as well. Finally on the relying party side we also support discovery of external OpenID Connect providers. So similar to how we do discovery when we are an IDP if we are a relying party you can specify the URL to your OIDC provider and we can discover the rest of the information. There is no need to specifically say where is the token key, what is the issuer, what is the token URL to get a token. So it just simplifies the onboarding and the overall sort of like lifecycle management for the provider. Future work wise what is planned for OIDC is we have good coverage in terms of IDP and relying party profiles so we are confident that we can go ahead and get an OIDC certification. This is a program that is run by the OIDC foundation basically to certify that UAA supports the OIDC profiles as an identity provider to begin with and we'll eventually get the relying party certification as well. Okay this is a heavy slide. I've tried to put a lot on this slide so let me try to work through everything. So in the open house today one of the key themes was okay I'm using UAA how do I rotate the keys and the different credentials that are present in UAA. So the reality of running identity server in the enterprise is that you have to manage the lifecycle of the keys and the various configurations which are essentially falling under the umbrella of credentials. So with respect to UAA apart from the user passwords which are governed by a password policy and if it is an external user store then we don't really manage the user password. Apart from that we have different credentials that UAA is using either as a consumer so we have client secrets right so if you are going to onboard a OAA client you basically generate a secret and that is used for identifying the client but how do you rotate that secret from you know like there might have been a breach with app data and you need to rotate the secret but then how do you do that without affecting other instances of the app. So there is an existing model that is used by other providers as well wherein the old credential continues to function while the new credential is introduced into the system. So with credentials there are two models right you have like a shared secret kind of a model which is like a client secret but then you have a sync like a PKI structure as well wherein you are using the credential for either signing or for encryption. So with respect to shared secrets what we've done is with client secrets we've introduced the concept of having the old secret and the new secret both work in tandem so if you have multiple instances of the application the old secret will still continue to function as well as the new secret and once you are confident that all the app instances have been updated you can just retire the old secret by basically deleting it from within the client configuration now there will be scenarios wherein you don't want the old secret because it's been compromised and you can do an immediate deletion of it as well so apart from that from an asynchronous perspective we have like the jot signing keys right and the SAML certificates and private keys because UAA is generating tokens and those tokens are being signed with UAA's private key so how do you rotate something like that so we have introduced again the concept of specifying multiple keys and basically you set something called as a active key ID so active key is used for signing the tokens whereas all the other keys can potentially be used for validating the tokens so the way the key management is done via the API is we have the identity zone API which is used for configuring every zone in UAA including the default zone so you can use that to set an active key and a list of keys and you can use the token keys endpoint so you will see that it's not token key and it is token keys because now we support multiple keys to be present which can be used for validating the token because there may be outstanding tokens which have been signed with the old key which is not being used actively but you do not want to have failures on those tokens again in situations wherein there is a breach you will remove the key immediately which will cause all the existing tokens to be invalidated SAML certificates and private keys is pretty much the same model wherein we manage the keys via the identity zone API again and with SAML again there are two profiles we have the identity provider and the service provider profile so with respect to the identity provider profile we have signing the assertions and encrypting the assertions and from a service provider perspective we are generating an authentication request which is signed so we always do signing with the active key but the other keys are still there for the relying party or the identity provider to validate the signature of the assertion or the authentication request what's the future of this so when I explained all of this we expect the devil operators to do a lot with respect to generating these new credentials and setting them as active but what are we doing as a platform to make this all easier so we have a new project which has been introduced into incubation it's CRED Hub and it is going to be responsible for all key management and secret management for the platform so this is something that we are going to integrate at a Bosch layer or a Bosch level where in manifests which are in possession of the keys and the secrets will be the manifests which are in possession will no longer have the actual credential in there but it will just be a reference to a credential in CRED Hub so we have plans to integrate that further with that further for credential generation and rotation okay token exchange flows is something that we have added over the past couple of months we have added different varieties of it one is the SAML bearer token flow and the other one is the Jot bearer so let me explain to you with a sequence diagram so this is going to be a tough to explain so let me take a stab at it so suppose you have an external application and that external application is not using UAA as the identity provider so it has another external identity provider that it is using for its single sign-on and API security if that application has to call into API which is secured by UAA it is not in possession of a token to do so so the way this use case came to us was via OpenStack users who have an existing identity provider which is Keystone and they just want to do an in-place exchange of that token which is generated by Keystone and get an exchange, get a token through which they can access the Cloud Controller API so typically if there was a browser in the middle then all the mediation would happen through the browser as with SAML wherein everything flows through the browser you get redirected to the identity provider it generates an assertion and then you get redirected back to UAA which in turn generates an access token after the assertion is validated but if you want to do this in a native manner like script it, it's hard and that's where token exchange comes into picture because with token exchange there is no need for a browser in the middle to have an assertion like identity provider or an external application may be in possession of an assertion or a jot and it can exchange it with in this case UAA for an access token that can be used for accessing other services another example is in enterprises you have to deal with applications which are legacy they are not using the latest and greatest of protocols so if you have an ecosystem of legacy applications and APIs which need to call into the newer sort of cloud native APIs or apps on the platform then you have to deal with different token formats so token exchange makes that possible wherein you have an older format token you send it to UAA and then that gives you an access token that you can use to access apps and APIs protected by UAA so from a standards perspective there is a RFC for it those are the two RFCs but it goes beyond just token exchange another thing that we plan on adding is the jot bearer for client authentication now it sounds a bit cryptic but basically what it is today UAA supports client secrets for authentication so any time a client has to identify itself to UAA it uses a secret and based on that we match the hash and say that okay this client is valid but imagine again in like IOT kind of a situation wherein devices have already been provisioned with certificates that's their identity so typically with asset management what you do is that you have devices which are tied to a cert as an identity and you do not want to add another secret to the mix because then you have to deal with the life cycle of that client secret so with the jot bearer for client authentication every client which follows this model will be able to identify itself using its cert so it can basically sign a assertion which validates its identity which proves its identity as opposed to having a client secret as having to present a client secret so enterprises where there is heavy use of provisioning certs for assets and they need to do basic what should I say a token acquisition flow they can use the existing cert as the identity rather than using the secret so opaque and revocable token support with this so out of the box UAA today supports JWT based tokens basically jot tokens are things that can be validated offline but we added an additional token format called as the opaque token so the question is this just leads to more confusion like there is already so much confusion with how to use OAuth and then we dump like two more token formats on you and then you think okay oh my god what am I trying to do which token format should I use so some you know like this table is to sort of clear some of that confusion so jot by nature can be validated offline the reason why jot exists is because it with distributed systems offline validation works much better and it just reduces the number of network calls that you have to make for validating tokens but same is not the case with opaque tokens but they exist for a reason and the reason is you may have requirements around not having the clients actually be able to read what is in the token so I'll give you an example so in OAuth right you have a resource server you have a client and you have the authorization server whenever app needs to call into an API it requests an access token from UAA but if you are using jot then the client actually has the knowledge of what's in the token and you have situations where you don't want the client to know what is in the token it's only meant for the resource server now you can solve it with something like encrypting the token itself but the way we have done this or implemented this is using an opaque token wherein it's like a string it's an opaque string it does not actually mean anything to the client but client is supposed to just pass it to the UAA which will tell it what is actually in the token if you want to maintain claims confidentiality you should use an opaque token so opaque tokens by nature are persisted but you can do the same with jot also so the question is why would you want to persist jot when they are validated offline the reason is if you are having highly privileged flows within an application so not all applications are created like you have applications which are meant for privileged access and the kind of operations that are performed within the application are privileged in those scenarios you want always the latest state of what the user permissions are which only the STS or the token server can tell you so in those situations you can either use jot which is persisted or you can use an opaque token because we have the ability to always the latest state of a user or a client permission future work wise what we want to do in this area is from a configuration perspective you can request opaque tokens on a per client basis but we don't enforce it it's something that you do at request time and coming to JWTs being revocable that is something that you can do on a zone or identity zone basis you can give more configuration what should I say bandwidth around that wherein you can configure the token formats on a user client combination and you can also enforce token formats at a client level so when I was creating this slide as like I do not know how our customers understand which library to use for UAA so this is to clear out some of that confusion so from a client side integration perspective so UAA is implementing all of the server side flows right but on the client side how do you integrate with UAA so we have UAAC and which is essentially a Ruby gem and it is backed by a Ruby library which is the CF UAA lib and it's I consider UAAC to be more of an admin tool which is used for basically admin flows in UAA like onboarding users managing clients managing providers so that's something which we have in maintenance mode right now and Spring Security OAuth is a developer focused sort of like an integration library for UAA I say developer focused because it deals with the OAuth client configuration so if you want to integrate an application with UAA you can use something like Spring Security OAuth and you get that integration and there is no need to write any native code for integrating with UAA you should know that we have a rewrite planned it's not something that is maintained by the UAA team it is maintained by Spring Security but the kind of rewrite that we are planning is so if you are aware of Spring Boot there are there is a lot of OAuth capabilities which have found their way into Spring Boot so we are trying to create like a clean separation between OAuth implementation and what is in Spring Boot so that's why the rewrite is happening we also have a CF Java client again this is not just for UAA because it's for also by the name it's also for the Cloud Controller API but it also provides to all of the latest API support for UAA so anytime we add new APIs to UAA there is a corresponding CF Java client version also which supports those things we recently introduced a singular SDK it is a client side SDK for UAA in JavaScript so this is something that we did for some of our internal projects but it's definitely something that you can use with your single page apps as well and we have plans to add support for Node.js and finally we announced this big partnership with Microsoft and moving a lot of .NET workloads over to the platform and there is definitely a gap in terms of UAA not having some de facto .NET SDK so that is something that we'll focus on okay so I try to cover some amount of roadmap within the feature updates there is a separate roadmap as well so bear with me so we are planning to add multi-factor authentication and this is basically if you are aware of multi-factor authentication there are different providers out there there is Google Authenticator which is widely used and there are other things like Ubiko Authy and Toofre so we are going to start with Google Authenticator integration and I think the key takeaway for you should be how we are going to accomplish this integration we are going to do this at two levels one is to enable multi-factor authentication for the entire identity zone that means a user is not considered authenticated if they don't complete a two-factor authentication so if you basically don't use the code from your Google Authenticator app you are not considered authenticated and you won't be able to access anything beyond that we also want to do something called as step up authentication wherein instead of enabling it for the entire authentication domain or identity zone you can enable multi-factor authentication per app so a typical use case could be that you have certain applications which again are dealing with privileged access and you want those applications to prompt for multi-factor authentication but not necessarily every app out there from a usability perspective so depending on your compliance and security requirements you can enable the multi-factor authentication policy finally on the multi-factor authentication it's not just from an authentication perspective typically you will see that anytime you are trying to reset a credential you are prompted for a second factor because you are again performing a privileged action for your account so we have plans to integrate that flow into something like a password reset for UAA wherein if you are trying to reset a user's password in UAA as a user that is as an end user flow then you are going to be prompted for a second factor fine-grained authorization service I think it's been on the back burner for a very long time so there are some very specific CF platform needs that are driving the need for an authorization service a fine-grained authorization service today we have some gaps around how fine-grained authorization is done on the platform so we have canned roles of space developer and org manager in CF and you cannot go beyond them you cannot split those roles into low-level sort of resource actions and permissions another sort of a gap is the ability to map those CF roles to your existing enterprise entitlements so this is something that we have heard from a lot of customers both on open source and on the commercial front is how do I derive something like a space developer role from an existing held up entitlement so those two needs are becoming really evident and a major gap in terms of our identity management strategy with the platform and we plan on addressing those but beyond that there are new services that are being continually added to the ecosystem so there is CredHub which is performing a lot of which is going to be performing a lot of credential actions which are privileged and you want to secure it at that level not coarse-grained but fine-grained authorization potentially like a credential level and other CF services so definitely there is a need for like a common service now the question is whether it's going to be part of UAA or it's going to be a separate service so this is something that we have not still decided on but we've definitely decided on building a service so whether it is part of UAA or not is immaterial coming to some of the other architectural aspects we plan on following access control list approach or ACL approach where in every resource has a ACL which contains multiple entries per user multiple entries with each for a user or a group so we have plans to follow that kind of a model for fine-grained authorization and delegation is something which is key to fine-grained authorization so by delegation I mean so if I as a user want to delegate some permissions out to another user or a client but only do so on like a selective basis I don't want to delegate all of my rights so that's essentially impersonation but I just want to delegate like a subset of the rights I should be able to do that and then finally as with UAA which secures not just the platform we want to do this for the service as well wherein it's not just meant for securing the CF platform but we want to extend it for applications and APIs too so if applications and APIs have fine-grained authorization requirements then you should be able to use the service there are some other features that we are actively working on one of them is performance testing so in the morning Eric touched upon how in Diego they've done some performance testing to basically create like scaling indicators we plan to do the same thing with UAA and we plan to integrate it into like a CI system because we don't want to regress on our performance indicators so that's something that is a track of work that the team is actively invested in and then we are doing some major documentation as well one of the things that has been challenging lately is to keep up on the UAA Slack channel with all the questions that we keep getting around what is OAuth how do you onboard X provider Y provider so there is definitely a lack of documentation on the product front and we plan to sort of solve that in a persona based approach where we are planning to have an operator guide and a developer documentation by the way so we have like a standard API doc set right now as opposed to something living in GitHub we plan to also have identity provider integration guides so this is another area where we've lacked a bit in terms of keeping up with all the integration guides finally there are other things that we are doing around account management which is account linking which is the ability to link account across identity providers and skim 2.0 support so UAA today supports skim 1.1 but lately there has been a lot of enterprise adoption around 2.0 and most enterprise identity systems are supporting skim 2.0 connectors so that's something that we'll look to okay so this is the penultimate slide I believe probably on time housekeeping so there are a few things which I always wanted to sort of discuss in this kind of a group is how to how can UAA project updates be tracked so UAA project updates are part of the elastic runtime PMC so PMC stands for project management council and we have a bi-weekly meeting that happens so this is purely like this is open source it's not related just to pivotal or anything so this happens for all of the projects which are part of cloud foundry and UAA falls under elastic runtime and you can find the notes on what are the recent tracks of work that are in progress and what we will be working on next spread over at least like a month or so so you can find that notes and I have linked it there it's under cloud foundry PMC-notes and a note on UAA security issues as well lately there has been a trend sometimes on security issues being reported to github I would recommend that anytime you have a security issue please email security at pivotal.io we have a proper workflow in place right now and through which issues that come in all the security issues that come in are vetted with the product team with the security team and they are working on the CPSS core and then we basically decide how to patch the different UAA versions so please use that model and CVs now are being published under cloud foundry org under the security folder so previously it was on pivotal.io but now all of the CVs which are related to cloud foundry projects are all under cloud foundry org security so you can get more details about that. Finally before we go to Q&A I want to take a moment to thank the entire identity team everything that we have done in the past I would say a couple of years wouldn't have been possible without an amazing team and during the keynote we talked about balanced teams and how diversity plays a major role I mean I'm proud to say that the UAA team is highly diverse from a perspective, nationalities and also from all the different companies that we work for so that is the current identity team because at pivotal we rotate people a lot but that is what the team is today so Bharath from GE I have a few people in the room Phillip, Helen Jeremy and Jen Mikhail from VMware, Priyata I'm the PM and we recently had a PM join, Tien thank you for coming on board that's it questions oh sure sorry so it's not necessarily a UAA integration but more of a platform integration so the initial phase is going to be the integration of CRED hub with everything BOS related in terms of generation of credentials so that's something that will show up soon from a pivotal perspective it's going to show up in the next version yeah but this is again you know like we are going to take a phased approach to introducing or moving credentials into CRED hub so we are going to introduce the dependency of a CRED hub server on the BOS director and then we will eventually move the credentials there is another phase in which all of the credentials which are part of like vcap services so at an app layer if you are managing credentials under environment variables those are also things that will eventually move into CRED hub yes I don't I don't have much insight into the decision making there because it's a separate team which deals with the architectural you know like aspects of CRED hub but I do know that with spring we do have integration with vault so on the client side so that's something that we will be able to achieve with entitlement mappings so if you have an external identity provider and you already have a certain you know like group membership we will be able to map it to a space role or an org role so right now it is two steps because you have to create a user in UAA which represents that external identity and then you provision that user with more roles but when we have this entitlement mapping there is no need for you to pre provision the user you can just create a mapping which gives them the right access so this is something that AWS does as well wherein you can just map you know like an existing external group membership to an AWS role yes so the mappings themselves are IDP specific so if you create a mapping for a certain group membership external group membership it will come into play only if you are authenticating via that IDP definitely from a workflow perspective you have to take into account how those mappings will be done across those identity providers because it's going to be a privileged operation so you cannot have that kind of duplication yes yes that will have to be but there has to be a certain level of trust okay I think we've probably 10 minutes over okay thank you