The shift from desktop and laptop to mobile working is well underway. Many organisations today have either written one (or more) mobile applications for their customers/employees, or are considering it. They understand the importance that mobile computing is having and its growing dominance in the next few years as the primary platform for many users. However, as the use of the platform grows so do users’ expectations. They want an immersive, engaging experience, not just a mobile-friendly rendering of a website. If you don’t capture that ‘wow factor’ within the first few minutes, your app will be deleted.
From a security perspective, this causes IT a challenge. Now you have sensitive information being delivered outside of your network and stored on a potentially unsecured device. On top of that we now have the added complexity of an additional channel to deal with. To make matters worse, customers have come to expect security to deliver them an enhanced user experience, not just control their access to information. For example, user take web-based SSO for granted. You don’t expect to have to enter your credentials more than once when you access a company’s website. Typically, users don’t differentiate between a web and mobile channel and therefore expect the same level of user experience. This can be a challenge for an organisation to deliver. How do you re-use that existing Identity and Access Management platform that you have deployed for your web channel and extend it out to your mobile channel, thus gaining re-use whilst saving time and costs.
Fortunately, Oracle makes it extremely easy to do through our Mobile Application Framework. Now, you can take your existing Oracle Identity and Access Management platform and use it as the security layer within your mobile applications. You can use the full capabilities of the platform including risk-based authentication, social identity authentication, as well as authorisation. What’s even better is that you can achieve all of this without writing a single line of code. Yes, that’s right, no coding required.
Let me show you how.
First let’s take a look at my sample application. It won’t win any awards for design, but as you can see it’s made up of 3 separate features (N.B. a feature is a capability).
At the moment, there is no security enabled within the app so you can move back and forth between the features without any authentication.
Now we are going to add two different types of authentication to our application. Yes, as you guessed, the first is a risk-based authentication and the second is social login. Within my environment, I am using JDev 12c (12.1.3) and have Oracle Access Management installed and configured to protect web-based content. Therefore, the user directory and underlying connections are already configured. I have also enabled its Mobile and Social capability.
1. Oracle Access Management Mobile and Social Configuration
When you first enable Mobile and Social, most of the configuration is already setup for you by default. In addition to the out-of-the-box configuration, I created an Application Profile for my MAF application.
The key settings here are to configure it as a “Mobile Configuration” and to provide the platform specific settings. I then configure the MobileServiceDomain.
In this screen I need to configure the security handler and then link my Application Profile to the service domain. Since we want risk-based authentication, then we select the pre-defined “OaamSecurityHandlerPlugin”. After adding our MAFTest application profile to this domain we can save the changes.
That’s all we need to configure on the server side for now, so we can focus on our MAF application.
2. MAF Sample Application Configuration
Within my application I can easily see the three features that I have defined. At the moment, none of them have security enabled. We will start by enabling security for the Risk-based login. This is done by checking the box under “Enable Security”.
We have told MAF that we want to secure that feature but not how we will authenticate. So, the next step is within MAF-application.xml where we define the connection for our security server. In our case we are configuring a connection to our OAM mobile and social service. We do this by adding a new MAF Login Connection.
As you can see we have used the Service Domain and Application Profiles that we created earlier. Also, I am using a HTTP load balancer between my application tier and external, so I am pointing my connection at port 80. If you were connecting directly to OAM on the default port you would specify port 14100.
Now that I have defined the connection, I can associate that new MAF Login connection with the feature I have enabled security for.
Now, I can save all of my work and deploy my application.
This time when I try to access the risk-based login feature, I get a very different user experience.
Firstly, I am prompted for authentication. These are the same credentials that I would use for any other access (e.g. web-based access) since we are re-using the same access management platform. However, rather than just providing username and password authentication, as part of the login process the Oracle Access Management platform is undertaking a risk-based assessment of the attempted login. It is capturing a number of characteristics such as the device’s unique fingerprint and location information and comparing it to standard behaviour. In this case, it has decided that there is sufficient risk to require an additional level of authentication, which is does through sending me a one-time code. This could just as easily be configured to require me to answer a pre-registered challenge question. You can see a summary of the session within the risk engine web-based UI below.
This shows the a number of policies were executed, a risk score determined and an action of “Challenge” was decided. For organisations not using the risk-based capability of Oracle Access Management, we can provide standard, non risk-based authentication. All we need to do is change the security plugin within the Access Management to use the standard plugin.
So, in summary, what we have just seen is that through configuration alone we have provided security to our sample MAF application using our existing Access Management platform and without writing a single line of code, all through point and click configuration.
Now, let’s extend our use case slightly. We have provided risk-based authentication but what about a lower level of authentication. Many organisations are taking advantage of social authentication to onboard user’s easier and lower the barrier of entry to user’s to access personalised content. It also gives organisations access to a range of social information about the user they wouldn’t previously have had access to. Of course, most social networks expose the APIs to provide this. However, despite using open standards such as OAUTH and OpenID, the integration with each social network is slightly different in its use and configuration. We have extended Oracle’s Access Management platform to take away the headache of trying to integrate with each individual social provider and instead made it a configuration exercise. Yes, you guessed it, without any coding for the developer of your mobile application. Let’s have a look at the configuration.
3. Social Identity Server Side Configuration
The first step is configure each of our providers that we want to use. Whilst most social identity providers offer their services for free, you have to register and obtain the necessary API tokens to call their service. Within the Access Management console we define the connection specific settings, such as those shown below for Facebook.
Instructions are provided in the product documentation around how to obtain the consumer key and secret needed. As you can see, we also define which attributes we want the social provider to return. At the time of writing this, the Oracle Access Management platform provider out-of-the-box integration with Facebook, Twitter, LinkedIn, Google, and Yahoo. You can create your own custom providers if you have requirements beyond these.
Once we have configured the providers, we define an Application Profile covering social identity login.
This application profile includes details of which social providers we want to enable and how we map the attributes returned from each provider to local attributes in the user repository. In our example, we will just configure Facebook first.
We then create a new Service Domain to link our Application Profile to social login.
Again, that is all we need to configure on the server side. Now to focus on the client.
2. MAF configuration for social identity integration
As before, the first step is to tell MAF that we want to secure our second feature.
We then have to create a new MAF Login Connection for our social integration.
Just as before we create a new connection and configure it to point to the configurations we defined above. Once we have created the connection, we map it to the feature that we want to apply it to, in our case, mycomp.Help2.
That’s it for configuration. Now we can deploy and test our application. This time, after deploying we see a very different flow.
The user is shown their available social providers and they pick one. They are then taken to that provider to authenticate and provider consent (if they haven’t done previously) before being returned to the sample app as an authenticated user.
What’s really nice about this approach is that if I want to change providers, I can make the change server side and it immediately takes effect. So, if I wanted to add Google as a second provider, I make the change in the Oracle Access Management console to add Google to my Application Profile.
When I apply the change, the next time I try to login to my MAF application through social integration I see that change.
Of course, all of the login screens etc that you have seen can be customised. I am using the default, out-of-the-box screens for simplicity.
In summary, what you have seen in the last section is how I can configure a MAF application to support authentication through a range of social identity providers, again without writing a single line of code.
There is also a great video from a colleague that explains each component in a bit more detail.
I hope you found this useful.