By using MobileFirst Server, you can protect external resources by applying the OAuth 2.0 protocol. The OAuth 2.0 protocol is based on acquiring an access token, which encapsulates the authorization that is granted to the client.
MobileFirst Server acts as an Authorization Server and issues an access token that can be validated by the external service.
Client applications request the access token from MobileFirst Server and sends the token to the external services.
The scope of the access token is a realm (or several realms), which are defined in the MobileFirst project.
Authentication through an access token over OAuth 2.0
The OAuth 2.0 authorization framework enables an application from independent software vendors (also called third-party application) to obtain limited access to an HTTP service.
The implementation uses three roles of the OAuth protocol:
Resource Server: third-party server The server that hosts the protected resources. It can accept, and respond to, protected resource requests by using access tokens.
Client: app An application that requests protected resources.
Authorization Server: MobileFirst Server The server that issues access tokens to the client after it has successfully authenticated the resource owner and obtained authorization.
Overview of the Resource Server component
The Resource Server is an external server that hosts the available resource.
One use case is that services are deployed on a cloud, such as IBM Cloud. But this flow is not restricted to that case and works with any third-party server.
The public key that is necessary to verify the token must be configured for this component.
Java and node.js libraries are provided for offline validation.
Overview of the client component
As of IBM MobileFirst Platform Foundation 7.1, the MobileFirst SDK can now also be used to access the Resource Server through WLResourceRequest. This API handles the OAuth-based security model protocol and invokes the required challenges.
An External SDK can also be used to access the Resource Server. The external SDK must be able to attach a header to the request.
Overview of the MobileFirst Server component
MobileFirst Server uses the authentication infrastructure to issue an access token for the requested scope (MobileFirst realm).
Configuring the MobileFirst project
Configuring the MobileFirst project consists in configuring the scope for the access token. The scope of an access token must be a predefined realm in a MobileFirst project. You configure realms in the MobileFirst_project/server/conf/authenticationConfig.xml file.
The expiration period of a scope token (realm name) is defined by the expiration attribute of the login module that is associated with the realm.
If you want to configure a login module called StrongDummy with an expiration attribute, edit the authenticationConfig.xml file in the login module section as follows::
If you want to configure a realm called SampleAppRealm that is associated with StrongDummy, edit the authenticationConfig.xml file in the realm section as follows:
To use this feature, preferably use or create your own keystore and configure MobileFirst Server to use it.
For an example in an unrelated context, see the topic about configuring device auto provisioning, in the product documentation.
Important: Using the default MobileFirst Server keystore is NOT secure!
Configuring the external service
For your external service to accept the access token, you must add a validation library to your service, which must be able to validate the token with either online or offline validation.
You can use one of two libraries for this purpose:
com.ibm.imf.oauth.common_1.0.0.jar - Java lib
The node.js library, which can be downloaded through npm.
For MobileFirst Server installation - You can find the necessary java library and files in: installation_dir/MobileFirstServer/external-server-libraries
For MobileFirst Studio - When you create a new project, you can find the java library and files in: project_dir/externalServerLibraries
External service configuration - Using Java
The purpose of this module is to enable offline validation of access tokens that are generated by MobileFirst Server for Java web applications.
Validation of access tokens that are generated by MobileFirst Server is also possible for node.js servers.
To use the Java library, you need three files:
Certificate - For the associated sample, the certificate that has been exported from the MobileFirst Server Keystore. You can use the Java keytool. In production, preferably use your own keystore as explained in Configuring MobileFirst Server to use a keystore.
com.ibm.imf.oauth.common_1.0.0.jar
OAuthTai-1.0.mf
server.env - It may also be useful to create this file in the same directory as the server.xml in the external server. In this file you will add the URL to the authorization server so this way it will be included in the environment variables of your deployment.
External service configuration - Using Java: servlet filter
Add the com.ibm.imf.oauth.common_1.0.0.jar file to your server under this path: usr/extension/lib
Add the OAuthTai-1.0.mf file to the path usr/extension/lib/features
Add following entry in environment variables of your deployment. One of the ways is to add it into server.env, which locates in the same directory of your server.xml. publicKeyServerUrl=URL_to_authorization_server
where URL_to_authorization_server is: http://:/
Add a security constraint and a security role to the web.xml file of your external server, as shown below:
<security-constraint><web-resource-collection><web-resource-name>RESTServlet</web-resource-name><url-pattern>/api/protected</url-pattern></web-resource-collection><auth-constraint><role-name>TAIUserRole</role-name></auth-constraint></security-constraint></p><p><security-roleid="SecurityRole_TAIUserRole"><description>This is the role that MFP OAuthTAI uses to protect the resource, and it is required to be mapped to 'All Authenticated in Application' in WAS and 'ALL_AUTHENTICATED_USERS' in Liberty</description><role-name>TAIUserRole</role-name></security-role>
You must modify the external server server.xml file, too. Configure the feature manager to include these features:
The scopes that you provide are all defined in the authenticationConfig.xml file of the MobileFirst Project. You can provide multiple scopes.
Using the WLResourceRequest API
The MobileFirst WLResourceRequest API provides built-in support fur using MobileFirst access tokens for the following platforms:
Hybrid - JavaScriptTM
Android
iOS
Windows Phone 8.1
Use of WLResourceRequest: JavaScript example
This JavaScript example shows how to use the client-side API for access to an external service.
functioncallProtectedRestAPI(){varurl=EXTERNAL_SERVER_URL+REST_CONTEXT_ROOT+PATH_PROTECTED;varrequest=newWLResourceRequest(url,WLResourceRequest.GET);request.send().then(function(response){showResult(response.responseJSON.description);},function(error){showErrorResult("failed to get scope!");});}
Reporting analytics
Java
The TAI library is capable of reporting analytic events to IBM MobileFirst Platform Operational Analytics. To do this, you must configure the Resource Server that contains the TAI with your Analytics URL and credentials.
The MobileFirst Operational Analytics server is protected by basic authentication. When you installed this server, you configured the data entry point and basic authentication credentials. To configure the Resource Server, you must provide the Analytics credentials, specifically the URL to the data entry point, the user name, and password. These properties are set with the following property names:
- imf.analytics.url
- imf.analytics.username
- imf.analytics.password
If your Resource Server is running on Liberty, you must configure these properties by using JNDI. You can do this by adding entries to your server.xml file. For example:
If your Resource Server is running on WebSphere Application Server, configure these properties as environment entries.
To do this, navigate from the WebSphere Application Server administration console to Servers > Server Type > WebSphere application servers > {your_server} > Server Infrastructure > Java and Process Management > Process Definition > Additional Properties > Environment Entries > New.
This is where you had to set publicKeyServerUrl when you set up OAuthTAI.
After these properties are set, the TAI will post its events to MobileFirst Operational Analytics.
Node.js
You can protect your resources that are running on Node.js servers with OAuth-based MobileFirst security. Like the Java implementation, the MobileFirst Operational Analytics server is protected by basic authentication. You must configure the Resource Server by connecting the passport-mfp-token-validation module to the Analytics server.
The passport-mfp-token-validation npm module provides passport validation strategy and a verification function to validate access tokens and ID tokens that are issued by the MobileFirst Server.
The following example shows how to use mfpStrategy in a node application:
varexpress=require('express'),passport=require('passport-mfp-token-validation').Passport,mfpStrategy=require('passport-mfp-token-validation').Strategy;//the configuration ('config') is optional if you wish to report//events to the Analytics Server.varconfig={url:'http://localhost:10080/worklight-analytics-service/data',username:'admin',password:'admin'};passport.use(newmfpStrategy({publicKeyServerUrl:'http://localhost:10080/WLProject',analytics:{onpremise:config}}));</p>
varapp=express();app.use(passport.initialize());</p>
//protect api with MFP strategy using scope Realm1 Realm2 Realm3app.get('/v1/apps/:appid/service',passport.authenticate('mobilefirst-strategy',{session:false,scope:'Realm1 Realm2 Realm3'}),function(req,res){res.send(200,req.securityContext);});app.listen(3000);
To start this example, issue the following commands:
Inclusive terminology note: The Mobile First Platform team is making changes to support
the IBM® initiative to replace racially biased and other discriminatory language in our code and content
with more inclusive language. While IBM values the use of inclusive language, terms that are outside of
IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other
industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the
documentation to reflect those changes.