The December 2013 release of IBM Security Access Manager (ISAM) for Mobile v188.8.131.52 delivered a set of OAuth 2.0 standard compliant capabilities, and some additional capabilities which enhance and support common mobile access uses cases. The v184.108.40.206 release extends the context based access features of RBA and OTP which were delivered in ISAM for Mobile V220.127.116.11. The v8.0.01 release is available as an appliance firmware upgrade and can be deployed as a hardware or virtual appliance.
The OAuth 2.0 features supported by the appliance are manageable via a browser based web UI. The UI simplifies deployment of OAuth protection for access to web based API and application resources. The OAuth protection features have been targeted for consumption by hybrid and native mobile apps, but are also consumable by other client types as described by the OAuth 2.0 specification.
Key features delivered with ISAM for Mobile v18.104.22.168 release include:
Standard OAuth 2.0 grants and OAuth client types – Public and confidential client types are supported. Supported grants include authorization code, resource owner password credentials, implicit grant, and client credentials grant.
PIN code protection – Enabled via configuration, a deployer can make PIN validation a mandatory requirement. This feature helps to achieve the common mobile experience of supplying and validating an end user PIN when using a mobile application.
Session endpoint – Allows an OAuth access token to be exchanged for an authenticated WebSEAL session cookie based on the resource owners identity.
Management of trusted client – End users can review and manage their authorized clients.
Management of access grants – End users can review and manage specific access token grants. An access token may be enabled, disabled or revoked.
Associate additional custom attributes with a grant – Additional attributes may be persistently stored with a grant.
Configuration of OAuth protection is in two parts.
OAuth API Protection Definition – This entity is a template for configuration of general OAuth protection parameters. When OAuth clients are registered, they must be associated with one OAuth API definition. An OAuth API definition can be associated with many OAuth clients.
OAuth client registration – Register public or confidential client types. The client identifier is automatically generated. A client secret is also automatically generated for confidential clients, however this may be overridden by the administrator.
The figure below is a screen shot of the OAuth API Protection Definition configuration screen.
Noteworthy options include:
PIN – Enabled or disabled using the checkbox. If enabled, the administrator can define how long a PIN value must be.
Single use grant – If enabled, a maximum of one access token will be successfully validated. The grant becomes invalid after the first successful use of an access token.
Trusted clients and consent – These options define how the authorization endpoint will behave an prompt with respect to authorization grants.
Information regarding the options shown above is available online at: http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.ammob.doc_22.214.171.124/concept/OAuthConfiguring.html?path=3_3_9_5#oauthconfiguring
An administrator can register OAuth clients. The figure below is a screen shot of the OAuth client registration panel.
The client identifier is generated during a new registration. The client name is simply a friendly name to assist administrators to identify clients in the GUI. The client secret can be automatically generated or user defined.
Support for user supplied PIN has been included with the ISAM for Mobile OAuth features. It provides an out of the box method to allow a PIN to be supplied and set when the initial access token is issued for a given authorization grant, and validated when an access token is refreshed. When PIN has been enabled, a refresh token grant will only be successful if a valid PIN is included as an additional attribute with the refresh grant request.
PIN protection is supported for authorization code and resource owner credential flows only.
Strictly speaking, OAuth is an authorization standard. However, in many cases OAuth has been or is being applied for authentication scenarios. One of OAuth's main attractions is the ability to obviate the traditional role and use of a password for authentication and access to protected resources. Another driver is the desire to apply OAuth protection to traditional web applications which rely on authenticated web sessions for security. In support of this goal, ISAM for Mobile supports a URL endpoint which can be used to exchange a valid OAuth access token for an authenticated WebSEAL session cookie. The resulting session is associated with the identity of the resource owner who delegated authorization for the access token.
More information regarding ISAM for Mobile is available at the IBM Infocenter:
and this excellent article published by my colleagues: