Of the many articles I read today, which one piqued my interest the most? “Google Launches Mobile Backend Starter, A One-Click Deployable Cloud Backend For Android Apps.”

Mobile Backend Starter provides developers with a one-click deployable mobile backend and a client-side framework for Android that provides them with storage services, access to Google Cloud Messaging, continuous queries and Google’s authentication and authorization features. (emphasis mine)

 

Why is this important?  I can think of at least 4 reasons:

1. If this is the easiest way for developers to embed authentication and authorization functionality into their apps, guess which method they will choose?
2. If it is easy to exploit back end services from mobile apps, emerging apps will ail be richer in functionality and content, because app developers will focus on real application innovation, rather than re-inventing the AuthN/AuthZ wheel.
3. Google’s quest to become Identity Provider for the world just took a big step forward.  If app developers can easily rely on Google AuthN/AuthZ, other companies that aspire to be IDPs will be playing catch up.
4. This pattern of easy-to-use backend infrastructure available to developers could revolutionize application development as we know it – not just mobile apps.

The obvious question is “where are you, Apple?”  But a bigger question is for all of us engaged in enterprise IAM, “how will we quickly adapt to this model?”

Oracle recently released a white paper entitled, “Oracle Access Manager Mobile and Social, A Case Study – Piggy Bank.”  This white paper outlines the use of the Mobile and Social component of the Oracle Access Management platform.  Mobile and Social provides a simple means to integrate Mobile applications with the security capabilities provided by Oracle’s Identity and Access Management platform.

The white paper:

discusses the effort involved in executing a Proof of Concept with a major international bank. While the PoC exercise was real and the requirements described in this paper implemented, certain details have been changed to protect the identity of the bank and its security architecture and simplified for those new to OAM Mobile and Social.

The Proof of Concept detailed in this white paper involved three main tasks:

1. creating a simple electronic banking application
2. the REST/JSON services for the application
3. securing the application and services with the Oracle IAM technology stack.

The “Piggy Bank” represents the bank for which the Proof of Concept was completed.  The basic PoC architecture is shown below:

 

The white paper does a good job of outlining just what is necessary to configure the components in this architecture.

The white paper concludes:

While the PiggyBank application is quite simple, it illustrates the power and capabilities of the Oracle Identity and Access Management platform including Oracle Access Manager, Oracle Adaptive Access Manager and some of the Mobile and Social Services. By using the OAM Mobile and Social SDK a fully functional mobile e-Banking application was created and secured in a very short time, without the need to install and configure any additional software and without the need to write complex code to secure the mobile App and its communication to the services it uses. 

A customer with an existing security infrastructure based on Oracle Access Manager and Adaptive Access Manager can easily deploy Oracle Mobile and Social to extend the same security capabilities to mobile applications. By using the Mobile and Social SDK customers can seamlessly integrate security into their native Apps on popular mobile platforms including iOS and Android.

The need for secure mobile access is already huge and growing rapidly.   The Oracle Mobile and Social product goes a long way towards meeting that demand.

 

 

Last Week, on Thursday, March 7th, the second @OracleIDM Tweet Chat (AKA Tweet Jam) was held. It was great to participate with many others on this lively and informative chat. The Chat Archive for #MobileIDM has been posted here for review.

This week, Phil Hunt posted a good educational piece about tokens, entitled, “Standards Corner: Tokens. Can You Bear It?“.  He focuses on how tokens are used in message authentication and explains the differences between bearer tokens and proof tokens, including implications of each.  He describes how the IETF OAuth Working Group is now working on requirements for Holder-of-Key tokens (aka proof tokens) to address how web sites which accept tokens should consider risks of compromise.

Thanks, Phil, for a instructive post.

Ironically, a couple of weeks after the @OracleIDM #authchat Tweet Jam about trends in authentication was held, NIST released DRAFT Special Publication 800-63-2, Electronic Authentication Guideline, over 110 pages of scintillating reading on the subject:

This recommendation provides technical guidelines for Federal agencies implementing electronic authentication and is not intended to constrain the development or use of standards outside of this purpose. The recommendation covers remote authentication of users (such as employees, contractors, or private individuals) interacting with government IT systems over open networks. It defines technical requirements for each of four levels of assurance in the areas of identity proofing, registration, tokens, management processes, authentication protocols and related assertions. This publication will supersede NIST Special Publication 800-63-1.

No, I haven’t read the entire report, but I did skip forward to page 102 because the table of contents promised a discussion of “Password Entropy,” and I really like the word “entropy.”  But alas, the most profound thing I read was the obvious: “Empirical and anecdotal data suggest that many users choose very easily guessed passwords, where the system will allow them to do so.”

Enjoy!

Last week, I participated in the first IAM Tweet Jam led by Mike Neuenschwander on @OracleIDM to discuss Authentication trends and predictions for 2013.  I really enjoyed the interchange of ideas and insight about such a timely topic in Identity Management

Today, the highlights of the Tweet Jam were posted on Storify.  I was pleased to see that my concluding tweet was published:

I look forward to participation in further IAM Tweet Jams.

Thanks, Mike, for hosting this event.

My former Sun colleague Brad Wheat just alerted me about an interesting service from Acxiom, “Identity-X Authenticate”:

According to Acxiom’s brief product description:

Verification is the process of substantiating that someone is in fact who he says he is, and verifying the validity of the information he has provided as authentic or genuine. Often times this is the first step in a risk management strategy. The Acxiom Identify-X Authenticate process uses unique data generated questions to identify an individual and then verifies these individuals through our high quality database, offering greater security to the end user.

Acxiom’s identification platform utilizes demographic and geographic data in challenge questions with nearly 900 data elements for more than 300 million individuals. Identify-X Authenticate data comes from public, publicly available and non-public proprietary databases. Identify-X Authenticate data is current and regularly updated daily, weekly and monthly, depending upon the data source.

Reading further in the product fact sheet, I discovered:

Examples of some of the data generated questions that Acxiom uses include:

• Based on your driver’s license do you wear corrective lenses?
• What professional licenses do you hold?
• What subdivision do you currently reside in?
• What state does your relative Joe live in?
• How many fireplaces did you have in your last residence?

Acxiom claims to leads the industry with a collection of more than 115 unique authentication
questions.  I didn’t realize I knew that many answers myself!

When I visited the Acxiom corporate headquarters in Arkansas about a dozen years ago, they claimed to have data on 95% of the population of the United States.  I think the coverage has grown in both depth and breadth by now.

This approach to authentication both encourages and unnerves me.  On one hand, it appears to be an effective method to reduce fraudulent access to information and systems.  On the other hand, it is more than a bit scary to realize that all this information about individuals resides in a single private database.

I just wonder … do they know what injury nearly killed me when I was four years old?  Do you? Do you care?