 So, good afternoon. Five minutes fast hour. Let's get started. In my session I'm going to talk about user account and authorization server and the experiences we made at SAP. My name is Martijn de Boer. I'm working as a product owner in a security and crypto topic for SAP. Okay, a little bit closer. We have been working as a platform security team for many years and since one and a half years we're looking into the topic UAE and how can we make it usable for applications. So, let me shortly introduce SAP. So SAP has helped hundreds of thousands of businesses to take advantage of technology. We started in the 1970s, starting with R1, evolving over R2, R3 to the cloud business. And one of the pieces of cloud business is HCP Cloud Foundry, which is using Cloud Foundry as a baseline. SAP means 76% of the world transaction revenue every day is passing through an SAP system. And while we have a very solid rock inside on-premise deployments, also cloud customers are getting very relevant for SAP. So in 2015 we roughly made 2 billion revenue in the cloud. So what I'm going to talk about today, I have three topics for you. First of all, for those who don't know the details, I'll give an introduction about Cloud Foundry, user account and authorization server. Then talk about how can you make it useful for applications? So what mechanisms do we have to integrate UAE into business applications? And the third topic would explain what we have done at SAP to simplify integration and make using the UAE really easy. So, let's start with UAE. What is the UAE? The UAE is within Cloud Foundry the central place where users and authorizations are managed. So that means if a user, for instance, locks into the platform using the CF lock-in command, what's happening is its user is prompted for credentials, usually using a password. And then these credentials are sent to the UAE. The UAE will validate, will issue a token, which then can be used to call different Cloud Foundry components. The UAE is very strong when it comes to REST APIs. So there are lots of APIs for managing the different entities known inside the UAE. It is rather restricted when it comes to user APIs. So the UAE, it has an admin UI for logging in, but otherwise it doesn't really have a rich set of admin UIs. One of the aspects that makes it very interesting for application development is the support of multi-tenancy. So usually you don't see it a lot as being used in Cloud Foundry itself, but the UAE has support for multi-tenancy and also I'm going to explain what that means. So let's start at authentication. The UAE has different kind of mechanisms for authentication. So the first thing it has is an internal user store. That means using this internal user store, you can authenticate with password against that store. And the users in that user store can be grouped hierarchically to assign offerizations to that user. As a management API, there is a SCIM API, which is an internet standard for managing users and groups. And that's also supported by the UAE. But the UAE is also pretty good when it comes to integration in common enterprise standards. For instance, there's the support of LDAP. So LDAP is a common protocol, for instance, supported by Microsoft Active Directory. So if you have Microsoft Active Directory, you can authenticate your users using username and password against Active Directory. You can do a mapping of LDAP groups to the UAE groups again. And as management API, management API would directly use the LDAP protocol. So when it comes to enterprise requirements, the UAE sometimes has some challenges for use. For instance, when authenticating with the internal UAE users, you can put the password policy. But the UAE, for instance, has no forced change of a password. So assume you have a password policy that requires to change a password every 30 days. Then after 30 days, the users will get locked. And the user need to get the email password reset flow to get going again. Another protocol that's supported by the UAE is the SAML2 protocol, also very well known in the enterprise environment. With the SAML2 protocol, if you hit the UAE, you can select a link. I want to look on with my favorite SAML identity provider. Then the browser would get redirected to the SAML identity provider and then authenticate using the methods supported by the SAML identity provider. Similar, so with authorization, so if your SAML identity provider has a mechanism of grouping users, then you can also map these SAML user groups to your UAE groups. Last protocol that's supported for authentication by the UAE is the OpenID Connect protocol. This is feature-wise very similar to SAML2, but rather adopted in the cloud world by cloud identity providers. What does it mean when you have enterprise requirements like strong authentication? So the UAE itself, it doesn't have something like pluggable authentication. That means if you have requirements to support a certain kind of authentication, then you need to delegate it to one of these standard mechanisms supported by the UAE. So in our environment, we have the requirement for strong authentication. And luckily, we have a SAML2 identity provider that supports strong authentication. And so what we do is any kind of authentication needs to be delegated to that SAML identity provider. For web applications, this is rather easy because it's just redirected to my SAML identity provider. However, when it comes to integration with the command line option, then you need to go through CF log in minus SSO. This will write a URL to the UAE where it can then authenticate. And if this is configured to support authentication using your SAML2 identity provider, SAML2 identity provider can prompt to factor authentication, and then you get the passcode which you copy into your command line and are then authenticated towards Cloud Foundry. So multi-tenancy. So in application development, multi-tenancy frequently is a very important feature if you want to share a certain set of resources. So assuming you have backend services which are tenant aware, then you can share these resources across multiple tenants. So the UAE, it has a concept of identity zones. And an identity zone is something that has own users, own award clients, own groups, own identity providers. And it is address using zone.login.ucfdomain. So that means if I now have an application and assume I have two customers on that application, if I then make sure that one customer gets redirected to the UAE with customer1.login.whatsever, and the other customer gets customer2.login, etc., then I'm making use of the multi-tenant features of the UAE. I get a JSON web token issued, for instance, and this contains the information about my identity zone and then the backend application can make use of that to separate, for instance, two separate database tables. So now I explained what functionalities are offered by the UAE. How do we integrate that into an application? And for application integration there are essentially two protocols that are supported by the UAE. The first protocol is using the OAuth protocol and JSON web tokens, and the second protocol is using SAML2. So let's look at OAuth and how to use that for integration into a web application. So with OAuth2 I have different entities. So I have a resource owner. This is the one who's owning access to a certain set of resources. Usually it's a user. And then I have an OAuth client. Usually this is my application that does something on behalf of a user. Then I have an authorization server. The authorization server is a component that authenticates the user and which has the capability also to issue a token which is then sent for authentication to the resource server. So from a user perspective, how does it look? I have a user, that's my resource owner, and this user is now going to access an application. This application is then redirecting the user to the authorization server, which is the UAE. The authorization server does certain checks and it will authenticate the user and also in OAuth there's a term of a scope. A scope is a permission for a user to access one or more resources. So assuming everything went fine, then the UAE is redirecting the browser to the application and the application will now take the client ID and client secret. It has registered as an OAuth client. We'll talk to the UAE. And the UAE is going to issue an access token. Now the application received this access token and this access token can then be used to access back-end services and sending this access token as an HTTP header. So in our world, this is usually a Node.js or a Java application. There will also be other kind of applications. Okay. The other option of integrating is by using the SAML 2 protocol. So what has recently been added to the UAE is the capability to act as an identity provider. And when acting as an identity provider, the user would access the application. It would get redirected using the SAML service provider protocols to the UAE. The UAE would authenticate the user, issue a SAML assertion, and the SAML assertion would then be sent back to the application and the application validates the SAML assertion assuming everything is fine, authenticates the user. So essentially these are the two protocols that are supported by UAE. So either taking the Oout protocols or taking the SAML 2 protocols. So what do we do to simplify integration? And there on our side, we have some boundary conditions. And the boundary conditions is we cannot give developers any kind of more or less restricted access to the UAE. So that means our developers should have the permission to create Oout clients. But when it comes to access to the UAE, you need to be very careful not to give developers too much permissions. If you grant them the permission, for instance, to create Oout clients, then they also could create an Oout client having the admin permission which you probably don't want to do. And therefore we need to be very restrictive on the permissions we're giving to developers. Another point is we're using Oout 2 for microservices. So that means we rely on these JSON web tokens and inside our applications, our backend applications, we do an offline validation of the JSON web token. Another point is we need to have very simple application integration. So it should not be that every application needs to invent these Oout protocols themselves. Instead, there should be a component for doing that. Then from SAP History, for long times, we had the approach that an application should declare the permissions it's going to check. So it should not be buried somewhere inside the coding. The experience is make a declaration and it gets much easier to handle. So how do we do that? Our approach is to come up with a service broker. So we have a service broker for integrating applications with the UAE and the second piece is we have an application router as a standard Oout client which we recommend to all of our applications. So what does a service broker do? Essentially, applications need to define their artifacts. So they need to define what are the scopes we're using for functional authorization checks, what are the attributes we're using for instance-based authorizations, and then this is what needs to be passed to the service broker. And the mechanism we're using for that is to use the service broker parameters. That means our applications, they generate a service instance and then they pass a so-called extra security JSON which contains the information about scopes, attributes, etc. So the service broker will generate an Oout client and the service broker will take control and governance about the scopes that this application is able to request. For instance, if an application comes and says we would like to have the UAE admin scope, no chance we won't do that. So does it look from development perspective? Assuming I have my developer and this developer wants to develop an events application and he says, okay, I want to have something like an event reader. I want to have an event manager and so he defines the role templates in this extra security JSON. He will define I need to have a scope to read events and to have a scope to comment events. Similar event manager gets these events. Additionally, the event manager gets a scope for managing an event and because the event manager, that one needs to be able to differentiate between different countries. Therefore, we'll define an attribute country. Then we can define a role event reader which is similar to the role template because it doesn't have any attributes and for the event manager, we'll have an event manager DE for Germany which has a country attribute DE. Similar, we have an event manager US with a country value US. So this is what applications need to pass to our service broker and then service broker takes care of creating the all out clients, managing all these role templates, for instance, to a SAML group. The other component which we provide applications is the application router. So application router probably could also be implemented using the routing services but we didn't have a closer look into that yet. So essentially what the application router does is this is the component that acts as our all out client. So that means it very well integrates with our service broker, taking the service binding, taking the data from the credentials of the service binding and then if a request hits the application router, the application router will check, has this user been authenticated, if it has not been authenticated, it will send the user to the UAE for authentication and to enforce authentication. What the application router additionally does is it will act as a reverse proxy sending the request to our resource servers and we have put some additional security functionalities inside the application router. One is CSF protection. So a request that comes from the browser needs to have a certain HTTP header set otherwise it will not pass the application router. And also what we do is our intention is that this JSON web token never leaves application router or resource servers. So that means the user agent here is going to establish a security session but it will not pass the tokens to the application router itself or to the browser. Good. Advanced topics. So the JSON web tokens, they're nice but sometimes you get to the limits. One of the limit is if an application is using a lot of functional authorizations then this JotToken will grow in size and what we have experienced in our Cloud Foundry environment is that there's a limit of 8 kilobytes so as soon as they are beyond that limit the JotToken is being blocked by the CF router. I mean you can work around that but still at some point in time you will get beyond that size. And therefore what we're looking into currently is two ways. So if you have one application calling another microservice then what you'll see as a requirement is either this service requires a different set of scopes. I don't want to forward my tokens so I need to have the functionality to request new tokens. And for that there is a, it's called the non-standard OAuth authorization code supported by UAA which allows you doing so. The other thing is sometimes you have applications that need to do something in the background. Some householding activities for instance. And for that you need to have a technical user and what we're using for that is the OAuth client can either do something on behalf of the user. This is how you usually know it but also there's a thing called client credential flow where the OAuth client can act on its own behalf. So and so this is what we're using for technical user communication. So we started with UAA one and a half years ago so first looking into trying to understand it having the feeling we find something new every day. And in the meantime we start contributing back. So what we already did is contribute an attribute API for getting attributes into the UAA. Then there were contributions about vulnerable library versions. What we're currently working on is OAuth's armor barrel flow. This is if you have server to server communication and you need to authenticate the user with SAML assertion without using a browser. In the SAP area this is a very popular flow. Then performance improvements. So at some places UAA is making a lot of SQL communication which needs to be improved and so working also on that one. And what we have as corporate requirement is we need to support a password change dialogue. This is also something we'll contribute back to UAA. Coming to the summary. So what we found is UAA can also be used for authentication authorization of business applications especially when making use of the identity zone multi-tenancy features of the UAA. Authentication authorization. If you know the boundary conditions this is all included inside the UAA. But to make it really usable for application integration you need to have a service broker. Otherwise it's very difficult to maintain all the entities inside the UAA. With that I'd like to thank you and open up for questions. This is the topic Plugable Authentication which is not available. So we have done that to authenticate against our HANA database. So it is possible but you really need to dig into that. So the question was is it possible to plug in a different user store. The standard user store of LDAP, SAML2, OpenID Connect etc. This is all supported but there's no API for plugging in another custom data store. My questions. You already have seen some links. Talk freely on where to start with your HANA. So the question is multi-tenancy authentication. So in the UAA for default there is no title authentication. So it means the only way of doing that is to delegate another identity provider. Then you have to choose SAML2, OpenID Connect and then you need to. So at SAP we have protocols for the LTP which supports this two-factor authentication using a password and code that gets generated by mobile device. And the trick is for web applications it's quite straight away. If you want to do it for the online interface, the family has this option minus SSO. The CF locking minus SSO which will then bring the URL of the UAA which you can access to get. More questions? Okay. Otherwise, thanks a lot and I'll be around for some more minutes.