ISAM for Mobile: OAuth Authorization in Mapping Rules

If you’d like to do Authorization in a mapping rule for OAuth, there are a couple of options as to how you do this.

On the IBM Security Access Manager (ISAM) for Mobile appliance, API protection exposes two Mapping rules:

mappingrules

A) A Pre Token Generation mapping rule named: <API Definition Name>PreTokenGeneration.
This mapping rule fires before the tokens are validated on a runtime flow, or generated on an authentication flow. This is most useful for performing operations around authentication, for example in a resource owner password credential (ROPC) flow.

B) A Post Token Generation mapping rule named: <API Definition Name>PostTokenGeneration.
This mapping rule fires after the tokens are validated on a runtime flow, or generated on an authentication flow. This is where the bulk of the OAuth business logic is performed.

For authorization based on URLs being accessed, this is best performed in the Post Token Mapping rule. The default post token mapping rule shows an example where it determines the request type. A request type of ‘resource’ is the runtime authorization flow – for example when called by WebSEAL to validate an access token.

    //request type
    temp_attr = stsuu.getContextAttributes().getAttributeValuesByNameAndType
                    ("request_type", "urn:ibm:names:ITFIM:oauth:request");
    if (temp_attr != null && temp_attr.length > 0) {
        request_type = temp_attr[0];
    } else {
        request_type = "resource";
    }

So in our authorization code, we can do the following check:

if(request_type == "resource")
{

    //This is a runtime flow. 
    var accessURL = stsuu.getContextAttributes().getAttributeValueByNameAndType
                                 ("path", "urn:ibm:names:ITFIM:oauth:request");
    IDMappingExtUtils.traceString("############# URL accessed is: " + accessURL);
    //Perform authorization here
    if (accessURL.startsWith("/test/api/secure/") && SOME_OTHER_TEST)
    {
        stsuu.addContextAttribute(new Attribute
        ("authorized", "urn:ibm:names:ITFIM:oauth:response:decision", "FALSE"));
    }
}

In this example, we are looking at the URL to determine where they are accessing and potentially performing another check for example based on additional attributes stored with the tokens. If the rule is to block, add an attribute to the context attributes on the STSUU, with a response decision of “FALSE”.

WebSEAL will respond to this decision with a 401 Unauthorized, using the configured template page.

[root@api tmp]# curl -k -H "Authorization: Bearer <ACCESS TOKEN>"  
                   "https://<host>/test/api/secure/api.jsp"

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<!-- Copyright (C) 2012 Tivoli Systems, Inc. -->
<!-- All Rights Reserved. -->
<!--
     This is a template file for the OAuth component.  It is used
     by the OAuth component when a page needs to be returned to the
     client.  The response pages correspond to:
       401 - Unauthorized

-->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 
<!-- Enter Page Title -->
<title>ISAM OAuth Response</title>
</head>

<body>

<!-- Enter Message Header -->
<h1><font color="#FF0000">ISAM OAuth Response</font></h1>

<p><!-- Enter Message Details -->
401 Unauthorized
</p>
</body>

</html>

 

One thought on “ISAM for Mobile: OAuth Authorization in Mapping Rules

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

WordPress.com.

Up ↑

%d bloggers like this: