openSAP Introduction to Mobile Solution Development for the Enterprise

WEEK 6, UNIT 1 00:00:10 00:00:15 Welcome back to week six, unit one. We have already touched on this topic in previous weeks, for example, when we talked about the Mobile Platform and how it helps us to provide secure access to enterprise systems. In this week, we'll take a closer look at the topic of mobile security. There is no doubt that mobility brings tremendous value to the enterprise by streamlining or accelerating processes, enabling faster decisions and improving collaboration within the enterprise. At the same time, there is also little doubt that this comes at a price. Mobility introduces additional risks for the enterprise data. Why is this the case? First, let's look at mobile applications themselves. By nature, we want to use mobile applications everywhere, at any time, and not just when we are in the corporate facilities. To fulfill their functional scope, applications in the enterprise space usually require access to mission-critical enterprise systems and the sensitive data and functions they expose. So the applications need to cross firewalls and into secure zones, where mission-critical systems usually reside. Frequently, the applications need to persistently store sensitive data of some sort. Sensitive data can possibly include authentication data, personal data, confidential business data, or security-relevant configuration data. Even applications without explicit offline capabilities store such data, usually for convenience or for performance reasons. For example, they store the back-end credentials so that users don't have to enter them each time they log in. Or they persistently cache documents like invoices or technical specifications to avoid performance hiccups in zones with reduced bandwidth. We have to be aware that mobile applications run in an untrusted environment. In general, clients cannot be controlled as thoroughly as services, and that's also true for mobile devices. We don't have an established security infrastructure with fire scanners or firewalls. Users often install tons of applications on their device, sometimes from vendors or developers they do not know. There's no real protection against malicious applications. What about the device? Mobile devices themselves add to the risk. Compared to corporate PCs or laptops, there's a higher likelihood that they will get lost or stolen. Users carry them around wherever they go. And while complete hard-disk encryption is becoming standard for laptops, this is not always the case for mobile devices. For attackers, mobile devices are a valuable target. They offer a unique combination of data, data processing, and communication capabilities. There is the data stored by the apps, the contact data in the address book, the camera to take photos or videos, the GPS sensors that can determine your location, and all the communication capabilities like email, phone, SMS, and so on. All these functions and data can be access by applications via device APIs. This combination is unique and offers a very wide range of options for data leakage and misuse. Finally, there are the people that use the mobile applications. It is obvious that many of them don't want two devices for business and private use. They want to use the corporate device or bring their own device to the business. This leads to a merge of personal applications and enterprise applications, and of course, a merge of personal data and

00:00:33

00:01:01

00:01:20

00:01:42

00:02:09

00:02:23

00:02:41

00:03:03

00:03:28

00:03:42

enterprise data. 00:04:05 Attackers are continually improving their social engineering methods to trick users into some sort of data leakage or to get access to a resource. That's not a mobile-specific problem, but it is also very relevant in the mobile area. Let me mention just a few examples of potential threats or attacks in the mobile area. We talked about the powerful capabilities that devices expose. If applications get permissions, they have a broad range of options for misuse. Malicious or vulnerable applications might access data on the device and send it to an arbitrary server. They might changes settings like device proxy configuration or access point names. In the worse case, they might even load malicious coding to root the device. Man-in-the-middle attacks often come along with social engineering. An attacker somehow tricks the user into entering a server URL that points to a malicious server that can then act as a proxy and read or manipulate any data that is sent from and to the device. Eavesdropping is a threat for any communication that is not encrypted properly. We can imagine that the requests triggered by a mobile enterprise app contain sensitive data, so we should never process them without proper encryption. Finally, we need to protect the mission-critical systems against denial-of-service attacks that would flood a system with a huge number of requests that render it unresponsive. Sometimes even a short downtime can have severe consequences for an enterprise. So the conclusion is that we really need to take security seriously in the enterprise space. We have to establish appropriate protection mechanisms to avoid data leakage or misuse of sensitive data. We will now look at some of these protection mechanisms, at least some of them that we need to be applied for mobile application developers developing apps for the enterprise. We know that a typical mobile enterprise application consists of a client part, the application itself that runs on the device, the back-end part, which delivers the corresponding business logic, and the communication between those components over the network infrastructure. Protecting against mobile threats means protecting ALL these layers, and we will take a close look at each of these individually. First, let's start at the bottom with mechanisms we apply to protect the back end. The back end can be any system delivering business functionality. Usually, each back-end system has its own user management and authorization concept to ensure only valid users can access data and functions. In fact, it is a must that mobile applications do not break or relax any of these access controls. OData requests triggered by mobile applications have to be authenticated. This means the mobile user's identity has to be determined at the time of access and authorizations have to be checked. There are various authentication and single sign-on mechanisms that can be applied, such as basic authentication, which we have been using during the course, X.509 certificates, OAuth 2.0, SAML 2.0, especially in the case of Web applications. So we just rely on standards here. For the authorization checks, we use the concept of the back-end server. We do not want to invent anything new for mobile applications. We need to ensure that the user is allowed to consume the business functionality. This includes validation of the authorization to call the OData service and the authorization checks that are included in the business functionality itself that are validated when the OData service is processed. Validating incoming data for our mobile applications primarily means validating the OData requests. SAP NetWeaver Gateway performs many validations out of the box. For example, it checks the OData request against the construction rules defined in the OData specification and it validates against the metadata. This includes a type check of the incoming data. A virus check of binaries can also be added. Finally, we have protection

00:04:23 00:04:29

00:04:55

00:05:12

00:05:27

00:05:43

00:06:08

00:06:36

00:07:02

00:07:14

00:07:32 00:07:42

00:08:00

Page 2

against cross-site request forgery, or XSRF. We apply a token-based approach that prevents a user from unintentionally being tricked into state-changing actions in the back end. 00:08:45 Next we come to network infrastructure. The network infrastructure is extremely important for the overall mobile concept. The network needs to support communication between the device and the back end without allowing unauthorized access. A well-defined network topology can eliminate many security threats based on software flaws at both the operating-system level and the application level, or network attacks such as eavesdropping. The technical components involved can differ per scenario, but usually we have a public infranet infrastructure, and potentially a reverse proxy or VPN, that together with the SAP Mobile Platform enables mobile requests to enter the corporate Internet. To encrypt the communication, we use HTTPS. When setting it up, it's important to stick to the implementation of the mobile platform and the mobile operating system, and use the defaults to find their entrusted libraries, like our SDMC connectivity library, which is part of the mobile SDK. Otherwise, the protection might be weakened. As an example, for server certificate validation on the device, the mobile application could create its own policy objects to decide how to validate. I recommend refraining from this option and rather use default trusted verification, as implemented by the mobile system itself. I also recommend relying on a root certificate that is already available on the device when the application is initially used, either shipped with the device operating system or provisioned beforehand by some mobile device management solution. Multi-layered defense summarizes anything relating to the network topology itself, meaning the components that enable access to the back-end system, which can perform early request verification and stop malicious or unauthorized requests before they hit the back end. In our example scenario, to make it conveniently available for all of you, our SAP NetWeaver Gateway system can be accessed in the public Internet. Obviously, such a setup would not be recommended in a production scenario, as the system is exposed to any kind of attack, such as denial-of-service attacks. In a productive scenario, SAP NetWeaver Gateway would reside in the intranet and would probably be deployed on a separate machine that stands in front of one or several backend systems. SAP Mobile Platform, both in the on-premise and cloud versions, can ensure secure access to the back-end systems. While the on-premise version of SAP Mobile Platform uses a reverse-proxy-based approach, the cloud version leverages the SAP HANA Cloud Connector, a VPN-like tunneling solution that is available with the SAP HANA Cloud Platform. SAP Mobile Platform also supports network edge authentication, that is, with CA SiteMinder. This allows early authentication of the user before the requests enter the corporate systems. Finally, let's talk about the protection on the device. The basis for every secure solution is provided by the mobile operating system. We really should use these mechanisms, and these mechanisms are being proved over time. Examples are the app sandbox concept that is a basic protection layer for all data processed by an applicationor the use of cryptographic libraries provided by the mobile operating system. Often, it is not sufficient just to rely on these mechanisms. And another important factor for on-device security is a mobile device management solution that can enforce certain policies to lock or wipe a device that is lost or stolen. We will talk about this in a later unit. Finally, we have to protect the enterprise application itself. This includes encryption of sensitive data and protecting access to an application, for example, when we're invoking the application from the background. Actually, what we recommend with these last two items is to put a kind of protective wrapper around each and every sensitive app itself. At
Page 3

00:09:15

00:09:34

00:09:56

00:10:14

00:10:29

00:10:46

00:11:07

00:11:19

00:11:43

00:11:58

00:12:28

00:12:48

least up to now, that's something you as a developer have to provide. Mobile operating systems might add further features in that direction in the future. For example, with iOS, there are some enhancements in that direction. 00:13:24 In the next units, we will go deeper into how such access and data protection can be implemented.

Page 4

WEEK 6, UNIT 2 00:00:11 Welcome back to week six, unit two of this course. In the previous unit, we had a good overview of mobile security topics. We have found that the majority of mobile applications in enterprise space typically deal with sensitive data, such as personal data, financial data, or authentication data. In many cases, applications need to persist some of this data, either for convenience or for performance reasons. On the other hand, we know that this data might be at risk. Applications on mobile devices typically run in an untrusted environment, although security features of mobile operating systems are continuously improving. Devices can get lost or stolen. And mobile users sometimes just accept security-relevant dialogues without considering their consequences. In this unit, we will look at how to enhance our native mobile application, developed in the previous units, to add additional client-side security. Basically, we will see two enhancements. They are related to how we deal with protecting sensitive data stored locally on the device. The first enhancement is to securely store the back-end credentials on the device. So far, our application does not even store any data. So let's assume users would like to store these back-end login credentials so that they won't have to enter them each time. We will store this data, and we will do it in a secure way that does not rely on preconditions that we can't always control, such as a strong device passcode or full encryption on the device. Mobile operating systems provide APIs for encrypting data, but we won't have to deal with these low-level APIs. Instead, we'll be using SAP Mobile Platform data vault, a secure store that is part of SAP's mobile software development kit. The data vault is intended to securely store secrets like encryption keys, user and application login credentials, sync profiles, certificates, and other information that needs to be secured. This is exactly what we require for our application. The component is delivered as a standalone library, which we can just link into our project. It builds on the mobile operating system functions and its store is strongly encrypted with an AES 256-bit key. The data vault can be locked, and it requires a passcode to unlock it. And developers can set the number of failed login attempts before the data vault itself is deleted. Once the data vault is deleted, the sensitive data can no longer be accessed. Additionally, you can define a timeout when the vault locks itself, but we won't be using this timeout mechanism in this unit. The second enhancement is around protecting access to the application. We have to ensure that sensitive data and functions exposed by the application are protected appropriately. For example, let's assume our application shows sensitive product supply data, and an unauthorized person gets hold of that device. When an application is launched, it is usually just resumed from the background. Data and functions are typically visible when it's launched from the app background with no access control. In many cases, this is not acceptable. To understand the reason for this behavior, we have to briefly look at the life cycle of mobile applications. This diagram shows a typical life cycle of a native mobile application. It's a little simplified, but in general this shows how all mobile operating systems work. After the application is installed and started, it becomes active, or goes into a running state. Once the user launches another application or navigates to the home screen, the application is suspended and goes into the background. Without specific, uncommon user actions, the application keeps living in the background and its data is kept in memory. It is only closed by the mobile operating system if the device runs low on battery or memory, that is, when

00:01:02 00:01:12 00:01:21

00:01:50

00:02:06

00:02:22

00:02:38

00:02:56 00:03:06

00:03:48 00:04:00

Page 5

another application is launched and requires that memory. 00:04:35 This means that often, applications are open on the device, sometimes for several days or even weeks. So when we launch our example application, it is usually resumed from a suspended mode and all the data is visible immediately. This poses a security risk for our application. So how can we make sure the application doesn't just remain open in the background? Again, the data vault is a key component to implement this protection. We will use the data vault passcode as a mobile application passcode that protects access to the application. Considering the Android application and activity life cycle, we will ensure that once the application goes into the background or is closed, the data vault is locked so that sensitive data is saved. When the app is resumed from the background or started, the user is prompted to enter the mobile application passcode before sensitive data can be accessed again. When the use enters the password correctly, the vault is unlocked and the application can be used. If an attacker tries to break this protection, the vault will be deleted after a certain number of failed attempts and the data stored in the vault is no longer in danger. Before going into the system, let's look at the user interface changes that we're going to implement. First, we'll need to enhance our login view so that we can set an application passcode. This screen will only come up with an initial login when the application is started for the first time, or if it's reset. Once the user has entered the back-end credentials and set the passcode, the data vault is created and the back-end credentials are stored inside the data vault. In addition, we'll create a new view for subsequent logins or for logins when resuming from a suspended mode. We'll call this one the data vault login, and the view will prompt the user to enter the application passcode. On success, the data vault is unlocked and the user can access the application. In addition, the flow is extended so that whenever the application is stopped or suspended, the data vault is locked. So let's go and look at how this is implemented. We have a project here called OPENSAP_ANDROID_UIMOD. This is a modified version of the project we generated in unit four. So the first thing we have to do to add this data vault and this passcode capability is modify the layout of the first login page. That layout is in login.xml. The original login.xml just had two text views and edit view combinations for user name and password. We are adding an additional two for the passcode and then confirmation of the passcode. So Set Application Passcode and then Confirm Application Passcode. When we run this app, we should see these two additional screens. Additionally to that...this screen should only be run the first time. Subsequently, we want to just use the passcode to access the application. So we've had to add an additional layout called data_vault_login.xml. And data_vault_login now just asks for the passcode, so it's just got one text view/edit view combination for the passcode. Now we need to modify the login activity to decide, to select, between these two. We're going to base that selection on whether the data vault has been created or not. So let's go into the LoginActivity. In here, we have the code, which has been inserted here on onCreate. We can see that we're using this PrivateDataVault, which comes with the SAP Mobile Platform mobile SDKs. We initialize the data vault and then we check to see if the vault exists. If it does exist, we call our setDataVaultLoginView. If it doesn't exist, we will want to go to
Page 6

00:04:58

00:05:16

00:05:36

00:05:54

00:06:26

00:06:48 00:06:56 00:07:01 00:07:17 00:07:35

00:08:03

00:08:31

00:08:45

00:09:09

our InitialLoginView. So let's see how this behavior change works on the device. 00:09:36 00:10:05 Okay, I want to run you. So I'm going to Debug As>Android Application. Okay, so I have the device here. Let's run that. Okay. So we can see that we've got additional fields now on this login page. We've got our User Name and Password, as before, but now we also have this Set Application Passcode. For ease of use in this demo, I've already embedded the user name and password in the layout. So all I need to do here is set up my application passcode. I'm going to create an application passcode, which is 11223344. And again, 11223344. And then I can just log into the application. So now the application should work pretty much as it did before. We should get a list of products down and we can browse through these products as we did before: product detail, supply detail, etcetera. So let's go back. One thing we need to check here is that if I.... Say this is the sensitive data that I have running in my application, and I go to the home screen, and then I go back to this application, we'll see that this application is not actually protected. So after my initial login, anybody can pick up my phone and view my sensitive data. We want to avoid this by adding in our second bit of protection. So let's get out of this and start looking again at our source code. To add in the second bit of protection, I'm going to have to add in a new class into this application. This class deals with the lifecycle callbacks of the application, so when the application starts or goes into the background, etcetera. So let me import one here. File System>Yes>Browse...good. Software. And here it is. We're calling it ApplicationAccessManager. So let's have a look at this code. ApplicationAccessManager implements this ActivityLifecycleCallbacks interface. It's got quite a few callbacks, such as activity created, activity destroyed, saved or paused. We're only going to be using two. We are interested when the activity starts and when the activity stops. So if the activity goes into the background, the activity stops and this gets kicked off. And in that case, we want to get our data vault and we want to lock our data vault, so we lock our data vault. When the application comes back to the foreground, this ActivityStarted will be kicked off. And here we will want to first of all check whether we are in our login screen. If we are in our login screen, we don't want to re-initiate our login screen. But if we're not on the login screen, and we're on any other screen, we want to start the login screen. So we will get the login screen and we'll start the activity. There's one additional thing that I need to do. Sure, we've got a callback handler here, but we still need to register the callback. And that is done by looking at the application code. So in the onCreate for the application code, we are going to have this registerActivityLifeCycleCallbacks. You can see here we're creating an instance of our ApplicationAccessManager. And that's pretty much all we need to do. So let's see how the application behaves now. Let me Debug As...Yes. Let me have a look at the message...Disconnect. Let's say Debug As>Android Application and debug on our device again. So...let's wait for this thing to start up. So the first thing you notice now is that because we've created the data vault, our application asks for a passcode. So I can just type in the passcode, which is 11223344, and I should gain access to the application. No problem. It should bring back all my data as it did before.

00:10:33 00:10:52

00:11:13

00:11:44

00:12:01

00:12:32

00:13:05

00:13:17

00:13:45

00:14:02

00:14:23 00:14:36 00:14:44 00:14:55

00:15:18

Page 7

00:15:27

Excellent. So we've got all our data back. Everything's great. Now if we go and push this application into the background by going to the home screen, and then going back in, we see a different behavior now. Now the login screen comes back up and we have to enter our passcode again. So that security hole has been patched. Okay. Access the application, and we're back in. It unlocks and we should see our data again. Excellent. There you go. That brings us to the end of this demo, and also to the end of this unit. If we need to incorporate these concepts, however, in each of our enterprise applications, it would make more sense to use reusable components than to code these requirements manually each time, like we've done in this demo. In the next unit, we will show you how to use SAP's up-and-coming mobile SDKs for the SAP Mobile Platform.

00:15:55 00:16:07 00:16:17

Page 8

WEEK 6, UNIT 3 00:00:11 Welcome back to week six, unit three of this course. In the last unit we built a protection wrapper for our Android application. We used the SAP Mobile Platform data vault's components, so when implementing the secure store and the access protection, we didn't need to delve into the low-level encryption APIs on the device. However, there were still some tricky parts. For example, we had to look into the activity life cycle application to determine when the application goes into the background. Implementing such a security wrapper for a productive enterprise application certainly requires some effort. In this unit, we will learn about the MAF Logon Component: a reusable component that can help reduce effort so the developers can focus on business-functional aspects of the application. First, let me briefly explain what the SAP Mobile Application Framework is all about. As you can see in the figure, the framework basically consists of two parts: an extensibility framework and a set of reusable components. It belongs to the SAP Mobile software development kit, and it builds on the mobile services provided by the mobile operating systems and the lower-level SAP Mobile Platform client libraries, which were also used in the generation of the application. SAP's Mobile App Framework is available in iOS and Android, and support for Windows 8 is currently under development. Summarizing the purpose of the SAP Mobile App Framework is a set of reusable components aimed at helping you develop mobile applications more effectively. Let's look a little bit more at the functional scope. It's all about functionality and qualities that you would typically need when creating mobile applications for the enterprise. So it's about extensibility, about adapting the layout, working with addresses or monetary amounts, and about secure logon and protection of credentials and other sensitive data. So first, MAF's functions can facilitate extensibility. As an example, fields can be added, removed, or rearranged on MAF-enabled screens by configuration. There would be no need to recompile the application. Also, the flow of the application can be changed and actions can be added via custom-defined functions. Second, the skinnable UI components allow you to adapt the layout with respect to style, color, or images, again by configuration. When you're building applications that are later used by different organizations, this is a perfect way to enable enterprise branding. The primitive UI components basically extend the native standard UI elements of the mobile operating system. In addition, there are compound components that you often need for enterprise applications, such as a calendar control or a logon user interface. MAF provides help components, again focusing on typical enterprise requirements. For example, locale-aware formatters can properly format addresses, phone numbers, or monetary amounts and currencies. And last but not least, we have the Logon Component, which we will look at in the rest of this unit. So what are the features of the MAF Logon Component? Basically, it provides us with that protection wrapper with a secure store and the application password handling that we implemented in the last unit, but adds a lot of useful functions to it.

00:00:33

00:00:43

00:01:04

00:01:20

00:01:38 00:01:48

00:02:01

00:02:24

00:02:49

00:03:07

00:03:23

00:03:38 00:03:47

Page 9

00:04:03

For the application passcode, it additionally provides passcode change functions and the possibility to redefine password policies via the SAP Mobile Platform. With that, administrators can actually enforce and control a passcode, for example, depending on the criticality of the application or the availability of other mechanisms that could ensure appropriate protection of the application. For example, let's assume that mobile device management is used to enforce a strong device passcode policy and full device encryption, or even may be able to control which other applications are deployed. In this case, the administrator could decide whether to reduce the per-app protection and switch off the need for a user to define application passcodes to access the platform. MAF would still use the data vault to store the secrets, but it would generate a key instead of using user-provided passcodes. Another feature that is a kind of a relaxation of the application passcode approach is the timeout mechanism. The admin or, optionally, the user can define a certain timeout for which the application is kept open when suspended. Say you set the value to 10 minutes. If you're using an application and want to switch to another app for a few secondsfor example, to look at the contacts or make a phone callyou could return to the application without having to enter an application passcode. However, if the application is suspended for more than a configured time, the vault is locked and the data store in the vault is secured. Such mechanisms to relax the application password policy are intended to give administrators a tool to balance the trade-off between security and convenience. Entering a passcode before using the application certainly can be annoying; therefore, it is important that security is applied in balancein a balanced, targeted way, really focusing on the protection of sensitive data. Besides that, MAF supports a registration process. When building an enterprise application, you can't always predefine the server details or other application settings as we have done in our example. So you need to ensure that such configuration data is added, at latest, when the application is initially launched. MAF supports this with integration of SAP Afaria, SAP's mobile device management offering. SAP Afaria can add settings without interaction, and thus makes the initial setup process for the end user very simple. Next, the Logon Component can handle various authentication and single sign-on mechanisms, such as logon tickets, X.509 client certificates, and network edge authentication with CA SiteMinder. Finally, the Logon Component supports the various deployment options that can be used, such as on-premise and cloud versions of the SAP Mobile Platform and the direct SAP NetWeaver Gateway approach. It can automatically detect the server type and handle the differences so the application doesn't have to care about it. The Logon Component can provide a lot of useful functions for enterprise applications. It abstracts the need for the developer to deal with all the lowlevel registration, authentication, and data vault handling. And when you use the Logon Component, the application is prepared for future changes or improvements on the topic, such as additional authentication mechanisms, new developments on mobile operating systems, and new developments by SAP. Let me briefly explain to you how the Logon Component works and how you'll add it to the application. Basically, the Logon Component contains libraries and resources that include logic and views for the whole login handling. You add these libraries to your application and build path. The implementation itself is done exclusively in the initial activity of the applicationin our case, the LoginActivity in the onCreate

00:04:28

00:05:05

00:05:46

00:06:11

00:06:47

00:07:01

00:07:20

00:07:33

00:07:48 00:07:55

Page 10

method. The Logon Component is initiated and in this onCreate method and the login view is called. Any further login process is performed within MAF. The application just has to listen for the result of this process. 00:08:33 To do so, the LogonListener interface has to be implemented. It provides callback methods for various login process results. The most important methodand the only one we will actually implementis the OnLogonFinished. There, we just check whether the login was successful. If so, we set up communication based on the credentials that were either initially entered or fetched from the data vault. And then we trigger the main activity of the application. The Logon Component internally triggers either on initial logon or the application passcode logon, depending on whether the vault already exists and realizes all the features are listed earlier. Optionally, you can adapt the login views and brand them according to the corporate branding of the enterprise. I will now go into Eclipse and show you how the MAF Logon Component is added to the generated Android application we put together in unit four. The project that we'll be using is this OPENSAP_ANDROID_MAF project, which is essentially a modified version of the generated project we made in unit four. What I'm going to show you here is the modifications that are required to use the MAF Logon Component. All the modifications that we need to do are in the LoginActivity.java file. And we'll see that this is considerably less work than we had to put into securing our application manually. We see here that we are creating an instance of mafLogon, which is an instance of LogonUIFacade. And we are just setting some default values here. These are the values that will allow us to connect to the SAP Mobile Platform, cloud version. If we go and look up here at our settings, you can see that these are just the settings for our cloud. And this is the settings for our application that we registered on the cloud version: com.opensap.myfirst. And then this is the security profile that we specified to use in the application. So once you've set all these settings, we can initiate the logon screen, the logon facade. We also need to be able to respond to the logon events, because essentially this system takes control of our logon screen, so we need to specify a callback. And we can see that when we initiate this logon component, that we use this so that we're referring to the activity itself. If we go to where the activity is defined, we see that there is a LogonListener. That means that we have an onLogonFinished function where we listen for the positive result for our login. Thereafter, it's a matter of starting it up and then calling the function Logon, which generates the view that we will use to log on to the application. So let's run this on a device. Okay. Let's right-click, and then Debug As>Android Application. There we go. It should start up shortly. Okay, so we're presented with a very different screen here. I'm not going to try with the sample data. What I'm going to do is just push this Login button. And this takes you to the credentials setup screen. So we can see that we've got our server address already set up and we just need to type in our user name and password to continue. So let me start with typing in my user name. So let me get those credentials

00:08:59

00:09:13 00:09:19 00:09:33

00:09:52 00:10:01

00:10:21

00:10:47

00:11:26

00:12:11 00:12:22 00:12:29 00:13:05

00:13:31

Page 11

again. 00:13:45 Alright...P194...and then 00672...and then 66. Correct. I'll put my password in. And you'll notice that there is a Next button on the top there that has appeared. So I need to push that button. Here we go. So now what we're doing is it's going to connect to the cloud, or our cloud version of SMP, and authenticate us. And then it's also going to ask us for a passcode, so I've been authenticatedI need to type in a passcode. So let's type in a passcode here. I'm just going to use 11223344. Do the same thing: 1122344. Go Done. Oops. It says that the password must contain at least one lowercase character. The reason why it's asking for that is because if we go back now to our admin UI...let me just log in there again...and we go to our application...and we look at authentication, we see that this password policy has been enabled. We'll need a minimum length of eight characters, which we have put in, but it specifies that it must have at least one lowercase character. Again, this is a great example of how we can centrally administrate password policies. So let's type in a new one this time and we will specify a lowercase at the end there. 1122334...and them I'm going to use a lowercase character, a. 1122334a. So that should pass the password policy and get us into our application. There we go. We're through. So as before, now we're using our credentials and pushing our requests through the cloud to our NetWeaver Gateway back-end system and getting all our products back down. Now let's see, if we go out of this application, and just push it into the background, and then go back to it, what happens. Oh...got a bit of a breakpoint here.... We see that instead of going back to our data, we're brought back to our passcode screen. So we have to type a passcode in. So pretty much all the features we had before when we did this by hand, but now we also are integrated into the password policyoh. I don't want to re-register. I want to be done. And there we go. We're back in. Okay, great. You can see we saved ourselves a lot of time and effort by just using a reusable component from the SAP Mobile SDK. This pretty much brings us to the end of this unit. We have shown how we can use reusable components to help the developer with credentials and security requirements of the application. But is this all that we can offer, or can do, to secure mobile applications? What about the device itself? In the next unit, we will look at SAP's device management solution for the enterprise, called Afaria.

00:14:39

00:15:30

00:16:20

00:16:53

00:17:08 00:17:22 00:17:29

00:17:56 00:18:04 00:18:18

Page 12

WEEK 6, UNIT 4

00:00:11 00:00:24

Welcome back to week six, unit four. When talking about enterprise mobility in general, and mobile security in particular, we have to include mobile device management. Mobile device management software helps manage and secure deployment of mobile devices in the enterprise. By controlling and protecting the data and configuration settings for mobile devicesbe it a company-issued or BYOD, or bring you own device, scenariomobile device management reduces support costs and business risk. However, it is important to understand that it's usually not a replacement for the in-app protection mechanisms we've been developing in the previous units. Rather, it is a comprehensive enterprise security concept that needs both protection at the application level and management and protection at the device level. In this unit, I will demo some mobile device management features with SAP's mobile device management solution: Afaria. SAP Afaria is a trusted solution for any size company, and it is available both in an on-premise and cloud deployment option. So what you see here is a list of features or activities that SAP Afaria supports, sort of along the device life cycle. It starts with provisioning, where you can enroll and configure your device, and then covers the production or usage phase, and ends with decommissioning, for example, if the device gets lost or stolen. Many of these features work on APIs delivered by the mobile device manufacturers and mobile operating systems. So for you as a developer, there's usually not too much that you have to consider. There are some exceptions. For example, you can prepare the application so that SAP Afaria can configure it automatically. If you use the MAF Logon Manager, this preparation is available out of box. I will spend the rest of this unit exploring and using Afaria. So the first thing we're going to do with Afaria is I'm going to enroll my device in this MDM system. What we're going to do is we're going to try to restrict certain features of the phone. Say, for instance...let's see...let's look at the phone here. Say, for instance, I want to restrict use of the camera because I don't want to allow employees to take photographs of sensitive documents. Or I want to restrict use of YouTube. I want to insist on a passcode on the device. I also want to have, for instance, maybe a link to the company's Web site automatically placed onto the phone. So these are the kind of control mechanisms that you can use Afaria for. But in order to make that happen, we have to enroll the device first. So Afaria has got very easy ways of enrolling the device: an employee self-service portal that allows you to enroll your device. So let me go to that self-service portal now. This is the default self-service portal for Afaria. To enroll your device, it's quite simple. We just click on Enroll New Device. I've already installed Afaria, so I don't need to do that now. But if you have an Afaria setup, you can just install the Afaria client that is in the app store. What I need to do is generate an enrollment code and submit this code to Afaria. So I'm going to Activate Enrollment Code, and then I'm going to Submit. This brings up Afaria. And I can just say OK...and there we go. After a few minutes, we'll do some...we're using something called SCEP, which basically is the mechanism by which we install profiles with certificates. So I'm going to install this profile, and this profile is asking me for my current passcode, so let me type that in...and then it generates a key. Install...yes, I do want to install. It brings down the config payload, which will configure all the settings which I'll show you shortly in administrator. Okay, I'm done. Now let's see what has happened to my device. The first thing you'll notice is that the camera icon disappeared. That's because the config payload that came down is now configuring my device, saying I'm not allowed to use the
Page 13

00:01:05

00:01:25

00:01:59

00:02:15 00:02:20

00:03:20 00:03:33 00:03:45 00:03:58

00:04:24

00:05:05

00:05:26

camera. If I try to access YouTube, you will also notice that YouTube will not work. I cannot actually find YouTube because it's...well, there is...there it is. YouTube. Let's try and run it...obviously that configuration is not there. 00:06:00 00:06:08 So how is this configured? Let's go and look on the administrator tool. In the administrator we have concepts of device, groups, and policies. So effectively, devices are assigned to groups and groups are assigned to policies. So if you want to apply a specific policy, such as you cannot use the camera, you create that policy, apply it to a group, and then assign specific devices to a group. We have these dynamic groups, which means it will take a piece of information like the device type and it will automatically assign whatever device is enrolled to that group. So let's first of all look at my device. It should now be in the list of devices. I can search for my device by just specifying my name, because I know my device has got my name, and say Contains. There you go. There's my iPhone. I can select that and I can see, by clicking the Links button, what groups and profiles have been assigned to my device. There is a couple of profiles. We've got All Devices profile, BYOD profile, and iOS Default Group profile. And here, at the bottom, you can see all the policies that have been assigned. See, I've got iOS Default Settings, and then there's a few applications that have been assigned to me as well, which I could download and use. But let's go and have a look at this iOS Default Settings, what that policy is doing to my device. We can go to Policy, and we can go to...let's just filter by iOS. Here's iOS Default Settings, and we can use the Inspector. And let's look at the payload that came down. We can see that there are a number of things. So one, they were asking us to set a passcode. Now, I already had a passcode on my device, so it doesn't ask me to set it again, but it is specifying here that the minimum passcode length needs to be four. Then look at Restrictions. You see here it has been unticked to allow the use of the camera. And then also there's this Web Clip. That means it's actually brought down the link to a Web page and put that on my phone. If we go and look back at my phone, we should be able to see this link that has been put there. And there it is. SAP. This link. So I click on that and it should take me to the company home page. So there are some very cool features that you can do with this system. And of course there's a lot more information online. And of course there are courses that you can go on to learn Afaria. So I'm not going to go into this in any more detail. Well that brings us to the end of this unit. In the next unit, we will have a wrap-up and outlook for this course.

00:06:43

00:07:16

00:07:44

00:08:13

00:08:39 00:08:47

00:09:14

00:09:29

Page 14

WEEK 6, UNIT 5 00:00:11 Welcome back to week six, unit five. This will be the final unit of this course, and we will summarize the journey that we have traveled thus far. We will also look into further educational options available to you, and look at where we're heading to next. So far, we have learned how to build integrated mobile applications using enterprise tools. We have learned that when it comes to the enterprise, building mobile apps isn't a straightforward exercisethat there are many nonfunctional requirements that need to be satisfied in order to ensure adoption of our mobile apps. We have learned that by utilizing the SAP Mobile Platform, we are able to fulfill enterprise mobility requirements and scale out our applications to be used in varied enterprise landscapes. We have learned that it may be necessary to structure enterprise services in a way that suits the conceptual model of the application we are building, and how to achieve this with SAP's service enablement tools. We have learned that there are many ways to build a mobile application, and we now have a good understanding of what questions to ask in order to make sure we make the right design decisions to ensure the success of our mobile solutions. And we have learned that security is a key requirement for enterprises, and we have learned a number of techniques to protect sensitive information in our mobile apps. So what more can we learn and where can we learn it? SAP offers several options for those who would like to learn more. SAP offers a mix of free-based learning programs, such as the course you have just completed, and paid-for learning programs from SAP Education. SAP Education offers specialized, role-based training courses in SAP mobility. Just go to the SAP Education home page and search for your topic of interest to learn about the educational programs on offer. Further, the SAP Community Network helps participants to stay in touch with mobile experts and keep abreast of what's going on in the community. I also recommend exploring the SAP Developer Center for additional learning resources. So what does the future hold for us? The cloud version of the SAP Mobile Platform has a sibling that has all the capabilities of the cloud, plus more. The on-premise version of SAP Mobile Platform, version three, will be released soon and bring a host of new mobile development possibilities. This is a consolidated platform supporting a wide range of development paradigms, including Web, Hybrid Web Container, native, metadata-driven, and SMS-based application development. Along with the platform, we'll see a new version of the SAP Mobile SDK that brings a host of new features, such as App Builder, SAP's next mobile UI development environment, and Kapsel, a set of PhoneGap plug-ins for the enterprise. We will also see a new OData SDK supporting OData with offline and cached transactions. Well that brings us to the end of this course. Thank you for attending this course. I hope you enjoyed it and will join us for future courses on this topic and others. Thank you, and goodbye.

00:00:30

00:00:50

00:01:04

00:01:17

00:01:32 00:01:43 00:01:47

00:02:01

00:02:15 00:02:25 00:02:32 00:02:36

00:03:07

00:03:24 00:03:33

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.