Monday Jan 20, 2014

The case for Mobile OAuth in the OAM OAuth service

Introduction 

Several OAuth Clients are consumer applications that cannot keep the client secret confidential (application password or private key). These OAuth Clients are called public clients or non-confidential clients. Mobile Client applications i.e. native applications on mobile devices are also categorized as public clients because when a native application is first downloaded from an app store to a device, the client credentials that uniquely identify the client application are baked into the application. Since all users that download the native application have access to the binary, a malicious user could easily decompile the client credentials out of the binary and insert their own credentials. During an OAuth flow when the access code gets exchanged for the access token this leads to a major vulnerability as there is now no secure means of really identifying who is actually receiving and using the access token.

Hence, providing a mechanism to secure the mobile application on the device in order to ensure trusted access is a key requirement specifically for enterprise mobile applications that routinely require access to sensitive data. The OAM OAuth Service provides key features in the OAM OAuth 2.0 Service’s Mobile OAuth flow to facilitate secure enterprise mobile access for OAuth Client applications.

How it's done : Overview - Mobile Application Registration and Mobile Device Identification

The OAM OAuth  Service provides built-in support for a mechanism for mobile applications to be first registered with OAM to use OAuth Access Services. Security is enforced for mobile applications by creating a client profile and issuing client tokens specific to the application on a device. The user provides explicit authorization to register each mobile OAuth application. In the OAM OAuth 2.0 Service, mobile application registration is modeled using the same paradigm as the OAuth protocol flow where mobile application registration is modeled as a scope for which the user needs to provide explicit consent. As a result of the mobile application registration the application is issued a client token. The mobile application always submits this client token as an input parameter for accessing OAM OAuth 2.0 Service end points. Furthermore, the OAM OAuth 2.0 service also allows easy coupling of device identification with mobile application registration where mobile devices and applications can be checked against fraud and security using a built-in integration with Oracle Adaptive Access Manager (OAAM). The mobile application passes device claims along with the client token for accessing OAM OAuth 2.0 Service end points and the OAM OAuth2.0 Service provides a configuration to make certain claims as mandatory and certain claims as optional.

Sunday Jan 19, 2014

Using the OAM Mobile SDK to secure native mobile apps - Android SDK

Introduction

In this blog post I'll round out addressing a key strategic area for our customers--i.e. securing mobile native apps with Oracle Access Manager using the mobile client SDK. In previous posts I covered securing iOS based mobile clients using the iOS SDK as well as covered the required OAM server side configurations involved in securing these applications. In this post I'll cover the Android SDK. Finally, the sample android app used here in this post as an Eclipse ADT project is available for download at :
https://www.dropbox.com/sh/6tc7vxyn9zn43an/JloXNybqN_

Invoking Authentication Services

Initialize

The first step is to create an object of OMMobileSecurityService and initialize the Android SDK by providing required Mobile and Social server details.

This constructor initializes the OMMobileSecurityService object using the Map<String, Object>:

public OMMobileSecurityService(Context context, Map<String, Object> configProperties,OMMobileServiceCallback callback)

This enables you to specify required and optional parameters to initialize the SDK using the OM_PROP_* properties in the Map. The OM_PROP_OAMMS_URL parameter is the URL (including protocol, host name, and port number) required to reach the Mobile and Social server. Only the HTTP and HTTPS protocols are supported. The OM_PROP_APPNAME parameter is a unique identifier that identifies the application. This String value must match the application "Name" value located in the Application Profile section of the Mobile and Social server administration console. The OM_PROP_OAMMS_SERVICE_DOMAIN parameter specifies the name of the service domain that has been created on the Mobile and Social server. The application profile that the OM_PROP_APPNAME refers to should be defined as an application profile in this service domain.

The following snippet in ConfigurationActivity#OnClick() populates the Map<String,Object>:

Map<String, Object> oamConfigProp = new HashMap<String, Object>();

oamConfigProp.put(

OMMobileSecurityService.OM_PROP_AUTHSERVER_TYPE,

OMMobileSecurityService.AuthServerType.OAMMS);

oamConfigProp.put(

OMMobileSecurityService.OM_PROP_OAMMS_SERVICE_DOMAIN,

oamDomain);

oamConfigProp.put(OMMobileSecurityService.OM_PROP_APPNAME,

oamAppId);

oamConfigProp.put(OMMobileSecurityService.OM_PROP_OAMMS_URL,

oamServerURL + ":" + oamPort);

The following snippets in LoginActivity#getMobileSecurityService() and LoginApplication#getMobileSecurityService() create a OMMobileSecurityService object:

if (mss == null)

{

try
{

mss = ((LoginApplication) getApplication())

  .getMobileSecurityService(getApplicationContext(),

new OMMobileServiceCallbackImpl());

  }  ...

}

public OMMobileSecurityService getMobileSecurityService(Context c,

OMMobileServiceCallback callback) throws OMMobileSecurityException {

if (!isMssInitialized) {

if (mOAMConfigMap != null) {

mss = new OMMobileSecurityService(c, mOAMConfigMap, callback);

isMssInitialized = true;

}

}

return mss;

}

The context argument is the context of the Application object. Pass the context that is returned by Context#getApplicationContext(). The callback argument specifies an instance of a class that has implemented the interface OMMobileServiceCallback. The SDK uses this to return control to the application after calling OMMobileSecurityService#setup() and OMMobileSecurityService#authenticate().

 Register

You need to register the current activity with the SDK before invoking certain methods in the OMMobileSecurityService, such as setup(), authenticate(), processSSORequest(), and processHttpRequest() and deregister the activity when it is not in the foreground. This is done to ensure that there are no memory leaks. To give the reference to the current activity, register the current activity in onResume() and deregister the activity in onPause() for activities that call the methods mentioned previously. If you call any of these methods in onCreate() of the activity, register the activity before calling these methods. To deregister the activity, when the activity moves to the background, use the OMMobileSecurityService#deregisterActivity() method.

LoginActivity#getMobileSecurityService() and LoginActivity#OnResume() registers the current activity in our sample application:

private OMMobileSecurityService getMobileSecurityService()

{

if (mss == null)

{

try

...

{

if (mss != null)

{

mss.registerActivity(this);

  }

protected void onResume()

{

super.onResume();

if (mss != null)

{

mss.registerActivity(this);

}

  …

}

Setup

The setup method gets the configured security policies and the application profile from the Mobile and Social server. This method also gets a list of the service endpoints (the URLs) that are required for connecting to the authentication, authorization, and user profile services on the Mobile and Social server. This is an asynchronous call. When the application profile download completes, or if a problem like network unavailability is encountered, the SDK returns control to the calling activity by calling callback.processSetupResponse(OMApplicationProfile profile, OMMobileSecurityException mse). If the application profile could not be downloaded, the exception details can be found in OMMobileSecurityException mse. The SDK downloads and stores the application profile. The SDK will not download the application profile on subsequent calls to OMMobileSecurityService#setup() until the ProfileCacheDuration setting has expired. The ProfileCacheDuration setting is defined in the application profile.

The following snippets in LoginActivity#OnClickView() and LoginActivity#initSetUp() invoke setup() on the OMMobileSecurityService object:

public void onClick(View v)

{

switch (v.getId())

{

try

{

if (!((LoginApplication) getApplication())

.isSetupCompleted())

{

initSetUP();

}


}

private void initSetUP()

{

mss = null;

if (getMobileSecurityService() != null)

getMobileSecurityService().setup();

}

}

The following snippet in LoginActivity#OMMobileServiceCallbackImpl#processSetupResponse() implements the logic when the SDK returns control back to the application after performing setup:

public void processSetupResponse(OMApplicationProfile profile, OMMobileSecurityException mse)

{

if (profile != null)

{

((LoginApplication) getApplication()).setSetupCompleted(true);

Toast.makeText(LoginActivity.this, "Setup Done",

Toast.LENGTH_SHORT).show();

login.setTextColor(Color.WHITE);

}

else

{

Toast.makeText(LoginActivity.this, "Setup failed",

Toast.LENGTH_SHORT).show();

((LoginApplication) getApplication()).setSettingsFailedOAM();

displayConfigureSettings();

mss = null;

}

}

Authenticate

Once the setup successfully completes, the business application can perform authentication by either calling OMMobileSecurityService#authenticate() or OMMobileSecurityService#processSSORequest(). Use the processSSORequest()instead of authenticate() if your app also needs to act as an SSO agent—the OMMobileSecurityService#processSSORequest() supports both self authentication as well as the ability to allow the app to act as an SSO agent.

Both these calls are asynchronous calls and the SDK will return control to the application once authentication is completed or if authentication has failed for some reason. The control will be returned to the application through OMMobileServiceCallback#processAuthenticationResponse(OMAuthenticationContext context, OMMobileSecurityException mse). All the details with respect to the authenticated session are available in the OMAuthenticationContext context. If authentication fails for some reason, the details are available in OMMobileSecurityException mse. If an application (SSO client) needs to authenticate using the SSO Agent App, the main activity has to call OMMobileSecurityService#processSSORequest(intent)

The authenticate() and the processSSORequest() methods return a ViewFlipper object that holds the processing view. When the view is focused it will trigger the actual authentication flow. If a valid authentication context is already available in the cache for the above request, then it will return control back to the calling business application without performing any request to the server.

The following snippet in LoginActivity#OnClickView() demonstrates authentication:

authView= getMobileSecurityService().authenticate();

LinearLayout.LayoutParams params = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.MATCH_PARENT, LinearLayout.LayoutParams.MATCH_PARENT); relLayout.addView(authView, 1, params);

The following snippet in LoginActivity#OMMobileServiceCallbackImpl#processAuthenticationResponse implements the logic when the SDK returns control back to the application after performing authentication:

public void processAuthenticationResponse(OMAuthenticationContext context, OMMobileSecurityException mse)

{

Log.d(TAG, "Process authentication response() context = " + context);

String msg;

if (context == null)

{

isAuthenticated = false;

}

else

{

isAuthenticated = true;

}

relLayout.removeView(authView);

if (authView != null)

authView.invalidate();

if (isAuthenticated)

{

Intent i = new Intent();

i.setAction(LoginConstants.ACTION_LOGIN_SUCCESS);

i.putExtra(LoginConstants.USER_AUTHENTICATED, true);

startActivityForResult(i, LoginConstants.AUTH_SUCCESS);

}

..

}

Offline Authentication

Mobile and Social from R2PS1 onwards supports offline authentication. This feature requires that first the “Offline Authentication” setting is enabled in the Application Profile in the OAM Admin Console. Next, while initializing the SDK to create the OMMobileSecurityService object, add the OM_PROP_CONNECTIVITY_MODE key as a parameter to the Map<String,Object> as shown earlier in the Initialize section . You can specify the way that offline authentication should happen by providing one of the following values to this key:

OMConnectivityMode.ONLINE - Always authenticate with the server. Fails if device cannot reach the Internet.

OMConnectivityMode.OFFLINE - Authenticates locally with cached credentials. Offline authentication happens even if the device is online and can reach the server.

OMConnectivityMode.AUTO - Authentication happens with the server if the server is reachable and happens offline if the device is not connected to the Internet.

Invoking Relying Party Authentication

From an SDK perspective, Relying Party Authentication is identical to invoking Authentication Services as outlined above. Additionally, there are two areas to be considered:

1. To authenticate using a Relying Party, the data scheme in the main activity of the application should match the URL scheme configured in the Application profile. The main activity is the activity that has the <data android:scheme="xyz" /> in its <intent-filter> in the Android Manifest and xyz should be the same as the URL scheme configured in the Application profile. Finally, the main activity name is the name that should be used as the Android Package name in the Application Profile configuration.

2. If your apps will authenticate against different OAM servers, or with the same OAM server but different authentication schemes, then one OMMobileSecurityService instance should be created for every server or authentication scheme. So, for example, in this case since the same Login app authenticates against OAM server and against Facebook for different use cases, we need to create separate instances of OMMobileSecurityService to handle each use case.

Invoking REST Services

The Mobile SDK makes it easy to securely access REST services that are protected by OAM. The Android Client SDK automatically injects an access token when invoking an OAM R2 Webgate protected REST resource. It maintains a cache of access tokens that it has obtained during the mobile application's lifetime. It then either fetches an access token for the webgate from its cache or if an access token for the Webgate is not available in the Mobile and Social SDK cache, it sends a REST request to the Mobile and Social server to obtain the Access Token for the Webgate--provided the resource is protected by an Access Management 11g R2 Webgate. If a valid user token is not found for the current application (for example, if the user is not authenticated), the SDK throws an exception.

The following snippet in AccountStatement#RetrieveSummary demonstrates invoking a REST service:

class RetriveSummary extends AsyncTask<String, Integer, ArrayList<String>>

{

@Override

protected ArrayList<String> doInBackground(String... params)

{

// super.

ArrayList<String> resultList = new ArrayList<String>();

if (mss != null)

{

Log.d("AccountStatement", "rest service = " + restService);

// create a Http Request with the webservice

HttpRequest httpreq = new HttpGet(restService);

// in order to access the protected web service add the user-agent which is configured in the webgate settings.

httpreq.setHeader("User-Agent", "OIC-Agent");

try

{

// invoke sdk processHttpRequest() on the mss instance.

HttpResponse response = mss.processHttpRequest(httpreq);

final JSONArray array;

try

{

array = new JSONArray(parseHttpResponse(response));

for (int i = 0; i < array.length(); i++)

{

resultList.add(array.getString(i));

}

}

catch (IOException e)

{

e.printStackTrace();

}

}

catch (OMMobileSecurityException e)

{

e.printStackTrace();

}

catch (JSONException e)

{

e.printStackTrace();

}

return resultList;

}

return resultList;

}

As can be seen above, the Mobile and Social Android Client SDK provides a simple OMMobileSecurityService#processHttpRequest(HttpRequest httpRequest) method to access REST Web services or any Web resource protected by Access Manager. However, the "user-agent" http header value must be set to the OAMAuthUserAgentPrefix value that is defined in the webgate configuration to activate non browser client functionality.

About

Kanishk Mahajan is a Principal Product Manager in Oracle Identity Management with product responsibility within the Oracle Access Management suite

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today