ddd

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, who is a product owner in our team, especially focusing on the topics of security. Hi Martin. 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, and as you also know, the platform has quite a number of services, and for this week we will focus exclusively on security 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, 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. 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. 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. We will look at security, and specifically in terms of our runtimes. That's true. 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, 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 signon 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 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. 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, 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. 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. 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, 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 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. 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. 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. 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 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. 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, and that's now quite a number over the past few years, I've never actually seen a requirement from our customers that said: "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." 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 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. 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. 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. 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. 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. 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. 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. That's true, and that's what this slide is all about. So if you as a developer want to get started quickly 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. 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 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. 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. That's true. So it's basically our large identity provider that manages the users that we authenticate with our services that we offer, 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 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. 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, 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, 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, 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. 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, 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. 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 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. 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. 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. 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. 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. 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. 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 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] So let's quickly talk about business users and platform users. You see that terminology all over the place in Cloud Platform. 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? 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. 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. 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. But we definitely do not recommend using SAP ID Service for productive scenarios. - You don't have that much control? - Exactly. 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 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. 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, 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. Would they usually be the developers and administrators of your application? Absolutely, yeah. 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. 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. 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 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. 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 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 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 to even integrate with the user base in your corporate IDP. However, that comes with a small limitation. 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. 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. 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. 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. 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. 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. 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 to roles defined by your business applications. So we no longer talk about these platform roles 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 – 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, 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. 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". 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 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. 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, that assignment can really only be made statically, which means you assign a user with ID "abc" to role "xyz", 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, 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? 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", 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 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, then he wouldn't have the rights anymore. Right, so this means also from an administrator's perspective, from a platform user's perspective, 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, which can be your corporate directory, then that has an immediate effect when the user logs in the next time 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. 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. All right, and with that, I'm done. So what have we learned? 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. 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, 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, or your own corporate identity provider. And we have also covered authentication and authorization, so the two main things here. 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.