openSAPSAP Cloud Platform Essentials Week 5 Unit 1 00:00:07 Hello and welcome to the openSAP course "SAP Cloud Platform Essentials" – Week 5, Unit 1. And this week is now all about security, for which I have my colleague Martin with me, 00:00:19 who is a product owner in our team, especially focusing on the topics of security. Hi Martin. 00:00:25 Hi Sven, and also welcome from my side, again, to the openSAP course. As you know, we will start for security usually with an introduction of the topic, 00:00:37 and as you also know, the platform has quite a number of services, and for this week we will focus exclusively on security 00:00:48 and all the cool features that the platform offers to help you develop secure applications and services on top of the platform. And in the previous weeks, we've also covered the Neo environment as well as the Cloud Foundry environment, 00:01:03 so we'll now do this with security as well, right? That's true – I've brought quite a number of new features with me in my bag for this update of the course. 00:01:12 So unlike in the previous courses, we will not only cover the Neo environment, but also look into the great new features that Cloud Foundry offers us as a new environment that came with the Cloud Platform this year. 00:01:28 And also we covered different types of applications – HTML5 applications, Java applications, and so on. We also covered that in previous courses, but here again, we will do that as well. 00:01:40 We will look at security, and specifically in terms of our runtimes. That's true. 00:01:46 For this week, I basically want to cover those topics. So we will look into those really classic security topics, which are authentication of users, 00:01:59 how to carry identity information securely across the different environments and applications, which is sometimes referred to as "identity federation", and in that context, we will certainly also look into services such as single sign-on – so how we can enable our users to single sign- on 00:02:21 without re-entering their passwords or credentials again and again to authenticate against the services. And usually, after authenticating the users, we have to find out what the user is actually allowed to do 00:02:34 and which data the user is allowed to access, and this is all about authorization management. And again, we will look into those topics, from the different runtimes we offer on the platform. 00:02:45 So we will look at how to do this in a Java-based application in the Neo environment, We will take a look into the same topic for an HTML5 application in Neo, 00:02:56 but as a new topic, we will also look at how to do this in a Cloud Foundry-based application. So we will start the week off with the Neo environment, and we will then end the week with the Cloud Foundry environment. 00:03:09 That's the plan. One other important topic I want to also discuss in this unit is all about the difference between business users and platform users. 00:03:21 You already see them on the slide, so in this unit, in the introduction, we will briefly talk about these two different types of users. But we want to get started in this introduction with another recap of the previous courses, 00:03:39 and I think from the previous courses – if you attended those – you may already know this slide. So one of the key concepts of Cloud Platform is that authentication and identity management 1 00:03:54 are always delegated in any scenario you look into on the platform to what we call an identity provider, or what the industry calls an identity provider. 00:04:04 That's mainly a system that is designed and dedicated to securely managing users. Those users can be of different types – they can be employees, administrators, anything really. 00:04:20 But overall, the task of managing those users securely and especially managing their credentials securely is usually delegated to a system that we refer to as an identity provider. 00:04:39 So it provides identity information to applications that rely on this identity provider to securely authenticate and manage those user accounts. And on Cloud Platform, we basically offer the integration with these identity providers 00:04:59 and want to provide the best possible flexibility to integrate with whatever identity provider you as a developer of the application prefer to manage the user accounts. 00:05:11 And also what the customer is already using perhaps? Exactly, because the point is that for almost any scenario that I have been involved in on the platform, 00:05:22 and that's now quite a number over the past few years, I've never actually seen a requirement from our customers that said: 00:05:30 "Okay, we want to have a dedicated user store with our application because we want to create new users and again new passwords for those and new accounts." 00:05:39 And this is what users hate to do – they hate to keep track of all these thousands of user accounts. And we all know from our daily business that probably every one of us has a huge password list 00:05:52 and user account list for all the different applications that we work with on a daily basis. But instead, what we really want to do is centralize user management, we want to reuse existing accounts that we already have. 00:06:05 And if you look at any sort of scenario, you will usually find out that there already is this system, the identity provider, that keeps and manages your user account securely. 00:06:20 For example, in a corporate scenario where the users are employees that make use of a new application hosted on Cloud Platform, usually you already have an existing account in your corporate user directory. 00:06:34 And then the corporate user directory is the identity provider. For a more consumer-oriented scenario, your user account may be your social account – Twitter, Facebook, Google, whatever it is. 00:06:49 So here again, these social media or social networks are representing the role of the identity provider. And, by the way, they are very rich identity providers – they probably know more than we want them to know about us. 00:07:05 So that's what this picture says – on Cloud Platform, we want to make it as easy as possible to integrate with these identity providers of your choice. 00:07:16 So that's one of the really key concepts, and we will see these key concepts being applied to the units and exercises throughout this week. But we are definitely also offering one identity provider from ourselves as an option. 00:07:27 That's true, and that's what this slide is all about. So if you as a developer want to get started quickly 00:07:34 and if you do not have an identity provider at hand that allows you to quickly set up a number of accounts for testing, you can always make use of the SAP ID service as a default identity provider. 00:07:52 It's operated and run by SAP which, by the way, hosts and manages quite a number of user accounts for us. There are millions of accounts, and I'm pretty sure that everyone currently watching this 00:08:10 and who has attended this course has such a user in that SAP ID service. That's your trial account user, for example, or if you are a customer at SAP, your S-user. 00:08:23 - All of those users are managed... - Or also the SAP community – users of the SAP ID service. So everyone who has a user in the SAP community has a user of the SAP ID service. 00:08:33 That's true. So it's basically our large identity provider that manages the users that we authenticate with our services that we offer, 00:08:46 such as to SAP Community, SAP Service Marketplace, and so on. But that comes with some limitations from the perspective of the developer who wants to develop 00:09:03 an application on Cloud Platform and wants to make use of SAP ID service. You as a developer cannot control who can register a user there. 00:09:12 You cannot simply delete a user from that user base because it's our user base that we manage. Exactly, it's our tenant, it's managed by SAP, so you can use it as it's free by default, 00:09:25 but if you want to have your own tenant where you have full control... Right, then you have to go for the second option on this slide, 00:09:32 which is our cloud-based identity provider that we offer as part of a service in Cloud Platform, which is called the Identity Authentication service. From a technology perspective, that is basically the same as SAP ID service, 00:09:44 but it comes as your own tenant that you as a customer can use to fully control the user base in that tenant, and it even goes beyond those features. 00:09:55 - You can customize the look and feel, the UIs... - Put your own logo in... - Right. And, actually most importantly, you can also control the security level in terms of, for example, 00:10:09 the password policy you set for this tenant and for the users here. So you can control whether it's a more, let's say, relaxed policy versus a very strong policy with passwords that have to be whatever length. 00:10:21 Or, for example, if you are using this for some customer scenario, the requirements might not be as strict as if you were to use it for employees 00:10:31 who needed to change their passwords every three months or whatever. Right, so you can really adjust and control many more things than you can do with SAP ID service. 00:10:41 And really most importantly, you can fully control the security settings of your tenant and control the user base of that tenant. But we also want to enable our customers to make use of their existing identity provider. 00:10:57 I mentioned before that many of our customers look for an option to integrate with their existing corporate identity provider, and that is certainly also an option on Cloud Platform – to integrate with this identity provider. 00:11:12 And for those, we definitely support the SAP ones, which we've had on premise for years, but also from third parties. For example, Microsoft Active Directory – probably one of the big players in that area as well – is also supported. 00:11:26 Right, the only prerequisite to integrate with an identity provider of your choice is that this identity provider should be compliant with a very well-known standard in that space, which is called Security Assertion Markup Language, or in short, SAML 2.0. 00:11:44 It's a very well adopted and mature standard, known not only at SAP but also industry-wide, at many other vendors, and almost any identity provider out there usually supports this protocol. 00:12:05 So this makes it very easy for you to integrate the platform and your applications on top of Cloud Platform with the identity provider of your choice. So, that said, let's take a look at the different user types and which options we offer on the platform 00:12:23 to make use of an identity provider of your choice depending on the user type. Actually, you can see from that slide already that there are almost no limitations. [Laughs] 00:12:34 So let's quickly talk about business users and platform users. You see that terminology all over the place in Cloud Platform. 00:12:43 Business users are those users that authenticate as the end user to the applications running on Cloud Platform. So, for example, if I'm a customer and I'm using SuccessFactors, then I have a business user there managing my employee data? 00:12:59 Right, the business user can also be you as the private user that logs on, for example, as mentioned before, with your Twitter account or whatever. 00:13:09 So the business user is the end user – it's just a synonym for that. - End user of an application? - End user of an application. 00:13:15 And as an end user of an application, I as a developer can decide that the SAP ID service may be the IDP of my choice... - For testing, for example? - For testing purposes, right. 00:13:26 But we definitely do not recommend using SAP ID Service for productive scenarios. - You don't have that much control? - Exactly. 00:13:33 And for that purpose, we recommend using either SAP Cloud Platform Identity Authentication service, which is called here IAS for short. That is certainly our recommendation if you want to rely on Cloud Platform 00:13:47 and the services in Cloud Platform to authenticate your business users for productive scenarios. Or you may also make use of your corporate identity provider – it's up to you which one you choose. 00:14:02 Now, platform users are those users that usually do administrative tasks on the platform. That is usually a much smaller number of users compared to the business users, which can go into millions, 00:14:13 whereas the platform users are usually a small number. You usually have tens to maybe even hundreds of administrators, depending on the size of your organization. 00:14:23 Would they usually be the developers and administrators of your application? Absolutely, yeah. 00:14:28 Those users usually work with tools such as the Cloud Platform Cockpit. - They may also make use of the console client...- Or the Eclipse tools? - Or the Eclipse tools. 00:14:40 As the developer, I usually make use of Eclipse tooling to interact with the platform. And up to spring this year, we only offered to authenticate those platform users with the SAP ID Service – that was the only choice. 00:14:54 We received quite some feedback – not always positive feedback – on this limitation, and this is why we worked very hard this year to extend the options for authenticating platform users 00:15:08 to also make use either of your Cloud Platform Identity Authentication service, which allows you, for example, to authenticate the platform users with a stronger password policy. 00:15:20 So you can extend the length of the passwords and the minimum length of the passwords for those platform users to whatever you want. And – even more importantly – we also received from our customers feedback that they 00:15:32 also wanted to have even stronger authentication of these administrative users with a second factor, which may be, for example, a randomly generated number on a mobile phone app 00:15:48 that basically proves, in addition to the password, that you are really the person who you claim to be when you log in to the cockpit, for example. And last but not least, we also offer via the Identity Authentication service an option 00:16:04 to even integrate with the user base in your corporate IDP. However, that comes with a small limitation. 00:16:09 That is that in such a scenario, you cannot make use of the console client for the Neo environment to authenticate those platform users with the console client. 00:16:21 So that basically gives you a very rich set of options. And with that, let me now talk a little bit about the authorization story of Cloud Platform. 00:16:37 So I as a platform user am assigned to platform roles, and in the Neo environment, those platform roles may be such predefined roles that we have in place for Administrators, Developers, Support Users. 00:16:50 For Cloud Foundry, we also basically offer predefined roles that can be assigned to the platform users. Those are Space and Org Managers, Auditors, Billing Managers. 00:17:03 So basically every environment on Cloud Platform comes with a set of these predefined roles that you can choose from as an administrator to assign your platform users. 00:17:15 And by the way, a synonym for "platform users" is "account members", so in the cockpit there is a navigation item that says "Members" and there you assign these platform users. 00:17:28 For the business users, the story is a little bit different in the sense that you have to be able to assign potentially many thousands, or even up to tens of thousands or millions of those business users 00:17:44 to roles defined by your business applications. So we no longer talk about these platform roles 00:17:53 but here the assignment of business users is to the roles defined by your business applications – that may be more than just one running in an account – 00:18:04 and to do so, we basically allow you to either go into the cockpit as a platform user and assign business users what I call "statically" to those roles defined by the business applications, 00:18:18 but you can imagine that at some point in time that model doesn't scale, especially if you have to assign many business users to potentially also many business roles. 00:18:29 And for that purpose, we offer a concept that in the Neo environment we call "groups", and in the Cloud Foundry environment we have a very similar concept – here we call it "role collections". 00:18:43 But basically those groups or role collections collect one or more application roles into one entity on the platform, and the assignment of the business user to such a group or role collection then assigns the user automatically to all these business roles 00:19:03 from the applications that are assigned to this group or role collection. So you could use here also some properties which the users have to assign them here. 00:19:11 For example, if they belong to a department which operates mainly in America, they should only see data from America or something like that. Exactly. So as you can see on the arrow that goes from business user directly to the business application, 00:19:27 that assignment can really only be made statically, which means you assign a user with ID "abc" to role "xyz", 00:19:35 and as long as you do not change that assignment, it stays there. However, the assignment of the business user to the groups can also be done statically, 00:19:43 which means you assign that user "abc" to a group or a role collection... But then perhaps a group which already has a certain number of roles, so that you don't have to assign each role individually? 00:19:53 Exactly, then you would benefit already from this concept of groups or role collections. But that assignment – as you just mentioned – can also be what I call "federated", 00:20:02 which means based on an attribute that all of these potentially thousands or millions of business users share, and that can be used at runtime at the point in time where the user authenticates at the application on Cloud Platform 00:20:17 to assign the user to that group dynamically – or in a "federated" way – based on this attribute and the value of this attribute. So if the property of the user were to perhaps change and it was no longer the right property needed to access this application, 00:20:36 then he wouldn't have the rights anymore. Right, so this means also from an administrator's perspective, from a platform user's perspective, 00:20:42 that you do not have to maintain those assignments every time, but once it changes, and the value of these federated attributes usually change in the underlying user base, 00:20:53 which can be your corporate directory, then that has an immediate effect when the user logs in the next time 00:21:01 and the assignment is then either made or not made based on the value of these federated attributes. We will look into these concepts especially when we go into Units 5 and 6 this week when we look into the Cloud Foundry features. 00:21:18 There we will actually make use of this federated assignment to role collection. And there we will see how that assignment of a user to an attribute in the identity provider will have an effect on the assignment to a group. 00:21:37 All right, and with that, I'm done. So what have we learned? 00:21:42 We have learned what this week will all be about. We will cover security in the Neo environment as well as in the Cloud Foundry environment. 00:21:51 We will cover security for HTML5 applications, for Java applications, and so on. And we have also learned about some of the major concepts which we will cover and which are relevant for SAP Cloud Platform, 00:22:04 which is on one side the business users and the platform users, also what identity provider you are using, either the default one, the SAP ID service, or the SAP Identity Authentication service, 00:22:19 or your own corporate identity provider. And we have also covered authentication and authorization, so the two main things here. 00:22:29 First you have to identify who you are, and then via authorization, what rights you actually have and what you are allowed to access. With this, that's it for this unit – see you in the next unit. Bye bye. Week 5 Unit 2 00:00:07 Hello and welcome to the openSAP course "SAP Cloud Platform Essentials" – Week 5, Unit 2. Now we will cover the topic of "Securing HTML5 Applications", so let's begin. 00:00:20 Right, so in this second unit we will take a look into the scenario that will be used in Units 2, 3, and 4, 00:00:39 where we take a close look at the Neo environment. And I've brought with me an application scenario 00:00:49 where I hope that many of you will recognize a typical pattern on Cloud Platform, because many of our customers make use of what are actually the two key runtimes for the Neo environment, which are HTML5 and Java, 00:01:14 and usually build applications that make use of these two different runtime environments, and generally implement the UI side of the business application with modern HTML5 technology... 00:01:31 So using the Fiori design language oftentimes and using the SAPUI5 libraries. Exactly, that's usually done in the HTML5 part of the application, 00:01:42 whereas the more complex business logic may either reside already on an existing back-end system, in the corporate network for example, in an existing SAP back end for example, 00:01:55 but they may also introduce a layer in between, or that may even be the only layer for their business logic, which is also on Cloud Platform, and not implemented in JavaScript or HTML5, but implemented in Java, so using the Java runtimes in the Neo environment, 00:02:15 and also make their use of the persistency and other services – document service, whatever that is – in Cloud Platform. But both components of the applications only make sense if they are used in combination and not as only one. 00:02:37 Therefore, they have to play together, so the application requires both components – the HTML5 application and the Java application – to interact with each other. 00:02:51 And that will also be an important topic – also from the perspective of security – this week. We will take a look at that in Unit 4 – how the interaction between the two works. 00:03:07 Also in Unit 3, that will be covered by Unit 3. Now for this unit, we will take a look at the HTML5 part of the application. 00:03:17 The demo scenario of the application, the business scenario, is a simple project management application. So the users of this application can be employees, as an example. 00:03:30 Employees that make use of this application on Cloud Platform to keep track of the time they spent on various projects in the enterprise. That's the simple scenario of this xProject application. 00:03:44 You see the landing page as a screenshot on this slide here. And basically the application should allow me, as a member of a certain project, to log in to this application and record my timesheets, 00:04:03 so time that I spent on the various projects in the enterprise. Whereas there is also a group of users that should act as administrators in this application to, for example, manage these projects 00:04:17 or create new projects, where other colleagues can then join these projects as members. So that's the simple scenario. 00:04:26 So we have the business users and they in turn are split into two groups. And we have the HTML5 application more or less as our front end, and the Java application is then our back end. 00:04:36 Exactly. Or what we will then look at in Unit 4, that we have a REST client, 00:04:43 for example a mobile app or something like that, as an alternative front end. Exactly, so in that scenario you see that the Java part of the application offers a RESTful API 00:04:55 which makes use of the HTTP protocol to expose this business functionality to whatever component wants to make use of it, 00:05:05 And, actually, for this scenario I think we also have a very typical use case for modern-day Web applications. That is that those Web applications offer an API in this scenario to the UI front end, 00:05:19 but also to other sorts of clients that may want to make use of the business functionality offered by the Java part of the application. And in our scenario here that can be, for example, a mobile application, 00:05:33 which is not a browser, it's not a browser that is used by the end users on the left-hand side of this slide, but maybe an employee having his corporate smartphone launch a native mobile app 00:05:46 on that smartphone – that also needs to interact with the back-end side of this application. And as mentioned before, the Java component here can also be replaced by a back end in the corporate network, 00:06:03 but, you know, for the sake of these exercises here, we want to make use of a Java back end. So that said about the scenario, let's take a look into the focus of this unit. 00:06:18 We want to focus here clearly on the HTML5 side of the application, and as mentioned in the previous unit, we need to take care of authenticating the business users. 00:06:35 In the previous unit, we also said you have a choice of identity providers to choose from, and again, as always, the concept of the Cloud Platform is to delegate the authentication to an identity provider. 00:06:46 Since we do not want you to first set up your own identity provider, we make it easy for you as a developer to make use of the SAP ID service as the identity provider for this scenario, 00:06:58 so the HTML5 application will delegate the authentication to the SAP ID service. So we will take a look into authentication of the end users. 00:07:09 We will also take a look into authorization of the end users on the HTML5 side, and how we can actually even access certain information about the user 00:07:21 by federating the information about the user from SAP ID service to the HTML5 application. So with that, you can read attributes about a user – for example, their name or something like that. 00:07:37 For example. So SAP ID service only shares a small set of attributes. 00:07:42 That's, by the way, another limitation that comes with the use of SAP ID service. So you cannot share anything that you want – we basically control what is shared. 00:07:51 We as the operator of the platform decide what SAP ID service – which is still our tenant in the Identity Authentication service – shares with the platform, and that is basically first name, last name, e-mail address, and a display name. 00:08:07 That's just about all that we can make use of on the HTML5 side to show to the logged-in user. But we will see how that works. 00:08:20 So in order to implement authorization so that not every user should be allowed to access the applications, but only those that are legitimate project members or project managers in the xProject application, 00:08:40 we define as part of the HTML5 application in the deployment descriptor, which is the "neo- app.json" file, and I think that deployment descriptor has already been explained earlier... 00:08:53 Yeah, when we looked at HTML5 applications in the previous weeks, we also had a short look at the "neo-app.json" file, and that's the deployment descriptor for the HTML5 applications here. 00:09:07 – And here you also put in your properties, your configuration, for security. – For security. – We haven't used that before – that's the topic of this unit. – Right, right. 00:09:16 And it's quite simple to apply security and authorization rules to your HTML5 application. Basically, you specify in the first step what the authentication methods should be. 00:09:28 So if you want to protect anything in your HTML5 application – so every single source of the HTML5 application should be protected – you would basically choose "SAML" as the authentication method, which is the first property shown here on this code snippet. 00:09:47 However, as you can see here – and this may come as a little bit of a surprise – it says "none" here. And the simple reason for this is that we also have public paths in our scenario. 00:09:55 So if you have public paths that should be accessible to anyone, which includes, for example, this landing page of the application, so the landing page with the login button should be accessible to anyone, 00:10:06 not only those employees that are assigned to a certain role in the application. So in that case, you have to specify "none" as the authentication method, 00:10:16 and then further down in the deployment descriptor file, specify which subpaths should be protected by only users that belong to a certain role. 00:10:28 In our case, the application defines a path which is preceded by "protected", so "/protected/", and anything that is underneath that subpath should only be accessible to users that have a certain role. 00:10:47 In the HTML5 deployment descriptor, you specify that protected access by declaring a permission, and in that case, we have a very coarse-grained permission defined which simply says, okay, "Access Project Data". 00:11:04 Later on, in the cloud cockpit, we will assign a role to that permission, which users can then be assigned to via that path. But it also means that everything that does not have this path, everyone could access. 00:11:19 It's public, exactly, yes. So that's the case. So, for example, the "index.html" file that is shown here on this screenshot from the Web IDE snapshot, 00:11:35 that is still a publicly accessible file. And that's the purpose here of this configuration setup. 00:11:47 So I mentioned that this permission that you specified in the "neo-app.json" file needs to be assigned to a role that the users get assigned to. 00:12:00 That should only be able to access the protected path. So here is basically how we do this later on also in the demo of this unit. 00:12:11 So we will specify a role which we call "Employee", and assign only those employees that should be able to access the protected part of the application, 00:12:24 and then assign that "Employee" custom role to the permission that we specified at design time as the developer in the application in the "neo- app.json"... 00:12:35 And those settings we will do in the cockpit, which are also the screenshots which are shown here. Exactly, so there's a part that you do at design time as the developer, by specifying the deployment descriptor with the permissions, 00:12:47 and then later on, at configuration time, you as a platform user logging in to the cloud cockpit, as an administrator of your account, can do the proper setup to define the roles 00:12:59 and also assign the users in the cloud cockpit to this role that you assign to your permission. And we will take a look at that in a second. 00:13:10 Certainly after logging in to an application, you should also be able to log out, and that's what we do also by specifying a property in the deployment descriptor, which is called "logoutPage". 00:13:23 That defines what should be the page to redirect the user to after he clicks on a logout button in the application. And in order to not fool your browser into showing a cached page, 00:13:43 you should make sure that you define for certain pages in your HTML5 application a maximum age of "0", which means those pages should not be cached. 00:14:01 Otherwise, you may run into the difficulty that even though you clicked on "Logout", the user is not actually logged out because the browser fools you by still showing you a cached page. 00:14:09 Or actually the user is logged out, but the page you see there says the user is still in. We will take a look at how you as a developer can be really sure that the logout is triggered. 00:14:22 We will take a look in the demo at how you can check whether that logout request – because that logout has to be sent to the identity provider – how that logout request can be traced in the browser 00:14:36 so that you can really be sure that your setup works. Right. 00:14:43 And last but not least, we also want to show some basic information about the user. After successful login, the user should see some basic data. 00:14:53 As I mentioned before, with SAP ID service we only have a very limited set of user information available: first name, last name, and e-mail address. 00:15:01 But, nevertheless, that can be accessed also by your HTML5 application by specifying access to an API that is offered for HTML5 applications which is under the path "/services/userapi". 00:15:14 And in order to make use of this user API which gives information about the user, you need to specify that route, the access to this API as a route in your "neo-app.json" file. 00:15:28 And if you did so in your deployment descriptor file, in your HTML5 code you can then make use of a JSON model that basically uses the exact path specified in the routes to access the information about the current user. 00:15:53 And that gives you back a JSON model of the user information that is federated from the SAP ID service, or any other identity provider, 00:16:03 but for the ID service you basically then have this federated user information, such as a user first name, last name, and e-mail address, available in that model and can then show that information in your HTML5 application. 00:16:20 We'll also see in the demo that this information is shown. All right, let's go to the demo, and for that let me first go into the cloud cockpit... and log on to the cloud cockpit... 00:16:41 So what we are using here again is the Neo environment and the trial account there. For the code, if you click below the video, under "Additional Material", just download what you find there, 00:16:56 and then you will also find a link which points you to a GitHub repository where you will find the code for this HTML5 application. Then in the next units it will also be the same. 00:17:08 You can also get the code for the Java application and so on. And you can then just deploy those applications in your account. 00:17:17 Pretty easy to deploy with the HTML5 applications. Just download the ZIP file or clone it to your Web IDE – either one works – and then deploy it via the cockpit or via the Web IDE. 00:17:30 Totally fine. And here, in the README file, we also have the instructions on how to do it, so let's go to the cockpit. 00:17:39 So I've now logged in as a platform user to this trial account, and as you can see, I have already deployed that HTML5 application following the steps shown in the README file on GitHub. 00:17:54 And basically this is now my HTML5 application, and as you can see, it has this permission we specified in the deployment descriptor showing up here, this "accessProjectData". 00:18:10 And it is currently assigned to a custom role which we call "Employee". You create this custom role by simply specifying or creating such a new role, so we can either... 00:18:27 So perhaps cancel here, just delete it, because if the users now deployed their HTML5 application, this role wouldn't be there, right? That's true, so the default setting will be basically like this, 00:18:43 so if you start from scratch, basically you will see a picture that looks like this. You will have the "accessProjectData" assigned by default to all the users assigned as account developers, 00:18:56 so in the members section of your account as developers. However, we don't want to do this – we want to... 00:19:01 So if the learners logged in with their account developer users, so just the simple default user which we have in the trial, 00:19:10 then it would directly work because here the right role is assigned. Exactly. 00:19:15 But we now want to switch that into a true business role... So if they create a second user, and then with that second user also want to access the project, 00:19:25 then they need to first create a role. Yes, let's do that. So as mentioned on the slides, let's call that role "Employee". 00:19:35 And now, basically assign that role to a business user, which in my case, is yet another user on the trial landscape. So you could just create a second trial account, and then you have also your second user use this 00:19:51 and then the numbers – that's your user ID. You can assign that user there, and then as a third step, you need to go back and also add it... 00:20:02 ... and assign the role to that permission, yep. So now we change the "accessProjectData" back again to my newly created "Employee" role and save that. 00:20:15 And here, this "accessProjectData"... so this permission was exactly what we defined in our "neo-app.json" file, right? Exactly, let's go there quickly, let's go to the project, 00:20:26 and go into the Web IDE for a second and see what that looks like... So this is our xProject application, the HTML5 part of it. 00:20:42 And as you can see, I've already opened the "neo- app.json" file, and in there we basically find exactly that permission as it shows up later in our account. 00:20:51 And the security constraints – we have exactly what we had in the slides as well. Exactly. 00:20:57 So, let's give it a try. Let's go into the application again and simply launch it. 00:21:07 And I will do so now in an incognito window because I don't want to make use of my existing session, so this is why I'll open another window. 00:21:14 That's often a good tip: If you're dealing and experimenting with security, if something is still cached or some cookies are still saved or some user is still logged in, 00:21:24 use a different browser or use an incognito session – it often saves you some confusion. That's true. 00:21:32 Now we access the landing page of the application, the index page, without authentication, and that's on purpose because we do not want to force authentication to access this page, 00:21:45 but once I want to access any parts of the application under this protected path, I require an authenticated user. And that ensures by clicking on the "Login" button, as you can also see... 00:22:00 or maybe you have to have very good eyes to see that... this path goes into... - Protected... - Yeah, under... to a source... 00:22:09 So if the "Login" button is clicked, then the URL is opened, which has a protected... Right, and that enforces the HTML5 runtime to redirect the user to the identity provider of your choice, 00:22:22 and by default, that's the SAP ID service, and let's see if... And now I'm redirected to SAP ID service, and I'm prompted to log on, 00:22:32 and now I'm logging in with this second user that I assigned to the role. So the e-mail of this user is "
[email protected]". 00:22:46 And for you here it would be just credentials for the second user you created. All right, so I'm successfully logged in, but we still get an error message here telling us that some back-end request failed. 00:22:58 That's expected and we will fix that error message in the next unit. But for the time being, we are at least logged in as a user to the HTML5 site, and... 00:23:11 And also, not only logged in... so we are authenticated and we are also authorized to access this page. Yes, on a coarse granular level. 00:23:21 So far we are not assigned to any, let' say, more fine granular roles that the application defines. We will talk about that in the next unit. 00:23:28 But what you can already see that obviously worked is that the information about this user that I used to log in is now shared between SAP ID service and the HTML5 application by using this user API 00:23:43 and showing up here in this welcome tile that displays what is available by SAP ID service about the user. - Hello Adam Admin! - Yes! [Both laugh] 00:23:55 This time Adam Admin – okay. Ah, and now finally, before we end this unit, we also want to show the logout, 00:24:03 and let me quickly show that logout in a trace for the... We just opened a SAML trace under "Developer Tools" and then... 00:24:14 And now we can click "Logout" and let's see if a logout request is sent, and I think it was because here we see that this logout has now been sent to the IDP. 00:24:24 And just for you as a developer, to make sure that your logout works, always check whether that request is really sent. And if it isn't, the issue is most likely due to some caching in the browser. 00:24:38 So you can see that logout request – that's now really deep into the SAML protocol, we don't want to go into that, but nevertheless... We see that the request was sent. 00:24:48 ... the request was really sent, and you can be sure you are logged out as the user because if I now click on "Login", I will again be forced to authenticate. 00:24:57 All right, and with that, let me go back to the slides. Yeah, with that we are at the end of this unit. 00:25:06 So we looked into the xProject application, so a simple project application which we used to learn about security in the Neo environment of the SAP Cloud Platform. 00:25:17 Now in this unit, we specifically looked at the HTML5 application there. We had some pages which were public – so the index page – and we had our protected area 00:25:28 where we forced the authentication and we also used the second user to log in there, and to log in we also used some protected resources combined with a role in the cockpit to manage this. 00:25:48 In the next unit, we will continue with the back- end part and also make this whole scenario work fully. Thanks and see you in the next unit. Week 5 Unit 3 00:00:06 Hello and welcome to the openSAP course "SAP Cloud Platform Essentials" – Week 5, Unit 3. We will continue exactly where we left off, now looking at the Java application. 00:00:19 All right, so I hope you remember the scenario as we explained it in the last unit. We have a business application that is split into two parts: an HTML5 part which covers the UI, 00:00:31 and a Java application that hosts the business logic and takes care of persistency of our data. And all in this scenario of a project management application that allows our business users to manage their projects 00:00:49 and report time they spent on these projects. So as I said, we now want to take care of the Java side since in the last unit we mainly looked at the HTML5 part of the application. 00:01:07 Just as a short recap, we covered the authentication of the end of the business users, and used the SAP ID service to authenticate our end users, 00:01:20 and as a result, we had an authenticated user that now needs to be passed on to the Java part of our xProject application. So we will now have to find answers to the questions: How does the end user authenticate at the Java application? 00:01:45 How does the authenticated user, which we also call a "principal" – that's just another name for the authenticated user – how does that principal get propagated, forwarded from the UI side, from the HTML5 application all the way to the Java application, 00:02:12 when the UI makes use of the APIs that are exposed by the Java application to expose its business logic, so how does that principal propagation – that's just the basic term here for that mechanism – how can we implement that? 00:02:29 And finally, once the authenticated user, the principal, has securely reached the Java back how do we determine there what the user is finally allowed to do? 00:02:40 And here we certainly, since the user there gets access to their data – for this scenario, the project data – we also have to apply a role-based authorization model in our Java-based back end to decide whether or not the user is allowed to see data. 00:03:00 And that granularity can also be more fine granularity? Exactly. 00:03:05 So if you remember from the previous unit, our authorization model was fairly coarse grained. We defined one permission – "accessProjectData" – that was assigned to a custom role that we called "Employee" 00:03:22 and then assigned all our business users to that "Employee" role. That gave them access to the UI part of the application once they'd successfully logged in against the SAP ID service. 00:03:37 Now when they actually want to access their data which is managed and stored by the Java back- end side of our application, we certainly have to apply a more fine granular authorization concept, 00:03:51 and that will be implemented by two roles that I will talk about in a second. So to protect a Java-based application, you usually also specify the authentication requirements 00:04:09 against your Java application in a deployment descriptor. So similar to the "neo-app.json" file for the HTML5 application, 00:04:19 we also have a corresponding deployment descriptor for Java-based applications, which is the famous "web.xml" file. It's a standardized format for that deployment descriptor, standardized by the Java programming language. 00:04:38 And the most important part in that deployment descriptor is the "login-config" part that specifies in a subelement the authentication method – or auth-method for short – which authentication mechanism 00:04:53 should be used to authenticate your business users. We used FORM, and FORM basically translates on Cloud Platform into a SAML-based authentication, 00:05:05 because if you remember also from the very first units where we talked about the basic concepts, we always delegate authentication to an identity provider of your choice... 00:05:14 – Which is SAML 2.0 compliant. – ... which has to be SAML 2.0 compliant, exactly. And therefore FORM on Cloud Platform translates into SAML-based authentication, 00:05:26 and that can be seen in particular when you go into the cloud cockpit, into your Java-based application, and there you find on the left-hand navigation an entry which is called "Authentication Configuration". 00:05:39 A screenshot is shown here, and in the demo in a second we will also go into this configuration and see that for this authentication method FORM, basically two login modules, 00:05:55 which translate into authentication mechanisms, are configured by default. Those are SAML 2.0-based authentication against a trusted identity provider, 00:06:09 and second, in the default configuration you find another entry here in the FORM line that is called "Application-to-Application SSO". And I highlighted this login module because this is what we are going to use in our scenario 00:06:29 to securely accept the propagated authenticated principal from the HTML5 front end in our Java back end. So basically, with this mechanism we enable this principal propagation by accepting a propagated 00:06:50 from a trusted application component – in this case, the HTML5 application – in our Java back So it's important to leave this default configuration as it is when you start with your trial account and deploy any Java-based application. 00:07:09 That's the default configuration and it already incorporates this secure principal propagation using this "app-to-app SSO" mechanism, so application-to-application single sign-on. 00:07:22 So, as I said, as a developer just make sure that in your "web.xml" you specify this login configuration. And now going back to the first component of our application, the HTML5 component, 00:07:40 that component has to invoke these APIs exposed by the Java-based back end, and as, I would say, always on Cloud Platform, calls are made via destinations, right? 00:07:57 So you configure a destination whenever you make a call either to a component that resides on the platform as well as outside the platform, so destinations... 00:08:06 Be it cloud or be it on premise, you use destinations... ... all over the place, yep. 00:08:10 Also here, if you are thinking about the 12-factor principles, storing our back-end system... environment... storing that in the environment, and those are our destinations here. 00:08:23 Exactly, so you decouple the design time from the configuration time by only specifying the name of the destination. So I as a developer only have to specify the name of my destination. 00:08:36 In this case, in the calling application component, the HTML5 part. So again, this goes into the "neo-app.json" deployment descriptor 00:08:46 where the path to the API to retrieve, for example, project data from my back end is configured as a destination that refers to a destination with the name "projectAPI", and we have to use that exact name in the cloud cockpit, 00:09:03 which we will do now in this unit to create a destination, or actually two destinations are needed: one to retrieve project data and the other one to retrieve data for the time sheets that people maintain with the application. 00:09:18 So those two destinations are needed by the HTML5 application to successfully call the back end on the Java side. So actually, that code is already present in that HTML5 application which we deployed in the last unit. 00:09:32 Exactly. - So we do not need to touch that now. - No. 00:09:35 What we will do in this unit is deploy our Java application – we will see the project for that – and then we will create our two destinations so that the Java application also knows which URLs to target, 00:09:50 or rather the other way around: so that the HTML5 application knows which URLs to target in the Java application. Exactly, so we have to specify the actual URL, the technical URL endpoint of the APIs exposed by the Java application in those destinations. 00:10:05 And if you remember at the end of Unit 2, after we successfully logged in to the HTML5 application, we still saw an error message that popped up. That was exactly due to the fact that those destinations were still missing. 00:10:20 So we will fix that. And certainly we also want to make sure that by using these destinations, 00:10:26 the HTML5 application can securely propagate the already logged-in user on the HTML5 side to the back end – in this case, our Java back end. 00:10:36 And this is why for the authentication property of our destinations, for both of the destinations, we have to choose this app-to-app SSO. 00:10:46 And that corresponds exactly to the previous slide where we had, as part of the FORM-based authentication, this application-to-application SSO login module being part of our module login stack, however you call that, 00:11:00 these login methods that are assigned to the authentication method you choose – in our case, FORM. All right, so that's the setup of our destinations. 00:11:12 In order to allow principal propagation within your account and within components of your applications running in your account, You have to make sure that one property in the trust settings of your account is switched from the default value, 00:11:29 which is "Disabled" to "Enabled", and that's principal propagation. So that screenshot... So you do that only once and then it works for all the applications in your account? 00:11:37 Exactly, so application-to-application SSO is meant as a secure propagation mechanism for applications running in your account. We recently also documented the setup of how to use application-to-application SSO even beyond your account boundaries 00:11:59 so that you can even use this mechanism to securely propagate a user from an application component running in account A to an application component running in account 00:12:10 But the original design of the application-to- application SSO mechanism for secure principal propagation was basically meant as a mechanism for propagation between applications within your account. 00:12:26 And for that, to ensure that there is the required trust setup between those components that propagate the user, you have to enable that flag so that the runtime is instructed to trust the propagated principal. 00:12:44 - Okay. - Okay? So... that said, I will jump in a second to the demo, 00:12:57 but not without again mentioning the authorization model of our overall scenario. As I also explained before, we created this "Employee" custom role on the HTML5 side, 00:13:10 assigned the user, and assigned the "Employee" role to the permission "accessProjectData", which – as already mentioned – is a fairly coarse grained authorization model, 00:13:21 whereas in the back end, when it comes to accessing the data, we have to apply a more fine granular authorization model. And for our demo scenario, we make use of two different roles that are defined by the Java back 00:13:36 One is for project members and the other for project managers, and you can already imagine what the two roles are allowed to do. Project members can basically report their times on projects that they are assigned to, 00:13:48 whereas as a project manager, in the application I can also create new projects and, you know, do the administrative part here in the business application. 00:13:56 And assign members to those projects? And assign members to these projects, remove them, and so on. 00:14:00 So all that administrative stuff of project management should only be possible for users that are assigned to the project manager role, all the other stuff is for project members. 00:14:11 In order to make the environment aware of these two roles, they have to be specified, defined by the developer. And again, that is done in the "web.xml" file of the Java application, 00:14:24 so you have to specify the role names as security roles in the "web.xml" file, so as you can see here from the code excerpt here, we have project manager and project member defined. 00:14:39 And later on, we assign those roles to the protected paths of our application, so that whenever a protected path is invoked, 00:14:50 which in our case are the APIs of the project management application back end, the Java back I as an authenticated user have to be in one of these two roles in order to successfully invoke this back end. 00:15:07 And for that, the calling front end, the HTML5 application, has to securely propagate the authenticated user, right? Therefore, we need to assign a user to the roles, which we will do in the exercise. 00:15:24 And now let's switch first of all to the source code of our Java application... Exactly, so can you perhaps show the code just in the repository? 00:15:36 So again, below the video, under "Additional Material", just download what you find there, then click on the link, and there you will come to this GitHub project here, 00:15:49 It's a simple Java application which is our back end for the xProject. Here you'll also find the setup instructions. 00:15:58 Just follow those – it's a simple Java application – import it into your Eclipse, deploy it to SAP Cloud Platform, and now let's switch to Eclipse. 00:16:11 We had it... we wanted to show the "web.xml" probably... yeah. So then you can also have a look here at the "web.xml" file, the deployment descriptor for Java applications, 00:16:22 and there you'll find... so what do we find there? As we already showed on the slides, you find here all these elements that we mentioned. 00:16:30 So you find the login configuration for FORM-based authentication, which also covers this application-to-application SSO. 00:16:38 You find here the definition of the roles. Like we had on the HTML5 side, we also have a public area that should be accessible 00:16:48 without any constraints in terms of being an authenticated user assigned to one of the roles. Then there's an index page which contains nothing but just a simple statement that says, 00:17:00 okay, this is the xProject back end – it does nothing. But basically we also have a mixed setup here of protected paths and unprotected paths. 00:17:08 And here we see also one thing which you can do in your Java project – you can specify the roles already in the deployment descriptor. Exactly. 00:17:18 And then what we will probably do is use the cockpit to assign those roles to users. Exactly. So these definitions here that you create as the developer get onto the platform with the deployment of the application, 00:17:30 and from there, in the cockpit, you will see exactly the roles appearing under those names. "Predefined" roles – so those are predefined by the application. 00:17:40 The one that we created in the previous units – the "Employee" role – was a custom role. On HTML5, we do not have such a deployment descriptor that allows us to specify those roles, 00:17:53 therefore we had to create it in the cockpit, and this is also a little difference here. Okay, now let's go into the cockpit. 00:18:04 And there, if you now just follow the setup instructions, you will have your Java application deployed. And then... so where do we begin? 00:18:15 The Java application is now deployed, our HTML5 application is deployed... I would say let's start with the creation of the destinations because that's what we still need to 00:18:25 But let's not forget to also make the trust settings or that change there, because just with the destinations and without changing the trust, it wouldn't work. 00:18:37 That's true. So now I'm logged in to my trial account. 00:18:43 You see that the Java application is already deployed, having followed the instructions on GitHub. So let's get started with the creation of the destinations, and for that I have already prepared the property files for those destinations. 00:19:00 You will also find them in the additional material. That's true. 00:19:03 Let's first create this "projectAPI" destination. As you can see, you have to replace the URL in that destination, so replace that placeholder "XYZ" with the actual name of your application. 00:19:18 Okay, maybe I should have copied that... - Just open "Java Applications" in a second tab. - Yeah, okay. - It's probably easiest. 00:19:26 Okay, let's go to the cockpit... on trial... and just look it up here. Basically, you find the URL of your application here in the overview of your Java application, 00:19:43 so just copy and paste that link address here and paste it as the path... Yes, exactly. And here make sure that you not only use that, 00:19:55 but that you have at the end – if you now paste it in – that you have this "api..." and so on still in there. As you can see, I just copy-pasted the first part of that URL, 00:20:07 But now containing the actual endpoint of my Java-based back end. With your account name, so the "p" and the numbers... 00:20:14 And also – but this will be ensured by the input of the property file – make sure that "AppToAppSSO" is selected as the authentication mechanism which we use to propagate the principal. 00:20:26 So let's save that and just do the same for the... The second one – so the same steps here. We can just do it quickly. 00:20:33 Fortunately, we still have the URL on our clipboard... all right. So again, the path is slightly different here – it ends with "timesheets", on the other it was "projects". So let's save that. 00:20:51 So now that we have created the required destinations by the HTML5 front end to call our back end, securely propagating the logged-in user, the principal, 00:21:02 let's now enable application-to-application SSO in our trust settings, and there you have to go, also at account level, into "Security", "Trust" settings, 00:21:13 and right here on the first tab – "Local Service Provider" – click on "Edit", and switch from the default "Disabled" setting to "Enabled", 00:21:22 which now enables application-to-application- based single sign-on principal propagation between the applications in your account. And finally, what we also need to do now is assign the business user to the roles, and there we can go into... 00:21:44 - That we do in the Java application? - That we do in the Java application. Because we are using the two roles which we defined in the Java application? 00:21:51 Exactly. So as you'll remember, we already assigned this business user that we use for testing to the "Employee" role for the HTML5 side. 00:22:02 Now we need to do that also to the more fine granular roles for our Java-based application. So we went into the Java application, went into "Roles", and here you see exactly those two roles of type "Predefined", 00:22:15 which translates into defined by the developer in the "web.xml" at design time. And now we can select those two roles and assign the user, and for the ID, I can... 00:22:30 And here again, the same as what we did in the last unit. Just use a second account and then the user from there – that's the easiest way to go about having multiple users here. 00:22:41 Right. All right, so now that we have the user assigned to the roles, let's now invoke the application. 00:22:51 And now we again have to invoke the front end of our application, which is the HTML5 application. So let's go here... and open that again in a new incognito window. 00:23:07 - And so what happens now is we first probably see the index page...? - That's true. - And then we log in? - Then we log in. 00:23:14 And then with the logged-in user, the HTML5 front end will make use of the configured destination at this time. And because we specified application-to- application SSO in our destinations as the authentication method, 00:23:29 the logged-in user on the HTML5 side will be securely propagated to the Java back end. There, based on the user information securely propagated there, 00:23:39 the Java back end will be able to find out which roles the user is assigned to and will also show that in our login after we have sent this... And what we will see in the front end is this error message not coming up again? 00:23:55 Hopefully, it will disappear – let's see if we thought about all the steps that were needed. So let's log in with that user, with our business user. 00:24:07 I could also make use of the P-user here, but let's for more... so the e-mail address of that user... I thought I clicked... now I've clicked. - All right. - "Role assigned". It's green! - Wonderful. That's what we wanted to see. 00:24:28 So, now I also see an entry here on the left-hand side... that for my user... Since I'm a project manager, I can now also access the project data as managed by the application. 00:24:43 I am assigned to the two roles that we just did in the cockpit. Like in the second unit, that's already worked – my federated identity information is shown here on this "Welcome" tile. 00:24:58 But now the error message has gone, we are assigned to the two roles as managed in the back end, and we also see some data. So obviously principal propagation worked, from the front end to the back end, and all of our settings were correct. 00:25:15 Yeah, and perhaps before we go back, one thing which I find really interesting here is that we didn't have to restart our Java application. 00:25:24 We changed the configuration, and during the runtime it automatically used the new configuration, so that's one benefit here. Absolutely. Any changes you make in the cockpit, for example for the role assignment, 00:25:37 only take place once the user logs out and back in again. So if I now change any role assignments, we wouldn't see that because the user has an authenticated session, 00:25:48 and that makes use of the assignments to the roles that were on the platform when the user authenticated, but once I log out and log in, the new assignments based on whatever I change in the cockpit will also be in place here. 00:26:11 Okay. All right, so let's go back to the slides. 00:26:15 Okay, and with that, we are also at the end of this unit. So we covered in depth our Java back end and how to handle principal propagation 00:26:25 from our HTML5 front end to this Java back end, and also here the security. We defined our roles already in the deployment descriptor, in the "web.xml" file, 00:26:36 and then used that here to have our project member and our project manager, to have the authentication and also the authorization. That's it for this unit – see you in the next unit. Bye bye. Week 5 Unit 4 00:00:07 Hello and welcome to the openSAP course "SAP Cloud Platform Essentials" – Week 5, Unit 4. And now we will continue with the scenario which we already covered, but now with the Web API. 00:00:23 Right, so in the last unit we carried out all the configuration that was needed to take care of the scenario when I as an end user, as a business user access the application via the HTML front end, 00:00:40 using a Web browser, logging in to the SAP ID service as the IDP, and accessing the back end via the API, using the destinations, 00:00:52 and making use of the persistence managed by the Java back end. Exactly the same API will now be accessed using a different client – no longer a Web browser, 00:01:06 but a simpler client which, in our case, is a simple REST client. We will make use of a Chrome application called Postman. 00:01:24 That serves as a very nice way to test APIs with a simple REST client, but that REST client stands for a large number of possible clients other than a Web browser, such as a mobile application. 00:01:40 A native mobile application that also doesn't usually have the capabilities of a browser. So rendering HTML, understanding JavaScript, and so on, but really understands HTTP and knows how to talk HTTP, but that's it. 00:01:57 So for the purpose of this unit and the demo, we will make use of Postman representing our REST client which stands for a large number of clients other than a Web browser. 00:02:16 So that said, the question now is how does the user using such a REST client, not a browser, authenticate against the APIs? Because again, we certainly still want to understand who's accessing the API. 00:02:34 So who is it, and what is he or she allowed to do? And unfortunately, for those scenarios the login method we used for the browser-based scenarios – SAML – doesn't work, 00:02:54 because in order to support SAML, the client has to understand HTML, even to a certain extent JavaScript – again all of those capabilities... So you can put in your password, your user name, and so on? 00:03:09 Right, and the browser for SAML plays an important role. So it is an assumption made by the protocol that the client is a browser capable of rendering HTML and so on. 00:03:21 This is not all the case for our native REST client, and this is why we have to make use of a different authentication method. And here another technology standard comes into play that is quite important for the platform 00:03:41 and plays a role in Neo as well as in Cloud Foundry, which is OAuth. OAuth stands for "open authorization" (protocol). 00:03:50 As I said, it's also an international standard defined by the IETF, the Internet Engineering Task Force, and basically it helps us to enable authentication for those non-browser-based scenarios and REST clients. 00:04:04 So we will see in a second what the detail flow looks like for this OAuth-based scenario, but what doesn't change is that the authentication of the user – even for OAuth – is still delegated to the identity provider 00:04:20 which, in our previous scenario and units, was the SAP ID service, and which will also remain the SAP ID service for that scenario. So again we have to make sure that authentication authorization is in place for this 00:04:37 scenario where the REST client accesses our And as I mentioned, OAuth is specified by the industry as an RFC – a Request for Comments. 00:04:48 It basically enables us to securely access the data with this REST client without the need to pass the user's credentials – so the user name and password, especially the password, 00:05:06 which should be kept and managed securely only by the identity provider and nowhere else – to pass that to the REST client in order to allow the REST client to access the data on behalf of the user. 00:05:16 That's the main purpose and benefit of using OAuth in this scenario. And remember, SAML also did the same job for 00:05:26 The application never became aware of the user's password – the user only provided the password to the identity provider and that's it. And for OAuth, it's basically the same. 00:05:34 We do not have to pass those really secret credentials that should never leave the identity provider and give them to the REST client in order to allow that REST client to access our data, 00:05:47 but instead, the REST client will obtain from the platform an "access token". And that access token is an OAuth access token that represents the access that the user 00:06:01 authorizes to the client in that flow that we will see in a second to allow that REST client to act on his or her behalf to access the project data. 00:06:14 And that's represented by this access token. An access token can further be scoped – OAuth defines a concept of "scopes". 00:06:24 Scopes can be used by the application developer to further narrow down the access given to such a REST client to access the data of the user. We will also make use of scopes in our scenario, so we will define three scopes that categorize what the REST client is allowed to do. 00:06:44 So we will have a scope that allows the client to access project data, one to manage time sheets, and a third one to join a project. And from the names of these scopes, you can already imagine that those scopes are typically 00:06:57 very closely aligned to the business domain of the application, to the application logic. So, that said, let's take a look at the actual flow. 00:07:08 How does the REST client finally obtain this access token from the platform so that it can successfully invoke – under the given scope – the API in the Java back end, in our case? 00:07:23 And here an important component comes into play that you get out of the box from Cloud Platform, which is the OAuth 2.0 authorization server. 00:07:35 That authorization server is the place where the tokens are generated and maintained. That's the place where the user is delegated to the identity provider to authenticate, 00:07:48 and basically that's the important runtime component to enable OAuth in your applications. So let's start with the flow. 00:07:59 First of all, a platform user, a member in the account of the application has to register an OAuth client in the cloud cockpit for the REST client that represents that REST client 00:08:16 as an OAuth client to the platform. And once that is done, and out of that what the application gets, the REST client, is a client ID. 00:08:25 And with that client ID, the REST client can go to the OAuth server and ask for an access token. It does so not directly by requesting the access token, but first by asking for an "authorization code". 00:08:43 That authorization code is only given to the REST client if the user successfully authenticates against the OAuth authorization server. And that implies that the authorization server now delegates the authentication step, 00:08:59 like we had it before, to the identity provider – in our case, SAP ID service. Now after successful authentication of the user at the identity provider, 00:09:09 the authorization server will generate this authorization code and hand it back to the REST client. With this authorization code, the REST client can now go back to the authorization server and say: 00:09:22 "Hey, authorization server, here is my authorization code. If you consider this authorization code as a valid authorization code, please hand me back an access token." 00:09:32 And this is exactly what then happens. Under the hood, the user doesn't recognize that step, 00:09:37 but it happens automatically with the REST client asking for the access token with a valid authorization code, which is usually only valid for a few minutes or even seconds. 00:09:51 And once that access token is obtained and securely stored by the REST client – again, the access token still contains confidential information, not as critical, let's say, 00:10:04 as the user's password, because the user's password can be used to access probably many other systems, whereas the access token can only be used to call this API. 00:10:14 Nevertheless, it remains confidential data that should be stored, not only should – must – be stored securely by the REST client. So if that can be ensured by the REST client, 00:10:28 the REST client can use it in the authorization header of the HTTP request of the RESTful API to pass it on to the API. 00:10:35 And on the platform, there's also an out-of-the-box integration between an application on Cloud Platform and the authorization server on Neo to validate the retrieved access token, 00:10:48 and if it is valid, the data of the API is returned. All right. 00:10:57 So how do we protect our application with OAuth? Basically, we first have to ensure that an additional authentication login module is added to our existing FORM-based stack. 00:11:14 We mentioned that already in the previous unit. So we have to go into the authentication configuration of our Java back end 00:11:21 and add to the already existing SAML and application-to-application SSO login modules a third one, which then basically takes care of this validation of the retrieved access token 00:11:38 and validates it with the OAuth token login. And for that to take effect, we need to restart the application, right? 00:11:48 Exactly, whenever you make changes here to this authentication configuration, we will also see in the cockpit that there will be a popup that says "please restart", 00:11:56 or the changes only take effect after a restart. Perhaps let's do that first before we go further in the slides so that we can do that part already, 00:12:04 because that's the big one for which we need to restart the application. That's a very good idea, Sven, so let's go here into our application. 00:12:14 And as you can see, we have here the authentication configuration. And we've already applied a custom configuration here. 00:12:22 By the way, the default configuration cannot be used for that because it doesn't contain the OAuth 2.0 login module in the FORM stack. 00:12:28 So here we have to switch to a custom configuration. And here you then just select the additional login module. 00:12:39 And so here, for this, you just use the Java application from the last unit, you switch to "Custom Configuration", and then here you add "OAuth 2.0 token". 00:12:48 That's right. So any changes you made have to be confirmed by clicking the "Save" button. 00:12:54 And now the information comes that you have to restart the application, so let's do that quickly. Let's go back to the application, stop it, and restart it. 00:13:08 And while it is stopping... let's maybe go quickly back to the slides. It may take a few seconds – ah, okay, it's already stopped, okay, let's start it. 00:13:23 And while it is starting, let's switch back to the slides, which were... yeah. All right, so that one we covered, and already performed the protection of the API. 00:13:41 On the left side, that's still what we had in from the last unit, no changes there. So what's the next thing we need to do? 00:13:46 The next thing we need to do is apply the scopes to the API. As I said before, we want to apply three scopes that the application defines, 00:13:58 and those are to narrow down further the access given to such a REST client. These scopes can be configured either in the "web.xml", so declaratively configured, 00:14:15 or they can be applied programmatically – we'll show that on the next slide. This slide shows the declarative way. 00:14:24 So again, we are back in the "web.xml" file where we specify a filter – that "filter-class" that is mentioned here. It's a regular J2EE filter. 00:14:35 That filter class comes with the new SDK. And that filter class... you can pass certain parameters to that filter declaration, 00:14:48 one of them being the scope that you want to apply, and certainly also finally a mapping of the declared filter to a path in your application. 00:14:58 So basically this means that in this scenario the path under "/api/v1/mobile/projects" should only be accessible for a REST client that obtained an access token with the scopeless projects. 00:15:11 Right? And further, we even narrow down the access only to the HTTP method GET, 00:15:17 and that's basically what we achieved with these settings. So, that said, let me go back to our cockpit and see... okay, so the application has started. 00:15:33 Now we need to define those scopes. Since there is no way in the standard "web.xml" to pass those scopes at design time, 00:15:45 or to declare those scopes at design time in an element, because at the time when the "web.xml" was standardized, OAuth wasn't really on the radar, 00:15:56 therefore the "web.xml" doesn't have a way to declare these scopes other than only referencing them in the filter declaration, but this is why we need to declare those scopes here in the cloud cockpit, and this can be done here. 00:16:13 Under the application menu, you see an entry called "OAuth Scopes" under "Security", and basically here we specify those scopes. 00:16:19 Now, to avoid any typos, I would recommend copying the values directly from the "web.xml" file where they are referenced, and directly pasting those values as you have them here in the cockpit. 00:16:38 So "list-projects", so let's mark that, copy that, and paste that here as the ID, and also "List project data". Let's save that. Now let's define the other two. 00:17:00 "join-project" So now, while Martin creates those three scopes, that's exactly what then happens here. 00:17:16 And afterwards, we can then begin with making use of those scopes. All right. 00:17:31 All right. So you will also see in a second when we obtain the access token 00:17:38 and as a user I have to confirm that the client should be allowed to act on my behalf within a certain scope, those descriptions will also appear in the UI that the user is seeing. 00:17:50 So those descriptions are important from the perspective of the end user experience. Which was why the description was required. 00:17:57 Exactly, right. So... All right, I think we have done what needs to be done in the cockpit. 00:18:08 Now let's go back to the... let me just double- check... I think the application was up and running now. It's started, with the new authentication configuration applied. 00:18:20 Now, as I said before, we're going to use Postman as the REST client – it's a Chrome app that can be installed for free. Just go to the Chrome Web Store and search for "postman". 00:18:35 Right, and as you can see, I've already entered the URL here, which again I can copy and paste from the cockpit, so that's... 00:18:48 But you added something, right? Yeah, I've now added this "api/v1/mobile/projects" to the end of that URL as it appears in the overview. 00:19:02 And if you remember, that was also the URL specified for the "list-projects" scope in my filter class. Yeah, so to get these additional, let's say, URL parts, they can also look in the "web.xml" file, right? 00:19:16 - Yes, exactly.- It's also in, as the protected part.- It's there, exactly. Now, Postman is a nice tool, as I said, to test those RESTful APIs. 00:19:24 And it certainly also supports the OAuth 2.0 standard to interact with the protected APIs. So let's choose that for the request. 00:19:35 And here it allows us to get a new access token for our REST client. And I remember now that we have forgotten one important thing. 00:19:46 That is step 0 or 1 in my slide of the flow which was about registering the OAuth client for our REST client. That you can do in the cockpit. 00:19:56 That we can and should do in the cockpit, which is no longer... - You closed it. - I closed it? Okay, so let's go back to the cockpit... and register the OAuth client. 00:20:11 So that happens at the account level under "OAuth Settings" – "Security", "OAuth", "Clients". And here you have to click that button to register a new client 00:20:26 and make sure that this client gets a... so that's a unique name, let's say "xProject Client". 00:20:34 The description is optional here. Make sure that you choose the right application to access the xProject application in your account. 00:20:45 The ID is generated and keep it as this, but copy it here already to your clipboard because you will need it in Postman to configure it. And it also asks you for a mandatory URL which is called the "Redirect URI". 00:21:00 This you get here from this value in Postman, because that's the URL that the OAuth server uses when it sends back the authorization code. 00:21:11 You remember that authorization code from the...? So let's maybe first copy that and paste that here. 00:21:18 Then you need to copy the ID. And then we have to copy the ID to our clipboard again because we need... it's a little thing. 00:21:26 By the way, tokens can expire. You can specify a lifetime of the tokens – 60 minutes is fine for now. Okay, so let's save that client, and let's go back to Postman, 00:21:39 where we now have the ID like we copied it to our clipboard. Now, Postman also asks you for two URLs. 00:21:49 One is to where the request for the authorization code will be sent, and the other one where the request for the access token with the authorization code will be sent. 00:21:56 Those two URLs can also be obtained from the cockpit, when you go to the "Branding" tab here. Basically, you see those two URLs: the "Authorization Endpoint", which corresponds to the authorization URL in Postman, 00:22:10 and the "Token Endpoint", which is the corresponding URL value for the access token So just copy-paste those two URLs into Postman in these places and that's it – nothing more is necessary. 00:22:23 Now we specify the scopes, and maybe let's get started with the "list-projects" scope, and... And to avoid having a typo in there, just copy it from the "web.xml" file. 00:22:38 Right, that's the most... but I've typed it so many times, I hope I won't make any typos. [Both laugh] So let's also give that token a name, so "xProjectListProjectScope". 00:22:50 So we ask for the project scope, and let's start by requesting the token. Now the authorization code is requested, and as I mentioned before, you have to authenticate against the OAuth server. 00:23:01 So let's do that again with our business user. And basically you see, according to the scope that we entered, the "list-projects" scope, the authorization server says, okay: 00:23:22 "Hey, user, there's a client called 'xProjectClient' that wants to act on your behalf, to access your xProject application data under the scope to list project data. 00:23:32 Do you allow it to do that? Do you authorize this client to do that?" And I could cancel at that point in time, but we don't, so we authorize that client. 00:23:40 You might know of similar messages from logging in to some applications like Facebook or Twitter. It's exactly the same protocol that's used there in the background, so this should be familiar to you. 00:23:54 Yes, and now we have obtained an access token with this scope, and we can even see the value of the access token here. So again, that should be stored securely in a productive scenario 00:24:06 because it still represents quite a powerful credential. So now, in order to use this token with our GET request to the API, we have to click that "Use Token" button, 00:24:18 and when we click that button in a second, we will see that an authorization header will be added with the value of that token, and the scheme bearer will be added to our header. 00:24:28 So I click on "Use Token" and you can see that the "Authorization" header has now been added here. And that corresponds to the specification of OAuth in the RFC for how a REST client 00:24:43 should pass a "Bearer" type access token to the protected API. So let's see now... 00:24:53 If we haven't forgotten anything, we should now see – when we send that request – the project data of the application. Let's click on "Send"... 00:25:07 and... voilà, we get the data back in JSON format. The project we saw in the previous units that appeared in the left-hand navigation on the UI – 00:25:20 that's exactly the same project that we now see. We could now even test with another scope and see whether another scope would not allow us to do so. 00:25:29 I mean, that's a fairly simple thing. So let's go back to "Authorization", let's get a new access token, 00:25:36 but this time, let's request a different scope, let's say the "xProjectManageTimesheetsScope"... and just specify that here. So again, it has to be... "manage-timesheets"... it has to be the correct value according to 00:26:00 the configuration made in the cockpit under "Scopes", but basically that's it. If I now request the scope, you will see that that has now changed. 00:26:08 Now the authorization server asks me... I was already logged in to the authorization server, so my session was reused, but now it asks me for a different scope, if I confirm that. 00:26:18 Let's do that, but now let's try to use this new token with the same URL. And according to our filter settings, it should not be possible, right? 00:26:29 Because we protected exactly that URL with the GET method to be only allowed to be invoked with the scope "list-projects", not "manage- timesheets". 00:26:38 So let's just use that and let's remember the first few characters here: 4-2-8-something. "Headers"... okay. So that was now added, the difference. 00:26:49 Now let's send the request, and as you can see, we get an HTTP status "403", which tells us we have used an access token which doesn't match the filter settings we did in the "web.xml". 00:27:04 Okay, so we have tested it, we have seen that it works with the correct one, and that it doesn't work with the wrong one. There's also the second option – if you go to the next slide, we will probably see it – that you can do all this... 00:27:20 – ... programmatically. – Exactly. So in your application code. And then with that, we are also at the end of this unit, right? 00:27:27 – That's true. – Exactly. So now we've looked into Web APIs and also how to secure those, 00:27:33 and we've experimented a bit with the Postman REST client. I hope you've also had fun with this unit. 00:27:39 Thanks a lot and see you in the next unit. Week 5 Unit 5a 00:00:10 Hello and welcome to the openSAP course "SAP Cloud Platform Essentials" – Week 5, Unit 5. And now we are at the point where we will go into the Cloud Foundry environment, so let's begin there. 00:00:23 Right, so let's get excited about our new environment on Cloud Platform. So Unit 5 and the last one this week, Unit 6, will be all about this newly added environment. 00:00:40 And before we go into the details on security for business applications in the Cloud Foundry environment, let's maybe take one step back and clarify the question of why we have introduced 00:01:00 new security features for Cloud Foundry on SAP Cloud Platform. The simple answer to that question is because a native Cloud Foundry environment 00:01:12 perfectly takes care of securing access to the environment for platform users, so users in an administrative role, such as developers and account administrators. 00:01:28 But it doesn't actually take care of the authentication and authorization of business users, of end users. So in other words, with Cloud Foundry, as an application developer I don't get any good support 00:01:41 for securing my business applications like we know it, for example, in the Neo environment. where we can define roles, assign users to those business application roles, and so on. 00:01:52 So that's more or less missing. So a native Cloud Foundry environment takes care of platform users, 00:02:06 it defines a set of platform roles. Like we know them from Neo – Administrator, Developer,... – we also get those platform user roles with Cloud Foundry. 00:02:23 They are named a little bit different, but in the end, they provide those platform users with certain administrative permissions, rights, to configure and manage the environment. 00:02:36 Like Account Manager, Billing Manager, and so Exactly, those are the platform roles that are predefined by Cloud Foundry. 00:02:45 And the question of who takes care of authenticating those platform users is implemented also by one of the core services in Cloud Foundry, which is the User Account and 00:02:58 Authentication – UAA for short – service on Cloud Foundry. The UAA is, from a technical perspective, an OAuth 2.0 server, 00:03:11 so more or less like the one we already saw in Unit 4, for the Neo environment. We also have a very similar component to the UAA in the Cloud Foundry environment 00:03:23 which takes care of delegating the authentication to an identity provider and again for the platform users, it is the SAP ID service that authenticates the platform users. 00:03:35 And upon successful authentication against an identity provider, the UAA basically issues an OAuth token, 00:03:46 which then allows access to the Cloud Foundry environment for those platform users. And those tokens issued by the UAA then contain one or more scopes 00:04:01 that are also predefined by the environment, and that basically define on a fine granular level 00:04:06 the administrative permissions that the platform user has to access the environment. So overall, as a summary of this slide, 00:04:16 Cloud Foundry takes care of platform users but not of business users. Now, basically, that motivated us to introduce 00:04:26 a programming model to implement security also in the business applications, running in our Cloud Foundry environment on Cloud Platform, 00:04:35 and we refer to this programming model as the SAP HANA extended application services, advanced model (XSA). 00:04:43 Yes, we've talked about this already in the first and second weeks, so we've covered that programming model in general. 00:04:48 Also the SHINE application which we deployed by the end of Week 2 was also written in exactly that programming model. And now we are looking specifically at the security features of that programming model. 00:05:00 Right. And along with this programming model, 00:05:04 we introduced certain design but also additional runtime components in the environment that allow the business application developer to work with this programming model. 00:05:18 And as part of the additional runtime components that we introduced is a second instance of the UAA, which we call the XSUAA, 00:05:27 and which is a second instance of the OAuth 2.0 authorization server that comes with Cloud Foundry but only there for the purpose of authenticating business users, right? 00:05:39 So in our environment, we basically always have two instances of the UAA: one for the business users and one for the platform users, right? 00:05:48 And along with the security programming model in we have also introduced certain design time artifacts. 00:05:59 I will talk about those in a minute. But overall, our XSA security model enhances the core CF security model by enhancing the model 00:06:09 in a way that you are not only restricted to configuring and making use of security – so authentication and authorization – for platform users, but in addition to that, 00:06:22 also business users in business applications. So that both are taken care of, like we know it from the Neo environment. 00:06:28 Exactly. So in the end, what you get in the Cloud Foundry environment – on a conceptual level – 00:06:35 is not really different from what you are already used to getting in the Neo environment. You just have to accept the fact that with your application you are in a different environment 00:06:45 that comes with a slightly different notion of the programming model. But in the end, the concepts are very much the same, 00:06:52 so as a developer, I define roles in my business applications, I assign users to those roles, I can authorize these users. 00:07:00 The authentication of the user continues to happen at the identity provider of your choice, so conceptually, nothing changes, 00:07:10 but the way in which to implement those things changes from the Neo to the Cloud Foundry environment, and this is all what we're talking about in this unit. 00:07:19 And that's also one of the benefits of the Cloud Foundry environment offered by SAP as part of SAP Cloud Platform compared to other vendors who offer a Cloud Foundry platform. 00:07:33 What we did here, enhancing the CF security model by all those features for the business users of our Web-based business applications – those you find only on our platform. 00:07:47 Right. Okay, so let's go one level deeper into the XSA security model. 00:07:55 And as an XSA application that is deployed in the Cloud Foundry environment in SAP Cloud Platform, that always comes with at least two components. 00:08:10 One is the application router, and the other is at least one component that runs your business application logic 00:08:21 in a microservice world that may be split into many components, but at least your XSA business application has those two components: 00:08:33 the application router and the component that hosts your business application. Both of these components are bound via a service broker to the XSUAA instance, 00:08:48 and as a user of your business application, sitting in front of a Web browser, the first line of defense for your application is always the application router. 00:09:03 So you as an end user with your browser always access first the application router. And due to that fact, the application router – from a security perspective – takes quite an important role in this scenario, 00:09:15 because it takes care of authenticating the user, or delegating the authentication via the XSUAA service instance to an identity provider. 00:09:28 And upon successful authentication of the user, the application router obtains from the XSUAA service the OAuth access token 00:09:41 and makes use of that access token to pass it to the second-tier business application services and authorize any calls made towards those back-end components. 00:09:58 So the flow is exactly like we know it from the Neo environment? Exactly. So if you remember the scenario from Units 2 to 4, 00:10:06 we had the HTML5 application and the Java application in the Neo environment, where the HTML5 application more or less took the same role as the application router. 00:10:16 It authenticated the user and it passed on the authenticated user – the "principal" as we called it – down to the business application. 00:10:31 Here we have conceptually exactly the same but using different mechanisms. Yep, but also like the HTML5 application contained our front end, our UI code, 00:10:40 this is now not in the application router – this is in the business application. So the application router is more or less only those security-relevant parts, let's say, of the HTML5 application. 00:10:50 That's right. So in our scenario here, the business application also serves all the front channel... 00:10:59 It's a really... in our scenario, and we will go into the demo in Unit 6... - So this unit is just theory? - Just the theory. 00:11:06 - The next unit is then the practice. - Right. We will see in the demo scenario that our sample scenario here for Cloud Foundry is quite simple. 00:11:14 The business application is more or less just a servlet that is protected using the XSA programming model. 00:11:20 All right, let's continue. Now let's take a look into the interaction between 00:11:25 the application router and the business application and the XSUAA, how the application router in the end obtains the access token from the XSUAA service, 00:11:38 and makes use of it to call the business application. So that's the flow, and if you carefully followed Unit 4, 00:11:51 you hopefully remember the slide where we showed the flow – the seven steps – where the user obtained the access token for a REST client accessing the API on Neo. 00:12:09 Basically, the same flow now applies here as well – the "authorization code flow" in OAuth, right? Let's see how that goes. So the Web browser... Usually, I as a user start accessing 00:12:21 the application router for the initial step with no authenticated session. So the application router doesn't know who I am. 00:12:29 So that means the application router now needs a session, and therefore redirects my browser to the XSUAA service asking for the authorization code, right? 00:12:40 Which is the prerequisite for finally obtaining the access token. So that authorization code request again leads to 00:12:47 a redirect of the user's Web browser to a trusted identity provider. And again, SAML 2.0 is our key technology here because the XSUAA service integrates with 00:12:59 basically any SAML 2.0-compliant identity provider of your choice. Now, with that redirect, the user will be prompted by the identity provider, with the login page usually. 00:13:11 It may also even work with single sign-on if the user has a certificate or a Kerberos ticket or whatever. Now, after providing some sort of credentials – in the simplest case, a user name and a password – 00:13:22 at the identity provider, the identity provider will authenticate the user and send back a SAML response, which goes via the user's Web browser in an HTTP post, back to the XSUAA service. 00:13:34 Now the XSUAA service, assuming it trusts the identity provider, will process this SAML response from the identity provider, 00:13:43 now understand and know who the user is, and will create the authorization code requested in the step above. 00:13:51 It will return the authorization code to a known redirect URI, back to the application router, again via the user's Web browser with the redirect, 00:14:01 and based on that authorization code, the application router can now request with that valid authorization code, 00:14:09 the actual access token from the XSUAA service. And if the authorization code is still valid – and it should be after less than a second – 00:14:21 the access token is generated and sent back to the application router, which again now has to store that access token in a secure place, 00:14:30 but since the application router is a server-side component, it certainly has the capabilities to store data securely – unlike, for example, a browser – 00:14:41 and from that moment on, can use the access token to pass it to any subsequent calls to the business application. It's important to mention that the format of the access token is different, compared to the Neo environment. 00:14:57 – Here we have a JSON Web Token. – Exactly. If you remember, the access token in the Neo environment was an arbitrary string 00:15:08 of a certain length that should not be predictable for an outside attacker. For Cloud Foundry, the access tokens are in a different format – in a JSON format – 00:15:18 that also contains data about the user. So from that perspective, JSON Web Tokens – or JWT (pronounced "JOT") tokens – are richer in their semantics, 00:15:33 and also allow the recipient of the token to validate the token without any further interaction of the OAuth server. – An additional security feature. – Yes. 00:15:45 If you remember in the example on the Neo side, the bearer token – which is again just a string from the recipient's perspective – gives the recipient 00:15:58 no idea about the validity of this token or who the user is behind that token. So it always has to be passed on to the OAuth server and then ask for validation and also further information about the user. 00:16:11 For JWT tokens, this is not necessary, and therefore these JWT tokens fit very nicely into this microservice world, 00:16:19 where these JWT tokens may be passed quite a number of times between the different microservices of your application 00:16:25 and therefore, let's say, fit nicely in terms of performance and so on because there's no need to always interact with the authorization server. 00:16:37 Yeah, you remove some load from the authorization server. Absolutely, yep. 00:16:42 All right, so that's the authorization code flow on Cloud Foundry. And again, it's not different from a standards perspective. 00:16:48 Like we have it on Neo – in a slightly different context here, but nevertheless, it's more or less the same as we already saw it in Unit 4. 00:16:57 Okay, and upon successful validation of the job token – again, it can be done only locally, and potentially also scopes that may be associated with this token – a response is sent 00:17:11 back to the user's Web browser with the data requested in the very first request that took place. All right, a lot of stuff. 00:17:20 We are not yet done, but I won't finish this unit without mentioning the entities you as an application developer can use to specify your authorizations in your business applications, 00:17:37 and those start in Cloud Foundry at the level of scopes. Again, scopes are nothing different than the scopes we already learned about in Unit 4, 00:17:47 in the Neo environment. They are... Because scopes are a part of the OAuth definition? 00:17:51 Yes, right, so in OAuth the standard defines the concept of scopes. It doesn't define how the scopes should be named, what they should look like, 00:18:00 and the granularity of these scopes. It's all up to you as the application developer to define the scopes for your application. 00:18:07 But as I think I already mentioned in Unit 4, scopes are usually closely aligned to the domain of your business application, 00:18:16 and are usually on a finer granular level. So they are definitely there to do functional authorization checks. 00:18:23 So you check against the scope received in the JWT token from a business application perspective whether the user is allowed to access certain data or not. 00:18:32 A difference compared to Neo is that the authorization model on XSA Cloud Foundry applications can also refer to attributes when they do an authorization check. 00:18:46 So you can define a certain value of an attribute that comes with the authenticated user, such as the user's cost center – whether the user is allowed to access certain data or not, 00:19:02 such as a cost center number. These are sometimes also referred to as "instance-based authorization checks". 00:19:10 And those who are familiar with ABAP as a programming language may remember this concept when they think about authorization objects in ABAP. 00:19:23 They also allow such instance-based authorizations. And so that's basically the idea behind the attributes. 00:19:35 So scopes and attributes are aggregated by the developer at design time into what we call a "role template". And the template implies that this is still a design-time artifact specified by the developer. 00:19:51 So a role template must contain at least one or more scopes, it may contain one or more attributes, and depending... 00:19:57 Or also zero. Right, so attributes are optional, scopes aren't. 00:20:02 So scopes need to be assigned to a role template, which then gets instantiated at configuration time after deployment of the Cloud Foundry 00:20:11 or XSA-based application, and gets instantiated as a role. So a role is usually specified by the platform user in the account, 00:20:21 and a concrete role then always refers to a role template. And if a role template contains attributes, that role also needs to specify what the values of these 00:20:33 attributes should be in order to successfully assign a user to that role, right? So this means that if we... as in our example, we won't use attributes in the upcoming demo and example. 00:20:47 If you deploy your application with role templates that only contain scopes, a default role gets instantiated in your Cloud Foundry environment, 00:20:59 so you do not have to explicitly create these roles out of the role template. All right, so now finally the question is... 00:21:08 We now have scopes, optional attributes, we've defined them as role templates, deployed the application to Cloud Platform – now how does the business user finally get assigned to the roles? 00:21:20 And in Neo we had our groups, which we could Right, you could either statically assign the user to the roles or make use of groups. 00:21:28 And in Cloud Foundry? In Cloud Foundry, we basically have the same thing – we just call it something slightly different. 00:21:34 We call it a "role collection". Similar to the groups... 00:21:38 But here they are necessary? Right, because a user can only be assigned to a role collection, not directly to a role. 00:21:47 Again, these role collections – like the groups on Neo – contain one or more roles, or refer to one or more roles. 00:22:02 Those role collections are managed and created by a platform user in the cloud cockpit. And you assign a business user to such a role collection either by directly assigning the user 00:22:19 to the chosen role collection – "static assignment" – if you make use of SAP ID service as the identity provider to authenticate the user. 00:22:31 If you do not use SAP ID service as the IDP, you make use of a federated role assignment model, like we know it from Neo, 00:22:42 where the business user is assigned to a group based on an attribute value. The same is true for Cloud Foundry, 00:22:53 where the business user is assigned to a role collection based on a federated attribute which, at the moment, must be named "Groups" with a capital 00:23:07 So "Groups" is the name of the federated attribute that the identity provider of your choice has to send back in the SAML response 00:23:15 so that at runtime the user is assigned to the role collection, and to specify those federated role assignments, 00:23:27 you specify in the cloud cockpit a "role collection mapping" as the platform user. That's what we call that. 00:23:36 It's basically a mapping of that "Groups" attribute value to a role collection based on a value that you specify in the cloud cockpit. 00:23:48 So we will take a look at both of these assignment methods – the static one as well as the dynamic, the "federated" one – in the demo. 00:24:00 Now let's take a look at the design-time task of the sample application. This is the folder structure of the very simple 00:24:13 XSA application we are going to use in the demo in the last unit. And you will also find here many of the... 00:24:22 which we already covered when we talked about XSA-based applications or applications following the XSA programming model, so the "manifest.yml" file – that's the application manifest to do some settings, 00:24:34 also the "xs-security.json" file and the "xs- app.json" file, which we talked about already. One thing we didn't talk about was the "spring- security.xml". 00:24:45 So this application here uses the... It uses spring security, 00:24:49 and it uses our XSA security library that you have to download from the Service Marketplace. And that requires that "spring-security.xml" descriptor to configure certain 00:25:05 declarative authentication and authorization rules. I will go into the details of this file in a second. 00:25:15 By the way, the sources of this sample application can again be found in the Git repository. We will show that in the next unit when we actually use it, so that's fine. 00:25:29 But what you can also see from this tree is that exactly the two minimum components of your XSA application... under "web" are basically all the application router sources, 00:25:43 and under "src" are the sources for the business application. Those are just two simple servlets: one to only show data if you are in a support or display role, 00:25:57 and the other in a role that allows you to also manage data. So a little bit similar to the previous example on Neo – two roles that we will specify then as part of the application. 00:26:11 So let's quickly look into the design time files that you as an application developer have to specify. So the "xs-security.json" file specifies all the scopes that should be known to the application 00:26:30 and how these scopes are aggregated into role templates, right? So you have one section for the "scopes" and another for the "role-templates", 00:26:39 and as you can see, the "role-templates" then refer into the "scope-references" element, to the known scopes defined in the scopes declaration. 00:26:51 And under exactly those role template names, we will later see those role templates appearing in the cockpit. 00:26:58 So that then allows us to define the roles based on those role templates. Again, we do not make use of attributes here, 00:27:06 otherwise the attributes would also appear under the role templates. The other two important files that were mentioned in that overview of the structure were the "xs- app.json" file – 00:27:20 that is very similar to the "neo-app.json" file that we know from the HTML5 applications on Neo where you also specify an authentication method. 00:27:29 In this example for this unit, the authentication method specifies a route, which means that route-specific authentication types should be enforced 00:27:41 and under the paths for these two servlets, we will see that we will require for the first path, for the "DisplayServlet", only an authenticated user, 00:27:55 whereas for the "ManageServlet", we require not only an authenticated user, but in addition to that, also a specific scope, which is the "Create" scope, right? 00:28:08 So that's the little difference here, but just to explain and to show the different role assignment, and with the roles, the assignments of roles to the user. 00:28:20 In the "spring-security.xml" file, you can also declare those security and authorization settings declaratively 00:28:33 by – also very similar to the "xs-app.json" file – declaring the authentication requirement for a certain path 00:28:42 or the requirement to have a specific scope to access a path. So with that, we are almost done. 00:28:57 If you are not a big fan of declarative security, you can also make use of the XSA Security API or library. 00:29:11 As mentioned, it can be downloaded from the Service Marketplace, and it allows you, within your application code, within the code of your business application, 00:29:22 to first of all access the federated user information by getting the "UserInfo" object, and from there, accessing certain attributes, 00:29:35 and in addition to that, also obtain the scopes that the user comes with and check for those scopes. And this here a Service Marketplace link, so you need an S-user to download that. 00:29:50 So we are at the end of this unit. I hope you got a deep insight into all the parts which are necessary for security in the Cloud Foundry environment, 00:30:01 or which help you ensure security there, and let's continue in the next unit with the hands- on for this topic. 00:30:09 Thanks. See you in the next unit. Week 5 Unit 6 00:00:07 Hello and welcome to the openSAP course "SAP Cloud Platform Essentials", Week 5, Unit 6. We will continue directly where we left off, now with the hands-on. 00:00:18 So a short recap. Martin. Right, so this is part two of our Cloud Foundry adventure, 00:00:26 and we are going to continue with the sample application that we already introduced in part one. Before we build the application, deploy it, and configure it, 00:00:39 let’s briefly recap part one. What we have learned basically is that an XSA- based application in the Cloud Foundry environment 00:00:48 on SAP Cloud Platform consists always of an application router component and a business application. Both of those components are bound to the XSUAA service, 00:01:00 which issues the access token needed by the application router to access the business application. We looked at the detailed flow, how the application router obtains the JWT token from the XSUAA, 00:01:15 following the authorization code flow of the OAuth 2.0 specification, which is essentially the same as on Neo. 00:01:22 We looked into the design time elements for specifying the authorization in the business application of an XSA application, which were scopes, role templates, roles, and role collections. 00:01:36 We looked into the configuration or deployment descriptors of an XSA application and how those authorization checks and authentication requirements can be declared declaratively. 00:01:49 And finally we also looked at how this can be done alternatively using the XSA Security API library that can be obtained from the service marketplace to do those things programmatically. 00:02:03 So let’s get started with building and deploying the sample application. And for that purpose, we basically go into our... you can obtain all the code. 00:02:19 As usual, you can click on the additional material below the video. There you can then click on the link and find here the repository, 00:02:28 similar to in the last units, with the code, with the instructions. Here we also have the instructions on the slides. 00:02:35 So now let’s finish the application. Right. So here I have basically created my little cheat sheet 00:02:43 that allows me to execute those steps outlined in the readme of the Git repository. We first have to edit the manifest file of the application, 00:02:58 which you can find in the root directory. We already did that. 00:03:02 We already replaced all occurrences with 123456, which should be replaced with a unique number, 00:03:13 at least six characters of your choice. So probably you could, for example, use your P user. 00:03:20 That would be one way to do it because here it is important that this host is unique on the platform. Otherwise you will experience an error message when you try to deploy the application 00:03:33 and push it to the Cloud Foundry environment, you will see an error message that says that this host is already taken. 00:03:40 And here it’s not also only under the host field, but also the same number has four occurrences here in that file. 00:03:50 Exactly. So just do a replace, and that should make sure that you have used this ID continuously. So now let’s go into the… 00:04:01 So I’ve already checked out the Git repository. Yeah, so either check it out or download the ZIP file and then unzip it. 00:04:09 And basically then follow the instructions. So the first part is to build the application router component. 00:04:15 Therefore you have to go into the Web directory and just invoke npm install… Exactly, node and npm need to be installed for that. 00:04:24 – It’s in the prerequisites. – Yes. 00:04:26 Then finally, let’s do a Maven clean install, which basically now builds our WAR file. 00:04:33 That is used to deploy the application in the Cloud Foundry environment of your trial account, so that build also succeeded. 00:04:44 Now let’s log in with the Cloud Foundry console client to our trial account. Yeah, and here it is important that we are now using the Frankfurt region, 00:04:58 so we’re using the API eu10. As previously when we worked with Cloud Foundry, if you’re using the Virginia region, 00:05:06 then you have us10 here. And also make sure that if you’re working behind a proxy that your proxy is set for your command line. 00:05:15 Otherwise the connection here won’t work. Exactly. 00:05:18 So now let’s log in with our user that we already used, with the platform user that we used throughout the other exercises. 00:05:34 All right, and after doing so, before we push the application, we have to create the service instance for the XSUAA service. 00:05:46 That command refers to the xs-security.json file of our application in order to register all the scopes and role templates that our application defines. 00:05:56 And so we also created service instances in previous weeks. There we often also used the cockpit. 00:06:04 Here now we do it via the console client, which is one option for creating a service instance. 00:06:11 So now we do a push of our brand-new application. And while this is ongoing, let’s go back to the cockpit and define an additional trust relationship 00:06:25 to an IDP of our choice, which is the Cloud Platform Identity Authentication service, and tenant in Identity Authentication service. 00:06:37 You may not have such an Identity Authentication service tenant at home, but for the purpose of this demo, I also want to show how the federated assignment mentioned in the previous unit works with such a tenant. 00:06:51 So how to play around with those attributes? Exactly. 00:06:55 So here for you guys while you just create this, you just leave that step here out, and also then in the last part of the demo, 00:07:05 what we showed there with the attributes, you just leave that out and consume it as a demo, as one capability of the platform 00:07:13 which you can’t follow along with what is available for free. But you can also do everything else that we show here yourself. 00:07:22 So here what we show with the SAP ID Service as the IDP, you can also do with your own trial accounts. 00:07:29 Right. So, to establish the trust relationship to an IAS tenant, you have to either upload or copy and paste the metadata, 00:07:38 the SAML 2.0 metadata of this IDP into that field. This XML file can usually be obtained from the IDP by just invoking a public URL of the IDP. 00:07:51 It just contains public information about the IDP and allows you to quickly set up the trust relationship between your trial account and the IDP of your choice. 00:08:02 So if you parse that, and save that, you will see another new custom trust relationship appearing in your list. 00:08:11 And along with the one for SAP ID Service, which is there by default. Okay, so that's it. 00:08:18 Let’s take a look into our push. So far it has gone nicely, and now we have the application starting up. 00:08:27 Let’s see if we can already see the roles that have been deployed with our application router. So as you can see, under "Security", "Roles", 00:08:41 we should now have two roles instantiated with the push of our application. And those are named the same as the role templates we specified. 00:08:52 And the role templates we discussed in the last unit. Exactly. And in case you do not make use of attributes in the role templates, 00:09:02 the environment already creates these "default instances" of a role named the same as the role template for you. 00:09:11 Only if you make use of attributes in the role template definitions would you then have to create those roles yourself. 00:09:18 But in that case, since we only made use of scopes in the role templates, those roles were created under those names automatically for us. 00:09:28 But now we have to create the role collections ourselves. That’s true. This is something that you still have to do yourself. 00:09:35 Therefore go back to the account level. – Subaccount level. – Subaccount level, that’s true. 00:09:43 So you’re going together with the organizations. Exactly. So let’s first create a support role collection. 00:09:53 That should contain the display role of our application. So it’s just a read-only role collection for users in a supporter role of the application. 00:10:12 And if we go back here and specify a new role collection called Manage, then we will assign that to the role left, 00:10:25 which is the "RT_Manage" role. So here it's always, as we mentioned in the last unit, 00:10:34 in Cloud Foundry when you do this, you always need to create such a role collection and add your roles there. 00:10:41 So here there’s really one step that you have to do in order for the scenario to work. And now that we have defined these role collections, 00:10:49 we can either now statically assign a user with an ID to one of those, or also to all of these role collections. 00:11:00 Or we can do this dynamically based on a federated groups attribute. Again, this groups attribute can only be federated with a custom identity provider of your choice. 00:11:11 It is not federated by SAP ID Service. SAP ID Service only federates attributes like first name, last name, e-mail, and display name, 00:11:23 but no groups attributes because that would also require you to fully be able to manage the underlying user base, which for SAP ID Service is not the case. 00:11:33 This can only be done in your custom identity provider. But for SAP ID Service, we can still make use of the static assignment of a user. 00:11:41 So let’s see who’s the user. To show his assignments, and there are none so far, so let’s add one. 00:11:51 And here you can just directly pick one of your role assignments, role collections that we specified in the previous step. 00:12:01 So I only assign the support role, right? Okay, so with that, let’s go back to our console. 00:12:11 Okay, so the application has pushed and started. And going back to my cheat sheet, I need to finally create a route, 00:12:23 an additional route to my application. And that also has to refer to the unique number that we chose. 00:12:36 And let me go back quickly to my manifest file, and just copy and paste the right ID that I have chosen. 00:12:48 And with that, I can copy that command without the Run at the beginning. And paste that here to create an additional route. 00:13:02 So that route, as you can see, contains my subaccount identifier. And that allows the runtime to detect which trusted identity providers 00:13:14 I have configured for my subaccount, and therefore then show me basically that choice that I have configured in the trust relationships of my subaccount. 00:13:27 So with that, we should be ready now to test the application against SAP ID Service. So going back to the cockpit and to my space, 00:13:47 and to the application router, I should now see two application routes. And I will invoke this one with a new incognito window. 00:13:57 And as mentioned before, always for your application the entry point is your application router. And that one then federates the authentication. 00:14:08 And then directs you to your business application. Right. So now that's the login screen of the XSUAA. 00:14:18 Basically if I log in here with my SAP ID Service, user, I can also, as you can see here, choose an IDP that I configured as an additional custom IDP. 00:14:32 So the link text that I entered in the trust settings of this IDP shows up here. Now for that demo, I will only, I will log in with my SAP ID Service user... 00:14:57 All right. Now I’m logged in to the application, and let’s see whether I can access the display servlet, which should work. 00:15:09 Because we have the necessary role, which contains the scope. Right. But the Manage should not work because I don’t have the required scopes. 00:15:18 Okay, so let’s see. All right, so that seemed to work. 00:15:22 I am now logged in here and have been able to successfully access that servlet. Now let’s see if I can do the same with this. 00:15:33 And as you can see, it’s a little bit small here, but it says "Forbidden", which basically means I don't have the necessary role. 00:15:42 And this role contains the scopes that are required to access this part of the application. All right, now let’s play a little bit with the federated assignment based on the groups. 00:15:55 So for that, I have defined the trust relationship at my subaccount level before, and so we have this entry already here, but SAML always requires a bidirectional trust relationship. 00:16:14 So this is why I also have to configure the same, or the trust also in the other direction. 00:16:20 And I will basically, therefore, have to log in to my IAS tenant administration console, which is the one I've opened here, 00:16:30 and have to specify a new trust relationship to my trial subaccount. So let’s name that CFtrialAccount. 00:16:50 And now let’s open the metadata. And I’ve already downloaded the metadata in 00:17:01 I will show you how to obtain the metadata from your subaccount. So basically you have to invoke a URL that carries your subaccount name in the URL. 00:17:14 And if you open that – do that here in the browser. If you open that, the metadata is downloaded from your subaccount. 00:17:27 And that’s exactly the one that I now need to… Ah, sorry, that was the wrong one. 00:17:38 I now need to copy and paste here in the administration console. Not copy and paste, but upload. 00:17:53 Okay. So let’s save that. Now we have established the trust relationship in the other direction, 00:18:01 I will also change to the unique ID to "E-mail" so that the e-mail is returned by the IDP. And finally, most importantly actually, 00:18:11 I have to specify that I want to return this groups attribute of my users managed by this IAS tenant in my SAML response. 00:18:22 And therefore I just go here into the settings, and this may vary from IDP to IDP, so in other IDPs it may look a little bit different. 00:18:30 But basically, here I should also be able to see or find a groups attribute. That should hopefully… 00:18:40 – That was it.– That was it? Okay, I missed it. Ah, here it is. Right, so... 00:18:44 And I expose it to my applications under exactly that name. That’s the name is currently fixed for Cloud Foundry environments, 00:18:52 so that the Cloud Foundry environment always looks for an attribute with exactly that name. And it basically exposes the information about the user groups in my IAS tenant. 00:19:07 And I will make use of one user called
[email protected], and that user is assigned to a group Manager. 00:19:16 Okay, so… And exactly that name will be used 00:19:23 to then finally assign the user to that role collection. So let’s go into the settings to make this role collection mapping. 00:19:37 So here we go into the configuration of my trust relationship. So far I have not created any role collection mappings, so let’s do that. 00:19:45 So the role collection Manage should be assigned to any users that come with a groups attribute that equals Manager. – Okay. – Okay. 00:19:57 All right, and with that we can do another test. Let’s see if it works. 00:20:03 Let’s go back to our application. And this time, we will not use SAP ID Service but our IAS tenant. 00:20:18 So instead of logging in here, we go here. All right, so this is now the login screen of my IAS tenant. 00:20:26 There we are not using the hcp1 one user, but. Now this tturner user, exactly. 00:20:36 And let’s see. Okay, so now we’re logged in again 00:20:42 and hopefully we should now be able to access this Manage role, and voilà, it works. 00:20:48 Let us quickly take a look at the JWT token. So let’s copy and paste this value into an online decoder. 00:21:00 It's base64 encoded. And we have quite a number of these nice online tools. 00:21:08 So we can just paste it here and not encode it but decode it. I want it to decode it. 00:21:21 Here we are. Okay, let’s open that. 00:21:27 Maybe let’s do a little nice formatting. There's still some binary data left. 00:21:40 Let’s cut that and just take a look at this. And format that. 00:21:49 Basically, this is the JWT token that was generated by the XSUAA service, returned to the application router, passed on to the application. 00:21:59 And it contains a lot of information about the user: for example, the e-mail, the given name, the family name. 00:22:05 Basically, all these attributes that we saw in the IAS configuration of the attributes, but most importantly, it contains the group information federated with this groups attribute. 00:22:17 It contains Manager, and therefore the user was assigned based on the role collection mapping to the role collection Manage. 00:22:25 All right. And with that, we are done with this exercise. 00:22:35 And with that, we are also done with this week. So I hope you learned a lot about security in this week, 00:22:43 in the Neo environment, in the Cloud Foundry environment. Overall also the concepts which span both environments. 00:22:50 I hope you also got some hands-on experience, that you did some of the exercises. 00:22:57 And with that, I hope you have fun with your weekly exam, and then let’s see you in the next week. 00:23:04 Goodbye. www.sap.com © 2017 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.