openSAP Introduction to SAP HANA Cloud Platform

WEEK 4, UNIT 1 00:00:00:12 00:00:00:18 00:00:00:28 Hello again. Welcome to week 4 of the SAP HANA Cloud Platform course. In weeks 2 and 3, we concentrated on storing our data, both structured and unstructured data with the Persistence service and the Document service. This week will be all about security. We will be looking into security development, testing of security settings in the local and the cloud environment, and we will also be looking into troubleshooting. In week 4 unit 1, we will start with security development. So first of all, the question is: How can I authenticate a user before I give that person access to a protected SAP HANA Cloud Platform application? And, once I did that, how can I even check maybe the user's role to provide him with different information, depending on the role? So the question now is how to enable this functionality for a browser-based application like we have it for the SAP HANA Cloud Platform? So first of all, the user wants to have single sign-on, meaning you don't want to administrate users in the cloud. Ideally, you want to delegate the authentication and identity management to another provider, ideally an identity provider. And there are a lot that you can use, for example the SAP ID service, SAP NetWeaver single sign-on, or any other third party identity provider that supports the SAML 2.0 standard. SAML stands for security assertion markup language. That's a standard that defines how you can authenticate yourself. There are actually 2 options how you can do that in the SAP HANA Cloud Platform: You either use the SAP ID service that's SAP's identity provider in the cloud this is the default that the SAP HANA Cloud Platform uses. So you don't have to do any configurations, but it requires you to create an account for each of the users on the SAP ID service. And you can go there and check yourself how to do that at accounts.sap.com. But ideally, of course, you would also like to use your own identity provider in your corporate network and simply reuse what is in there. But first, let's look at how authentication is done with SAML 2.0. So as I said, SAML is the prerequisite, or SAML support is the prerequisite for the identity provider, and SAML is also the key technology that the SAP HANA Platform uses to delegate authentications and identity management to an identity provider. And what you see here is the flow of an access from a user to an application, and what the flow is with SAML. So, in the first step, the user wants to access an application via the browser, and that application, let's assume, is protected, so that in the second step, the SAP HANA Cloud Platform sends a SAML request via the user's browser to the IDP,

00:00:00:45

00:00:01:05 00:00:01:16 00:00:01:28

00:00:01:48 00:00:02:04 00:00:02:19

00:00:02:36

00:00:02:53

00:00:03:14

00:00:03:34 00:00:03:47

00:00:04:13

or the SAML 2.0compliant IDP identity provider. The identity provider in the third step then authenticates the user on an agreed mechanism, so this could either be something like user name and password, or an SAP login ticket, or a certificate that is installed on the browser. So there are different mechanisms, but you don't have to take care about that, so that's what the identity provider is doing for you. And once the identity is really done, the identity provider sends back a SAML response, again via the browser of the user to the application, and then the browser actually forwards the user to the application, and the user can access the resource. And the basis for all of this that it can happen is that you can define a trust relationship between your HANA Cloud Platform account and the identity provider. If you are using the SAP ID service, this is the default, the trust relationship is already there, and if you don't have it, you simply need to create this trust relationship, and we will show later on during this week how you can do that. But how to enable now authentication for such a browser-based application that we will create also in a small demo here? First of all, you need to change the deployment descriptor, so the web.xml file, and simply add this snippet that you see on the screen. And let's go through it step by step. In the tag login config, you see a tag called auth-method. It's standing on FORM, and FORM means that the SAML standard is used for authentication. There is also another authentication method which is called basic, where you would have to provide user name and password, but that's what we will not use now, so we will use our example FORM. And then you see underneath, security constraint. That security constraint defines Web resource, and it has a name, so we can give whatever name we want, so we just assume, we just give the name here protected, and then the URL pattern of that resource. So here we say it's /*, meaning that everything coming after the project name is actually protected. And then you see, underneath, an auth-constraint, meaning a role that is actually allowed to access this protected area. And here, we are using the role Administrator. And Administrator is a placeholder that you define in the section below, in the section with security roles. And there you see that the security role has a name Administration users so that's a description of the role name Administrator. And by using this role in the auth-constraint you're saying all users that are assigned this specific role will have access to that protected area. In the example we will go through now, we will actually also check if the user has a specific role. And if the user does not have this role, you will get an error message with logged in user

00:00:04:35 00:00:04:43 00:00:04:59 00:00:05:10 00:00:05:25

00:00:05:43 00:00:05:52 00:00:06:08 00:00:06:20 00:00:06:34 00:00:06:41 00:00:06:51 00:00:07:01 00:00:07:12 00:00:07:23 00:00:07:37 00:00:07:46 00:00:07:59 00:00:08:13

Page 2

does not have role administrator, 00:00:08:22 00:00:08:33 00:00:08:49 00:00:09:00 00:00:09:11 00:00:09:28 00:00:09:41 00:00:09:56 00:00:10:11 00:00:10:25 00:00:10:36 00:00:10:56 00:00:11:13 00:00:11:36 00:00:11:51 00:00:12:07 00:00:12:26 00:00:12:36 00:00:12:53 00:00:13:08 00:00:13:22 00:00:13:34 00:00:13:48 and if the user has this role, we will simply greet the user with an Hello Administrator. So, let's go now into our Eclipse to do this. As a starting point, we will be using now our Hello World application... ...in the SDK, so you say Import General Existing Projects into Workspace. Click on Next, select the root directory for your example. I have already selected the Hello World in the SDK samples folder, so I just say OK. Click on Finish. So, and now we have here our Hello World application. We open it up. We first open up the web.xml, our deployment descriptor here. So we double-click on it. We see here the servlet definitions they are already there and now we just go to our slides and copy and paste the text. So, let's go to the first slide here. So let's simply copy this text. Go back to our Eclipse, paste it, and we save this. This is wrong, so we also need to put the closing tag here. Just for you to see that whenever you do copy and paste, things can go wrong, like you see here below too. So I'm just putting it in here. Saving it, and that's it, no further errors. So we have now the configuration done. The next thing we will do is actually open up our servlet. and instead of just printing out Hello World, we will remove this. And take the snippet on the next slide, so this gentleman here. So we just copy this here, or we take everything here. So from PrintWriter until this closing bracket here. Copying and pasting to our code. So it doesn't know the PrintWriter method, no problem: we just right-click, say Source and Organize Imports, so that we see also now here in the imports it's using the PrintWriter class here. Saving this. OK, so now we are done. Let's add now this application to our local environment. Localhost Next. The port is fine, 8080. Adding our Hello World, clicking on Finish. OK. The application is being deployed now to our local environment. We see that the server launch configuration is updated here. So once all of this is up and running.... so we see here that the local environment is still on status Stopped, so we know that it doesn't make sense to try out things now. OK. Let's see. We start. OK, and it's started. It's still publishing here the application. We go back, or we go now to our browser, where we will be calling exactly this application it's called Hello World, it's on our local host, port 8080. OK, it's not yet there, let's wait a few seconds. OK, it's started and synchronized, so the application is available now. And, what happens now.... Aha... We were not able to simply get into the application. That's exactly what we wanted. So

Page 3

meaning that the application now knows before actually accessing any of my resources 00:00:14:04 that I defined in my web.xml let's look into it, and the resources are /*, meaning everything coming after Hello World, including our servlet, which we also modified, the Hello World servlet, and I need to provide a user name and a password. So that's all that we want to do right now. So what have we learned and went through now? Let's go back to our slides. We went briefly through the security assertion markup language 2.0, the standard, and how it works. We know now how to enable authentication for a Web application, and we also know how to define roles in our application. In the next unit, we will be taking exactly this example, and do testing in our local environment, and actually ensure that the user with the corresponding role can access the resource. So that's all for now. Thanks.

00:00:14:22 00:00:14:34 00:00:14:51 00:00:15:01

00:00:15:18

Page 4

WEEK 4, UNIT 2 00:00:00:00 00:00:00:17 00:00:00:25 Welcome to week 4 unit 2 of the SAP HANA Cloud Platform course. In this unit, we will be looking into local security testing. The testing of your security settings or security configurations can also be done on your local environment. And the way it works is that your local test user wants to access a protected Web resource, and then the application accesses the local HANA Cloud server, where you have test user accounts. And the test users authenticate against this local HANA cloud server, and if they have the right account with the right roles, they can actually access the application in the same way, with the same mechanism, as you would also do it in the cloud. And what we will do now in the next exercise is to take the application we have created now in unit 1 of this week, where we just saw at the end a login script, where we could provide a user name and a password, to create the corresponding user for the test user and provide this user with a role, and maybe also creating another user with a different role, and see how the application will react. And for that, we switch over to our Eclipse environment.... so there it is. We still have our application up and running locally from the last unit, so we switch here to our browser, call it localhost/8080/hello-world. And we get the login message here to provide a user and a password. So we configured our application accordingly, that whoever wants to access this application, and the URL pattern is /*, meaning everything coming after the project name Hello World, that everybody needs to have the role Administrator. But how do we configure users in the local environment? No problem. We just double-click down below, here, on our local runtime entry I'm moving it up so you can see it better, and click on the Users tab. And what we see now here is the server, and a list which is empty, where you can actually add users. So I will add a user, and the user ID is teddy. I provide the corresponding password, and it's created, so I just save this, and my first user for my local environment has been created. If I want, I can also provide here additional attributes, like, for example, an email address, so, I can say teddytest@opensap.com, if I want, and provide also here first name and last name, so first name is Teddy, last name is Test. OK. And finally I just need to resize this you can also add a role. So we will give Teddy the role of Developer. And then I will create another user, and the user is called Harry. I provide a password for Harry. To spend less time in configuring, I just put everything in here: harry.harmless@opensap.com.

00:00:00:38 00:00:00:56 00:00:01:11

00:00:01:27 00:00:01:43 00:00:01:55 00:00:02:11 00:00:02:22 00:00:02:36 00:00:02:45 00:00:02:57 00:00:03:09 00:00:03:25 00:00:03:42 00:00:04:00 00:00:04:13 00:00:04:32 00:00:04:48

Page 5

00:00:05:05 00:00:05:17 00:00:05:33 00:00:05:55 00:00:06:08 00:00:06:22 00:00:06:39 00:00:06:53 00:00:07:05 00:00:07:26 00:00:07:43 00:00:07:57 00:00:08:07 00:00:08:18 00:00:08:31

First name Harry, last name Harmless. I don't need to provide these additional attributes, I just put it here so it looks more complete. And, so Teddy has the role of Developer, and I give Harry the role of an administrator. So I'll just type the name Administrator here for the role. So I need, as the configuration has changed for the server, I need to save the changes. OK. The server tells me Started and Synchronized, so the application is up and running. We go now to our browser, I just reload again. I want to access now this application as Teddy. So Teddy... provide the password... I want to log in. I get an error message saying that the access to the requested resource has been denied. Why is that? As we said, only the... going to the employment descriptor, the web.xml file, only those that are in the tole Administrator can actually access the application. OK. So, I go back to my browser, I just close it and open it again, so that I have a new session here. OK. The application now, or the server asks me for my credentials. So now I'm Harry. We remember, Harry is an administrator. We log in. Hey, and it says hello administrator so, what happened? We defined Harry here as a user with the role of Administrator, and this is exactly the role that we are requesting for this application so that it works. And with that, we can go on now and test our application. We can add more users, we can play around with settings, until we are really sure that the local setup works fine. And once this is done, you can actually test your application also in your cloud account, which will then use the real users with their real roles. So what have we learned now in this unit? We have learned how to configure users and roles in the local development environment, and how to actually test the security settings in the local environment. So that's what we just did, we had two users, given them different roles, and the tool actually worked as it was designed. In the next unit, we will be looking into the testing of security settings in the cloud environment. So see you then. Bye bye.

Page 6

WEEK 4, UNIT 3 00:00:00:00 00:00:00:18 00:00:00:32 Welcome to week 4 unit 3 of the SAP HANA Cloud Platform course. In this unit, we will be talking about security testing in the cloud. In the last unit, we were successfully deploying an application on our local environment, which was access-protected. We created corresponding test users with roles, and we configured the application in a way that only a person or a user with the role Administrator can access it. Now that this is working, we would like to deploy the application to the cloud. But ideally, we don't want to create new test users now specifically just for the cloud environment, but would rather simply like to reuse the test users we created in our local environment. This is possible. So, together with your setup for the SAP HANA Cloud Platform on you local machine, there is already a test IDP installed, so we have a complete identity provider, pre-installed on your machine, which is SAML 2.0compliant, that we can use to cover exactly that scenario. Meaning that you have your local test users that access your protected application in the cloud. The cloud then delegates the authentication and identity management to the test IDP on your local machine, and the local machine authenticates you, and lets the test users access the protected resource, if the user has the corresponding roles. So let's now cover that in our demo. We will be doing exactly what we are showing in the slide, and to do that we switch over to our Eclipse environment... This is the Eclipse environment. and opening up the application we created in unit 2. And to make this more interesting, we will be adding now a few more lines of code to our code, showing simply after the Hello Administrator message the text with the first, last name and email address of the user that is accessing the application. We don't have to write this code right now. We simply reuse the code snippet on the official HANA Cloud documentation. You go to SAP HANA Cloud Developers' Guide Securing Applications Security Development Working with User Profile Attributes. We simply copy and paste this code snippet here, until the last bracket. Copy. And we paste it into our code, just after this Hello Administrator part. We have here two errors: that's because we need to organize the imports. So this UserProvider and UserManagementAccessor is not known, so, simply, you right-click, click on Source Organize Imports, and the error messages are gone. We save the application, and we publish it, on our local machine still, just to see how it looks like. So we create a new tab here: localhost:8080/hello-world. We need to log in via our Harry. Harry Harmless. Log in. Et voila! Hello Administrator, User Name Harry Harmless, harry.harmless@opensap.com. If we look into the code, it is actually using the attributes here; first name, last name, e-mail,

00:00:00:48 00:00:01:03

00:00:01:17 00:00:01:29 00:00:01:39

00:00:01:58 00:00:02:10 00:00:02:20 00:00:02:33 00:00:02:47 00:00:03:00 00:00:03:15 00:00:03:27 00:00:03:43 00:00:03:57 00:00:04:10 00:00:04:23

Page 7

that we defined in the local runtime. Here. 00:00:04:36 00:00:04:48 00:00:05:01 00:00:05:13 00:00:05:26 Right, so it's using exactly those texts that we defined here. So, now let's take the application and deploy it to the cloud. So we select SAP HANA Cloud, hahatrial.ondemand.com, application name opensap week 4 unit 3. We have here our account name, our user name. We provide our password for our account in the cloud, click on Next, select the Hello World application, Click on Finish. And after this is done, it shows up here, in the list of servers on our environment. It's on status Stopped. And we click on Start. Just as a reminder for you, we switch over again to the list of applications. As you can see here, I already stopped all the applications before starting the unit, and just as an advice, just to remind you, you have less issues if you stop all the applications after your unit, so that you don't get into an error message regarding the restriction, that you only can have only one application in run status Started. So the application is starting now, and while it is doing it, we will now create the trust relationship between our account in the cloud and the local identity provider we have. So to do that, we click here on Trust, and if we click here on Local Service Provider, so that's the service provider on your account in the cloud, click on Edit. We change it from default, which is using the SAP ID Service, to Custom. And we see now here a button to generate a key pair. That's actually what we need to later on do to design the SAML messages on the local environment. We save this. OK, and now the metadata that is necessary for the local IDP is now behind this link. So you click on Get Metadata, and you see that something has been downloaded. So we will need this file later on for our local IDP. But as a next step, we switch over to Trusted Identity Provider, and click here on Add Trusted Identity Provider, and we need to provide here a metadata file. So this metadata file, you get if you access your local IDP. And the local IDP you can access with this link, or meaning the metadata for your local identity provider. It's localhost:8080/saml2/localidp/metadata, and if I just reload that page, you see that a second file has been downloaded. Just down here. And that's exactly the file I need to select. So I click on Browse, select the file I just uploaded, that's this guy here. I open it. You see that all the other metadata is already filled out. You click on Save & Close. Ah, one thing we forgot... ...that we can do right now already is one second we need of course to select the right IDP. Click in here again. Localidp... The attributes. So we will add assertion-based attributes here, and those attributes are the ones that we defined in our local runtime, so that we also have access not only to the user but also to the

00:00:05:40 00:00:05:55

00:00:06:17 00:00:06:27 00:00:06:40 00:00:06:53 00:00:07:07 00:00:07:17 00:00:07:32 00:00:07:50 00:00:08:05 00:00:08:19 00:00:08:33 00:00:08:45

Page 8

attributes we defined here. 00:00:09:01 00:00:09:17 00:00:09:29 00:00:09:44 00:00:09:57 00:00:10:12 00:00:10:24 00:00:10:37 00:00:10:57 00:00:11:11 00:00:11:27 00:00:11:46 00:00:11:57 00:00:12:10 00:00:12:25 00:00:12:41 00:00:12:54 00:00:13:05 00:00:13:21 00:00:13:34 So for e-mail, first name and last name. So those are the ones we will be adding now here. Add Assertion-based Attributes: firstname, firstname. Another one. lastname. lastname. So we're giving them the same name on the cloud system as on the local system. And e-mail. So I click here on Save & Close. So, meaning now that we told the account in the cloud to trust your local identity provider. And now, the second step is to do the same for your local IDP. And for that, you have here under this Servers node here. If you open it up in the Project Explorer, you need to select SAP HANA Cloud local runtime config config_master com.sap.core jpass.security.saml2.cfg, and there is a directory called localidp. If you don't see it this could happen sometimes just right-click, and click on Refresh. And then it should show up here. And what we need to do, we need to switch to the local IDP directory, and simply paste the file that we downloaded from this Get Metadata button, so that's exactly this guy here. So, just Copy, and I just paste it in here Paste so that the local IDP now trusts your account in the cloud. So that's all you need to do. Well, not everything, but we will see what is still missing. But for now, we will just try to call the application from the cloud. It should be up already... yes. There it is. We click on it, select Hello World, and what happens? Let's see. Yes. It didn't use the SAP ID service, but it's now using our local host. And it's expecting you now to provide one of the users that you created on your local machine. So we are Harry again. So, and what happens if we click on Login? Access to the requested resource has been denied. So what are we missing? We missed to give the application also the corresponding role for Harry, so we need to give Harry the role of an administrator. We did that for our local environment, here, but this has nothing to do with the IDP, so the IDP is not aware of this role. But we need to create now here under Authorizations an assignment to the application week 4 unit 3. Administrator show who has those roles, and then assign actually our local test user Harry to that role. So Harry has now this role. And I will just create a new incognito window so that we assume that there are no cookies or sessions that have the old information from Harry. So we simply take the same hyperlink for the application, which is here... No, let's go here for the application. So I'm just copying and pasting, copying the link address and switching to my incognito window. I'm just making this bigger now again. Hello World. Again, we need to authenticate on our

Page 9

local identity provider, so we type in here Harry again. 00:00:13:56 00:00:14:12 00:00:14:23 00:00:14:34 00:00:14:47 Click on Login. Yes, we've finally made it! Harry Harmless: harry.harmless@opensap.com, on our account in the cloud, with the test user on our local environment. Exactly what we wanted. So, let's go back to our slides. We covered exactly this use case, that we have an application accessing a test IDP. So, what have you learned? You have learned how to set up your local test environment with the local test identity provider system. You know how to conduct end-to-end testing now in the cloud with the local test IDP. We made it! I hope you liked it. Thanks a lot, and see you in the next unit.

Page 10

WEEK 4, UNIT 4 00:00:00:00 00:00:00:18 00:00:00:24 00:00:00:36 00:00:00:47 00:00:00:59 Welcome to week 4 unit 4 of the SAP HANA Cloud Platform course. In this unit, we will be talking about the security configuration in the cloud. In the past 3 units, we went from creating an application, or securing an application in our local environment with additional users. Later on, also putting this application into the cloud, but again, using our local test users to test it. And now, the next step is actually to take a specific, or another identity provider, to actually authenticate against. And there are actually two options. The first option, and actually the default option for all the applications on the SAP HANA Cloud Platform, is the usage of the SAP ID service as identity provider. And the authentication works in the same way like in the last unit, with the difference that the IDP service is also not on your local environment, but somewhere in the Internet. So meaning that there is a trust relationship between the HANA Cloud Platform and the SAP ID service. And this is a built-in trust relationship, so you don't have to configure anything. The second option is that you use your corporate identity provider, which needs to be saml 2.0compliant. And here, actually, the configuration that you need to do is similar to the one we did in unit 3 of this week, meaning that you need to create a trust relationship between your account in the cloud and your identity provider. So with the identity provider, you need to do the same, and at the end, you have built a technical relationship based on trust between your HANA Cloud account and the account on your IDP. And with that, you can also do role assignments, either directly, via a static role assignment like we also did in unit 3. So you simply assign a certain user with a specific role, or indirectly, by using dynamic role assignments, where you take information from your IDP, like for example, the department that a certain person belongs to, and assign it to a group, giving that group the corresponding role to access the specific application or Web resource. We will now simply check and modify the application we did in unit 3, to use now instead of our local identity provider, the SAP ID service, meaning we will test out the option one I just talked about. That's pretty straight forward. We go to our Eclipse environment. We see that the application has stopped, so we need to start it again. And while it's starting, we need to switch now to our cloud cockpit. We need to switch again to the Trust tab, and here we have now our custom configuration that used our local IDP. We have to edit that. And instead of using the configuration type Custom, we set it to Default, save it, and that's it. So that's the built-in trust relationship between the account you have on the SAP HANA Cloud Platform and the SAP ID service. So both entities trust each other, and you don't have to

00:00:01:12 00:00:01:28 00:00:01:44

00:00:02:03 00:00:02:12

00:00:02:33 00:00:02:47 00:00:03:01 00:00:03:20

00:00:03:40 00:00:03:53 00:00:04:06 00:00:04:25

Page 11

configure anything, which is, of course, as you see here, the easiest way to go. 00:00:04:41 00:00:04:57 00:00:05:12 00:00:05:27 00:00:05:43 00:00:05:58 00:00:06:08 00:00:06:21 00:00:06:30 00:00:06:45 00:00:07:02 00:00:07:11 00:00:07:28 00:00:07:47 00:00:08:01 00:00:08:13 00:00:08:23 00:00:08:35 But of course, then you also need to use the SAP ID service for your account. And you see that the trusted identity provider switched from your local IDP to your SAP ID service. So let's see if the application still works. So we change now the IDP, the identity provider, we switch to our application. It's still starting, so I click again here on the link. I have here the link to my application, and once the application has switched to started it just happened; now, you see here that we no longer have the local host as our IDP, but (you saw it very quickly, flashing up) the SAP ID service. We see now here, we don't have access to that resource. So what happened is that the SAP ID service detected that you as the user p1940 and so on, or whatever your user is, tried to access the application. So the browser already knew you, because you were logged in to your HANA Cloud Platform, and you don't get access to it because you need to define now that your user in the cloud on the SAP ID service needs to have that specific authorization. And not any more the Harry user we used before from the local environment, but really your user in the SAP ID service. So for that, we need to switch now to Roles, select the account, and the application, select the role Administrator, and show who has access to it. We still see Harry, but Harry is not available now for this setup, so we need to assign a new user, which is actually the user that I use here on my trial account. So I will give myself now the role of administrator. So I have it. So I'm just taking this link now, and creating a new incognito window on my browser. So I just paste it in. OK, now... this was a certificate that is assigned to my SAP user, but I want to log on with my p-user. So I just type it in, p there it is and the corresponding password. I log on ...and there it is, my user name, Rui Nogueira, and with the corresponding e-mail address. So the system has authenticated me by using the SAP ID service. So we switched from the local test IDP on your machine to the SAP ID service. And that's pretty much it. So, going back to our slides, what have we learned in this unit? We learned how to implement single sign-on and identity federation with a productive IDP, like the SAP ID service or your corporate IDP. So the setup is similar for the corporate IDP like the setup we went through for unit 3. We know how to assign roles in the cloud, and you know that you can also use groups to assign roles indirectly with the attributes coming from your IDP. That's all for now. In the last unit of this week, we will look also into security troubleshooting, and see you then. Bye.

00:00:08:54

Page 12

WEEK 4, UNIT 5 00:00:00:12 00:00:00:17 00:00:00:24 Welcome to week 4 unit 5 of the SAP HANA Cloud Platform course. In this unit, we'll be looking into security troubleshooting. During the authentication of a user, things can go wrong. You might have mis-typed the password. You might be looking into attributes that you requested from the user, which don't seem to really fit what you are expecting. And for that, it's actually good to have some good tools that you can use to really identify the root cause for that issue. And for that, we have a lot of network protocol analyzer tools that we can use, like Wireshark, Fiddler, SAML Tracer, as well as the Logger functionality that is provided with the platform. During the next minutes, I will show you two tools. One is the Firefox Plug-in SAML Tracer, and the other one is the Logger mechanism from the SAP HANA Cloud Platform, and how you can use them to really track down issues. I'll switch over to Firefox, and the first thing you'll need to do, in case you haven't done it yet, is to download or to install the SAML Tracer Plug-in, I'm just making it bigger on your Firefox. So that's also why I have Firefox opened up now and not Chrome. And it's actually, if you look on Google, most probably the first hit. So click on it. It's an add-on for Firefox,, and just add it to your Firefox, install it, and you can go ahead and use it. I've already installed it here on my Firefox environment I'm just clicking here on Tools SAML Tracer, and the window opens up. So this window is now listening to the communication that is going on. And I will simply click on the Log On button. So I will provide the browser here with my account name and corresponding password. It's actually not the account name, it's the account user, of course... the corresponding password... and simply click on Log On. So we saw that something happened. Now we have our cockpit. But more interesting than our cockpit is actually what has been recorded now by the SAML Tracer. So we see there are a lot of Get and Post messages here; and we are most interested in the messages with the SAML stamp here. So we click on the first one, switch over to SAML... hmm, not really useful information yet for our case where we want to look at what has been sent to us. The second one... hmm, OK, not quite too. But the third one, which is actually coming from the cockpit, is interesting. It's actually a SAML response, which we see here, and we see that the issuer of this response is accounts sap.com, so that's the SAP ID service. We see here in this block the status of the authentication. And the status is a success, meaning that we were able to successfully log on here. Let's look what else comes. So... Signature values...

00:00:00:39 00:00:00:47 00:00:01:05 00:00:01:18 00:00:01:25 00:00:01:38 00:00:01:51 00:00:02:02 00:00:02:15 00:00:02:27 00:00:02:46 00:00:02:55 00:00:03:13 00:00:03:26 00:00:03:40 00:00:03:54 00:00:04:08 00:00:04:21

Page 13

00:00:04:31 00:00:04:44 00:00:04:56 00:00:05:11 00:00:05:20 00:00:05:34 00:00:05:48 00:00:05:57 00:00:06:11 00:00:06:21 00:00:06:30 00:00:06:45 00:00:06:59 00:00:07:15 00:00:07:26 00:00:07:36 00:00:07:51 00:00:08:03 00:00:08:14 00:00:08:27 00:00:08:43

The next interesting one is the subject, meaning the actual user that has been identified, and we can see here, under Name ID, the user that has authenticated. And this is my user that I used for the account. The next interesting part is the part with the conditions. So you see here that this authentication is valid for exactly 15 minutes, meaning that the authentication will work for 15 minutes, and after those 15 minutes, I will have to authenticate again. Good to know that. And, if you remember well in unit 3 of this course, we also worked with attributes. And you see here together with my user, we also get attributes like my e-mail address, my display name, my first and last name, and they are all sent with the corresponding value, and the name of the attribute. So one possible issue could be that you are using in your code an attribute, and instead of writing first name, you just, with this underline here, you wrote it with a hyphen, or with no character in between at all, and if you see what has been sent back from the ID service, and you try to match it to what you are using in your code, or in your configuration, you might already find out oh, I made a mistake here, I need to fix it, and either on the one side or on the other side, to identify what the issue is, so it's quite interesting to find out. So that's what you get here with the SAML Tracer. So some good method to find out what the SAML response is that you're getting, for your request, the SAML request from the identity provider. Another tool is the Logger itself: the Logger from the SAP HANA Cloud Platform account that you are using. So I'm just connecting here to an application. And we see here that there are some Logger files. And what you can do, you can if you have, of course, started your application, see what kind of packages are available. So we just start it, and now because as a good fellow, you always stop your application after each unit, so you don't face any issues in other units. So this will take a few seconds. I'm just clicking on this, and on the Logging tab here, and once the application is up and running, you can filter all the Logger names that come here, and set it to debug. So you want to look for packages with saml2. And they will show up here once the application has started. And then you set the saml2 package to logger level debug, so that you can also trace other, maybe more difficult issues, down to the root cause. And just one thing to note here is you should be very careful not to put the logger level too high. So debug, or All is actually the highest level of logging.

Page 14

00:00:08:56

It creates a lot of traffic on your account, because there are a lot of messages written into the log files, so you should really only use it when you really need to debug things, and to find out root causes. Let's see meanwhile if the application has started. So really, just use it if you have to. And after not needing it any more. go back and put it to the logger level Off. Or to Error, which is better, of course. So you see here, we are already matching 41 logger names here, and the one you would like to activate first is actually the jpass.security.saml2, or saml2.service, you can do both. And then switch the Log level from Error to Debug. The page has updated and now more logging information is created. The same also for service. And just try not to activate too much of those logger names and set them to debug, because, as I said, a lot of traffic will be generated. You can then look into the log files, which are here above, and see what happened on your account, and just open one of those log files. Trace down if any issues have occurred. And once you are sure that you've found the root cause and everything is fixed, don't forget to set the Log level back to Error, because you always want to know if an error occurred or not. And that's it. So, two tools that you can actually use to do security troubleshooting. I'm just stopping the application again. And go back to the slide deck. So what have we learned in this unit? We have learned how to use different tools to debug any security issues, and how to filter log files to identify authentication-relevant issues. That's all for now. Thanks, and looking forward to seeing you next week for the Connectivity Service. Bye.

00:00:09:11 00:00:09:21 00:00:09:31 00:00:09:41 00:00:09:53 00:00:10:09 00:00:10:22 00:00:10:33 00:00:10:46 00:00:10:56 00:00:11:07 00:00:11:17 00:00:11:28

Page 15

www.sap.com

2013 SAP AG 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 AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group 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. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices.