 Hello, everyone. Good afternoon. My name is Tian Wang, and I'm a product manager with Pivotal, working in the identity space. So prior to joining Pivotal, I worked for over six years consulting with enterprises on identity and security. And I'll be talking to you today about identity from legacy to microservices. So just as an overview of the talk today, I'm first going to go through a brief history of identity in the enterprise and how it's evolved over time to where it is today. Following that, I'm going to give an overview of UAA, which is Cloud Foundry's native identity service, as well as the SSO service tile, which is a service broker that allows utilizing a lot of the capabilities of UAA. And then after that, we'll dive into a lot of the customer use cases that we've seen used out there for UAA and SSO, including a lot of how our customers have been able to leverage this to their advantage. So first, just a primer about identity. Identity is something that all companies have to take care of, whether you're talking about customer users or your employee users or even your service-to-service applications. Identity is one of the cornerstones of security in that it's something that you need in order to be able to authenticate and authorize users for your applications. So this is something that almost must be there from a security perspective. But identity itself has been something that's evolved over time in the enterprise. People started to realize the importance of identity over time and just how much of it they need. And as a result of this, the way that identity has been implemented as solutions within enterprises has changed over time and adapted for what the needs have been. So in the beginning, people had their applications and, hey, anyone could access your application anywhere. And someone started to realize, isn't it a good idea if I check who's accessing my applications and I can secure them somehow and prevent malicious people from doing bad things to my systems? And that's kind of how the identity came to be as a concept for applications in the form of local user stores. And this made sense because application developers could build it for their applications. They could basically take whatever they needed to have and build that towards their apps and store it wherever was convenient for them, whether that was a file, a database, a directory. And that was very simple. You could set it up in a development environment. You could get up and running right away. Now, this works great when you're talking about a single application. But as you start to be kind of an enterprise, you realize no company just has one single application. That's going to grow as you start to build out more and more applications. So when you have hundreds of different applications, this is not going to be a maintainable model because you're going to be duplicating users across a lot of these applications. And your application developer is going to be thinking, well, I want to do it this way. But they did it another way. And there's just no agreement among how to do it. So you have all of these different implementations that are being reinvented. So you're basically reinventing the wheel over and over again. And when you have all of these applications with their local user stores, people are going to have to remember different logins and different passwords. And what do people do when that happens? They start reusing their passwords. So now you've got a security issue as well where everyone's trying to reuse their passwords and logins, or else they're going to forget about it. And you're going to have to spend more on password resets and all of those items. And this is going to get very expensive to manage. Because not only do you have different applications out there that have their own users, you have to go in and change those users, remove their access, do password resets. And I don't know if any application developer has ever said, I want to build an admin interface for my users for support to go in and change people's passwords. So this is not a scalable model across enterprises. But this is kind of where identity first started across companies. So as enterprises began to mature in the area of identity, they realized that since we're one single company, why can't we just have one user store, one location, where I have all of my users and all of their data and all of what they need. And all of my applications can use that. So that's where enterprise directories came into play. And this would be something like an LDAP server, like Active Directory, where you would basically share your users and passwords for all of your corporation's applications. You could manage and deprovision in one central place. You'd be able to basically handle the applications within your company in a more straightforward fashion. So this was a good model. And it made sense for many, many years. Companies still might be in this state today. But as companies began to kind of evolve in the technology area, there became more and more of a need to work with other companies, suppliers, partners, hosted applications, things like that, that are going to have separate users or separate applications that your users need to access, where their users need to access your apps. And that's where this no longer became a good model for sharing users, because you didn't know whether or not you could send your users to them. You might have firewalls that make it hard. You don't want to open that up to the world. So this then runs into the same issues that we had with the user stores that were local, in that you're duplicating a lot of your users. You're having a lot of the data. The management issue becomes an issue again. And do you share your sensitive data with other people? Like if you give someone else your passwords to your users, aren't they just going to get hacked and then go into your company and take all your stuff as well? So this is not something that can work across a lot of different enterprises. So as a part of this kind of dispersion of identity into different companies then, this idea arose that, hey, we should be able to federate users from other companies or federate our users to other companies so that we're using each other systems, but we own the data that we should be maintaining. So SAML 2.0 came out as the leading standard for federation. This is like early 2000s. And that really became a way to then say, this is my user. They're logging in at my location, so I have all of their data, all of their passwords. And I'll just send you an assertion or a claim that this person is who they say you are so that you don't have to maintain of this any data for me and I don't have to worry that all of this stuff is being left on your side. So not only are you keeping a lot of that security safe, but you're also able to manage your users and take care of how they're being the lifecycle of that user without having to worry about other people. So this was very good when it first came out for the web apps that were built during that age. But this model doesn't really handle beyond the case of web applications. So yes, you could log in towards a monolithic web application and it would be able to federate with other companies. But it doesn't really handle non-interactive flows. It's something that also doesn't really work for service-to-service calls because it's really you're logging in through a browser. It takes you to a login page. That doesn't work with CLIs. And it doesn't work between the services. So a lot of these weak points then became kind of a these worked back in the day because a monolithic web application could support that kind of thing and things worked. But when you started to get more and more API usage on the back end, you found that you could no longer use this model sustainably as you start to grow in terms of your API ecosystem, especially in kind of a microservices-oriented world. So this was definitely not microservice friendly. So as that kind of evolved within the businesses out there, OAuth 2.0 came into being. And this was really something that was geared around distributed systems and federating users among enterprises. It handled both the user flows that were out there and still had to be supported. But it also extended it for API-to-API calls so that you could do a lot of these things non-interactively. And it used delegated authorization as well to help you manage that security as you gave these out there to other entities. So this was kind of a good step in terms of microservices friendliness. But one thing that was not really addressed in the initial spec for OAuth is that they didn't cover how authentication would work. So this kind of arose as an open question of, well, how should I be authenticating my users? Because the spec doesn't really talk about that. So then the last step then to bring authentication also in line with authorization came OpenID Connect. And that was essentially a standard built on top of OAuth 2.0. So when you're building something that's OpenID Connect compliant, you'll also be using OAuth behind the scenes. And it established the standard of an ID token that said, this is how I should authenticate a user and this is how I should represent that it authenticated successfully. And so that was basically then something that finally brought us to where we are today in terms of what are all the protocols out there that support identity in the ecosystem. So businesses, of course, are still changing today. And we're still seeing that movement towards more and more distributed systems, more ecosystem proliferation, more microservices architecture out there. But one of the main pain points that are out there is that companies have heavily invested in various stages in these past ways of handling identity. So they're going to have spent a lot of time and effort on developing these directories or these integrations that essentially bottleneck them towards moving towards cloud-native architecture. And it gets very expensive for them to then become more agile and secure in the identity area. And that's where we at Pivotal have approached this with the UAA and the SSO tile to address a lot of these pain points that exist in the businesses out there. So the three main pieces that we put together when we tackle identity is the UAA, which is the open source identity service for Cloud Foundry. And it handles authorization and authentication today. So it'll basically support authentication via SAML, LDAP, and OpenID Connect. And it's also an authorization server that's compliant with OpenID Connect and OAuth 2.0. And what it does then is it allows you to convert a lot of these legacy authentication protocols into new age OAuth and OpenID Connect compliant tokens for your applications to use. The second piece that we brought in was the single sign-on service broker, which uses entirely UAA and Cloud Controller functionality. So if you're thinking that this isn't something you can achieve on your own, it actually is. It basically makes it a lot easier for operators to configure UAA by handling a lot of the multi-tenant policy configurations and a lot of the overhead that comes with using that in the open source site today and makes it available as dashboards for the operators to use. For app developers, it helps take that experience and make it self-service for app developers so that they can go in and manage their application clients, their OAuth configurations themselves, without having to work with IT and go through a lot of red tape to get that done. And SSO also helps the app developers in that it integrates with a lot of different frameworks, such as Spring Boot, to basically take the configurations and map those into the frameworks so that you're no longer worrying about that piece of integration, which is always the question at the end of it. And where Spring Boot comes into the picture, then, it is that it is one of the frameworks that we support to help application developers have a framework on which to build their applications in a secure manner. Spring Boot comes with OAuth libraries and OpenID Connect libraries as ways to help developers get started. And it manages a lot of configuration of those through auto-configuration and other concepts that basically help a lot of application developers not have to worry as much about managing identity within their apps. So how does this look put together, then, within the Service Broker, UA and Spring Boot itself? So what happens first is then an operator will go in and create an integration with the Enterprise Identity Federation systems. So this can be any system out there that's kind of a standard Enterprise Identity Source. With that, they'll be able to make it available for the application developers on the marketplace as basically service instances that can be bound to their applications to run. And basically, from this step on, the Cloud Connector that comes with SSO will help to do a lot of the automation of security enforcement and runtime and basically map that into Spring Boot in the form of declarative code that the developer can use in their apps. And with this combined, then, it allows a lot of autonomy for developers who can basically work on this on their own and develop within their own spaces and not have to go through IT for a lot of these things and also increases the productivity in terms of being able to build out applications fast. And this can be used for user flows, service-to-service flows. And you can also start using our latest feature, which was recently added to UAA for Token Exchange to handle a lot of those service-to-service API halls. Now, the typical end-to-end flow of a lifecycle then as a part of this flow is that whenever a user or an application, it could be a separate application or maybe even the application calling on its own behalf, wants to then request authentication and authorization, it's going to first make a call to the UAA and the SSO service, which will then, if necessary, broker that communication with any of your identity providers. This could be a legacy LDAP server. This could be some kind of SAML ADFS or SiteMinder if you have those. And it might also be able to help with your OpenID Connect providers like, say, Google. You want to integrate with that. Once the user is logged in, and it could also be an internal user, we support those as well, we send a token back to the client or the application that can be used for downstream API calls. And this is where you start kind of working in a more microservices-oriented architecture in that you can have your resource servers or your API sitting in any location. It could be on Cloud Foundry. It could be off Cloud Foundry. But these same tokens can be used by these API servers. And these API servers can check back into UAA and say, is this token valid? Or they can do it with offline validation through token keys that are provided from the authorization server itself. And with this kind of model for a single instance of application and number of APIs out there, you can provide your applications with microservices-friendly identity. Now, what are a lot of the benefits then that exist across the different personas as a result of combining UAA, SSO, and Spring Boot? So for operators, there's a lot of benefits that come natively within Cloud Foundry and BOS, just because UAA is one of the Cloud Foundry components in there. So you're going to have zero downtime upgrades and a lot of the operational maintenance pieces provided. For app developers, of course, we have the self-service capabilities that makes it very easy for you to configure what you need for your app without having to worry about others. And you can integrate with frameworks that will help make it easier for you to build your applications. And finally, for security administrators, this really becomes a powerful item in that you're able to leverage your existing identity provider where you've built years and years of users and data and policies and compliance items that you don't necessarily want to take somewhere else. And we provide guides and things like that to help you integrate and set that up and basically start using that without bottlenecking your developers who can then start building against those right away. So some of the common use cases that we see out there on how single sign-on and UAA are used, first one being, of course, application onboarding. So this could be new applications that you're building for the first time on Spring Boot, or this could be legacy applications that are already integrated with an identity provider you have out there. And now you want to move them onto Cloud Foundry, make them cloud native. So the main thing is we only require that your applications be OAuth aware. And this can be done through frameworks such as Boot or any other libraries that you have out there. And we help take the legacy protocols that you have out there and convert them into tokens for your applications to use. And this really gives an ability to allow for fast migrations and fast development. So in one example, we had one customer that was able to onboard 20 applications in the course of six weeks with their legacy identity providers. A second common case that we see out there is that as there are more and more companies who are doing business with more suppliers, business units, more partners, you're going to have a lot of different identity providers that are providing disparate user sets for your applications. And this can be a pain to manage, especially because you don't want to build your application to talk to five or six different identity providers, set up all those integrations, and maintain those integrations. So through the multi-tenant self-service architecture that UA and SSO provides, essentially you can define a lot of these integrations once and make them available through the service marketplace, either as configurable items for them to select or if you have to restrict them, kind of disallow them from certain orgs or spaces. And only then the appropriate people can use the corresponding identity providers they need. And lastly, of course, is another use case, which is less common, but still happens very often in the enterprises, switching identity providers. So identity systems change pretty often, and that leads to very expensive rewrites of applications. And most of the time, this is not something that's handled by application developers, but it lands on the application developers plate to be able to handle these types of situations. What happens when you have this kind of a service broker idea in between your identity providers and your applications is that not only can you build your applications to be cloud native, but you're also protecting yourself from the impact of upstream systems changing and kind of putting a lot on your plate to handle in terms of that integration. So this is definitely something out there that we've seen customers leverage when they're using the UAA and SSO as an identity broker for their applications. Now finally, of course, I like to just wrap up with some tidbits from a few of the customers who've been using UAA and SSO over the years. So the first customer is a company called Manulife that does financial insurance work out in the United States. And they've been using the SSO service for the last one and a half years. They have over 100 applications that are bound to the SSO service. That's both a mix of new applications they've developed and applications they've migrated from legacy builds. They have 200 to 300 active developers across PCF, and all of that is managed by three operators, including management of the SSO service tile itself. Prior to moving on to the SSO service in UAA, they were primarily using IIS and IWA to connect to an AD backend. And they had very limited RBAC capabilities for which they required a lot of red tape to go through IT and setup. And that could take days or weeks to get done. After they were able to migrate onto PCF and the SSO tile, they began to use SAML via ADFS to connect with their AD backend, so leveraging the same set of data that they did before. Their developers began to be able to use that self-service UI to create their OAuth clients, configure their scopes and their groups and what they needed to do their business logic. And without IT being in the way, that whole process went from weeks to days in some cases. And as a part of this process as well, their developers began to use Spring Boot. And even though Spring Boot abstracts the concepts of OAuth for you at the implementation level, it helped them to learn about how to build cloud-native applications that leverage OAuth in a microservice-friendly fashion. And one item that they're definitely looking forward to is that in the future, if they do change their enterprise identity source, and that's a possibility, but as always it's in talks, then they'll be able to do this without impacting the applications that they've already built on top of the platform. And lastly, I'd like to conclude with a quote from one of our other satisfied customers, General Motors. So this is a quote from Matt Brooks, who's their GM IT fellow for cloud platforms. Pivotal single sign-on service tile provides a trusted on-demand connection between our cloud applications and General Motors identity providers. Offered directly from the Pivotal cloud foundry services marketplace, the SSO service plans eliminate the need for per application trust and removes hours from the traditional deployment process. The SSO tile reinforces our Galileo initiative to spur innovation by having developers focus on code, not infrastructure. So in conclusion then, UA and SSO is something that we believe kind of help tackle a lot of the pain points that exist out there between kind of the legacy identity and how it was handled in enterprises and where people want to go in the future. You can learn more about the UA and SSO service at the links provided here, and feel free to reach out to us on CF Slack or Pivotal Slack as well. If you have any questions, we're always there to help support you guys. And we always, of course, on the open source side, appreciate contributions because there's always more out there than there's always ways to make identity better. And it's very helpful as well on the open source community to help improve that overall experience. Thank you. So now I'll go ahead and take any questions. Yes? Is there an easy way? So if I have an unusual identity provider, how easy is it to write a, I don't know how it works, a plugin or a module to integrate it with UAA? That's a good question. Is there any specific protocol or thing in mind that you're thinking of? That's a good question. And I don't think we've quite explored that on the front of that. But we have had open source contributors provide integration options into the UAA platform before. Like, the entire SAML piece was, I believe, donated from an open source contributor. So it's not unusual for us to see that come in through the open source channels. So how do you want to do the integration? UAA has a set of protocols. So it has the OpenID Connect protocol. It has the SAML protocol. It has the LDAP protocol. And therefore, if you're looking for integration through those protocols, then you can just do it by providing an implementation of one of those protocols. Mm-hmm. Right. And then if it's a new protocol, that's somewhere where it might be some new feature or pull request against the UAA GitHub. Hi. One question. We have Cloud Foundry, of course, running. And my question is, this has already in UAA. What do you propose should we, to be an identity provider, create that platform, use a different UAA, deploy it again on Cloud Foundry itself, or use the build in UAA and just align that? Actually, we wanted to split this Cloud Foundry users from the actual identity provider. Right. That's a good question. And what we recommend here is that with the UAA that already comes with Cloud Foundry provides the ability to use kind of multi-tenant identity zones to supply a lot of that functionality yourself. And that is the piece that the SSO service leverages. And what we tell clients to do as well with just UAA on its own so that you can kind of save a lot of the overhead of deploying your own UAA and kind of take advantage of what Cloud Foundry provides already with Bosch. Can you run UAA outside of Cloud Foundry? Because we're basically looking for an open ID connect server. And all of the offerings are not very nice to use yet. So you can run UAA outside of a Cloud Foundry. That comes with kind of overhead in terms of maintaining the upgrades and doing a lot of that operations piece yourself, which something that comes with kind of having an outside of Cloud Foundry. So it's something that's definitely possible. But one of the things that we kind of like don't recommend as much in case you already have Cloud Foundry available. So if there's no more questions, thank you for your time. Happy to answer any questions up here as well after the talk.