RSA Conference 2014 Singapore : Identity and Access Management

I got an opportunity to attend the RSA Conference 2014 Asia Pacific at Singapore. As a part of the IBM Security team I exhibited some of our products. The exhibition hall was filled with business partners, competitors, industry experts and large enterprise customers. There were themes like Security Intelligence, BYOD, intrusion prevention, etc. I was curious about access management and spent time discussing and understanding products from other exhibitors while sipping beer and eating delicious snacks. Market researches have been bullish on the Identity and Access Management market over the last few years. After the conference I got the feeling that the market researchers seemed to have got it right. Two areas that excited me were IDaaS and Strong Authentication.

There were various IDaaS ( Identity as a Service ) offerings. Despite the IDaaS market being nascent and profits in this space being low it seemed to be an area where everyone is investing. Large players who traditionally built enterprise software were busy showcasing their IDaaS solutions. It was a bit confusing as some vendors differentiated between IDaaS and SaaS. At a high level, IDaaS has two pieces :

• Identity Management. Identity Management includes integrating with on premise enterprise registries, importing the registries to IDaaS, integrating through adapters that synchronize the data between different registries, etc.

• Integration with SaaS (Software as a Service ) vendors like Google, Workday, Salesforce, Office365, etc. SaaS includes Single Sign On (SSO) and federation of accounts. 

Most vendors offered integration and extension capabilities through SDKs, REST APIs, etc. Application management, Device registration and Device management at a centralized portal with IDaaS integration was offered by some vendors. The pricing models ranged from cost per user per month to complex customized prices.

Strong authentication was another area with numerous solutions. It seemed as though smaller vendors were investing more and building solutions which can be easily integrated. Some of the interesting vendors were Fujisoft, LiveEnsure, Microsec, StrongAuth. Fujisoft showcased a finger vein authentication mechanism. The solution requires an additional device that scans the user's finger vein. Although the additional device for authentication might seem like a burden, the accuracy of the system is worth the disadvantage. LiveEnsure had a strong authentication solution using QR codes without requiring any passwords. It seemed that their software collects usage patterns and can detect fraud if the second factor device, the phone in this case, is stolen and is being used by a malicious user. It can be easily deployed by just entering a snippet in a web page. Microsec's PassByMe was similar to Toopher authentication mechanism except that they use PKI instead of pass code phrase. StrongAuth had products in the Crypto space. They showcased a second factor authentication mechanisms based on FIDO alliance.


Only time will tell whether these business ideas will make money. But, for an enterprise customer it is good news. The costs are coming down, at least for IDaaS, and authentication getting stronger and easier. A combination of IDaaS and Strong Authentication is an area worth exploring for the enterprise customer.

IBM Security Access Manager For Mobile : Integrate your own authentication mechansim

Enterprises want to integrate custom authentication modules with their access management solutions.  These modules are generally used for second factor authentication. 
As a part of my work, I had co-authored an article that explains integrating second factor authentication system ( In this case Toopher ) with our product called IBM Security Access Manager.  I am also attaching a video that will give an idea about the functionality.

Note: This blog is a personal blog and IBM is not responsible for any material shown here.

Building trust in delegated authroization protocols

Some websites on the Internet allow access to services or data after the user authenticates using an account created at the website. Another way of authenticating at the website is by using a social account. This mechanism is generally implemented using delegated authorization protocols such as OAuth, Facebook Connect or OpenID. The user is redirected to the social network and then requested to authorize the website. During this authorization process, the website requests the user to share personal information. User is allowed access to the website's service or data after the personal information is shared. Pop up dialogs asking the user to share personal information is common. This is the beginning of mistrust.
The well advised user understands the implications of sharing personal information although sometimes the potential implications are exaggerated. The dilemma results in the user either denying the access to personal information or allowing access and worrying about the possible problems it may cause. Similarly, dummy accounts are created by users just to access the website. The website's data collection systems may capture user information that is of no business use.
In either case a participant ends up worrying or loosing. This environment of mistrust does not benefit anyone. A system were mutual trust is built over time is needed. The idea should be to build trust over time and exchange data once the trust levels are reached.
It could start with the user agreeing to share personal information under the trust that the website will not use it initially. Over time, The user might visit the website again. This would mean that the user is interested in the service provided by the website. At this point, one can conclude that the trust level from the user's point of view has increased and the website could start using some of the personal information that was shared initially by the user. If the user accesses the website repeatedly the user's trust level could be increased further thus allowing the website to access more personal information belonging to the user.
The website might use account reputation services to identify the legitimacy of the user. Bogus accounts created by machines or accounts that are created on the fly just to access the website need to be identified. The website can collect valid information if the bogus accounts are filtered. The trust level from the website's point of view will be increased based on the reputation of the user.
An integrated system where trust is built over time will benefit users and websites. Advertising to users can be improved over time, website can categorize data based on trust levels per user and the users need not worry about loss of personal information.
The system mentioned above can be implemented using existing solutions. Trust is not a one way street. All parties involved should do their bit to build trust.

Understanding Evolution of BYOD : Gartner presentation

After a busy few months, I finally get to write.
At IBM Interconnect 2013, we showcased our security products and solutions. The general interest ranged from Risk Based Access to Network Intrusion Prevention. But the hot topic was BYOD.
There were lots of questions and different views regarding BYOD. Every customer needed a solution but they were incapable of implementing it because their infrastructure was not mature enough to develop these solutions. So, the next question, how do they get to a stage where they can implement these solutions. I did not have any answers at that point in time as my exposure to BYOD is minimal. Last week, however, I stumbled upon a great presentation on this topic at the Gartner website. This presentation explains the evolution of BYOD from an organization's perspective. A quick summary would be as follows.
Organizations tend to avoid BYOD initially, then they accommodate it on a case by case basis starting from top level executives and then to employees, over time they adopt the right methodologies and finally assimilate or integrate all the solutions. This phase by phase adoption takes place in parallel with the BYOD elements and policies. The elements include data protection, cost control, IT support, etc. The BYOD elements force the organization to create new policies around supported platforms, standards, SLAs for devices owned by the organization, etc. The technology solutions range from providing BYOD solutions for browser based applications, mobile hypervisors to mobile device management. In the end the presentation touches a little bit on BYOPC which is a more advanced form of BYOD.
All in all, a lovely presentation and a must watch for people who want to understand BYOD.

Amazon's Login - How will it work ?

I heard about Amazon's announcement to enter the OAuth Login market. I am curious about Amazon's entry into this space. Despite it not being a social networking site they do give insights into the purchasing patterns of a user. The advantage they have is sticking to purchasing patterns instead of worrying about other interests of the user. The real adopters of Login with Amazon ( LwA ) will be businesses which sell goods and service on the internet.

Amazon could expose the user's purchase history, credit card information, gift card information, etc. In a purchase use case flow, A site that uses LwA could redirect the user to Amazon for payments. Building on top of this, the user could even allow the site to deduct certain amount from the Amazon gift card. A consent from the user might allow the site using LwA to auto deduct amounts from the gift card and / or charge the credit card during the user's next visit to their site. Additional constraints on the maximum amount that can be deducted or charged could make the experience better for the user.
From a business perspective, Amazon may charge a fee for every transaction made at a site which redirected the user to Amazon for authentication and authorization. It will help monetize user's personal data stored at Amazon. Unlike login with a social networking site,  LwA might help sites distinguish themselves. A site using LwA might indicate to a user that the service offered comes at a cost.

However, There are some concerns that need to be addressed.

• What kind of user data will be shared with other sites that use LwA ? 
• Will the user be willing to share data present in his/her Amazon account ? I wouldn't. 
• What happens if the bearer token that Amazon provides to the site using LwA is lost ? 
• Why would I ever use LwA as a user if I can use other social networking sites that do not expose any of my monetary details ? 
• Can I trust any OAuth client that uses LwA ?

The future of LwA will depend on the security and privacy policy it adheres to and the business model it surround it. But, if LwA is a success, then very soon Banks, Payment services such as PayPal, etc might enter as identity providers in the e-business space. Only time will tell what happens to Login with Amazon.

AZA - Worth the experiment

A lot of mobile applications (app) provide services that require the user to authenticate using their social networking identities and authorize the app to access their personal data. The result is that the user can consume the service while the app can access personal data belonging to the user. The problem is that the user needs to log in and authorize each app even if the social identity used by the user is the same across multiple apps. The Authorizing Agent (AZA) will solve the problem of repeated authorizations if the identity used by the user is the same for multiple apps. The initial ideas are well captured in the forum started by engineers from Ping and the draft spec. The suggestion is that an agent will reside on the mobile phone. The agent will take the responsibility of authorizing apps on the user's behalf thus reducing the burden on the user for repeated authorizations. This idea might trigger some good initiatives across the mobile app development apart from Single Sign On which is obvious.

Consolidation of Enterprise Mobile Apps
For years enterprises have been building mobile apps with custom authentication and authorization mechanisms. AZA can be deployed as a service that is reusable on the mobile platform. App developers can build the features of the app and leverage this service for authentication and authorization. The service and app will be separate entities. App developers can concentrate on app development while the service is maintained by the security developers. Each team should make sure that respin of either entity, App or Service, will not break the overall integration.
This could help consolidation of apps in an enterprise and the same standards for mobile app development can be used across different teams.

User Managed Access (UMA) and Scope sharing
As disscussed earlier, users authorize apps to access their personal data. The app can access depending on the consent given by the user during app authorization. The user basically gives permission to access some of his/her personal data. UMA proposes that an external entity should host all the user's permissions and any app requesting user's personal data should interact with the host instead of the user.
AZA could act as the host and host the user consent or permissions. Currently, each app requests permissions to access user's personal data. Even though the identity used by the user may be the same for these apps, each app requires specific data. The problem of authorizing each app and maintaing permissions given to each app can be solved if AZA acts like UMA host and avoids user intervention. User intervention is needed only if the permission requested by the app is not hosted by AZA. Once the permission is authorized by the user, AZA could update a list that contains permission information for subsequent app requests.


If implemented, AZA might open an authentication and authorization services on the mobile phone. AZA services will run closer to the user and might allow the user to revoke permissions and authorization to certain clients. By peppering it with risk based authentication an intelligent system can be developed. I hope the specs and groups will discuss such details further.


Of course, all this comes at a risk. Control to the AZA, revoking permissions and authorizations when something goes wrong such as a lost device, leaked credentials need to be thought about. But, all in all I think it is a great experiment worth trying. My best wishes to Ping and Oracle who have ventured into this experiment.

Identity and Access Management - 2013

As we steam along in 2013 with more releases and more fixes it is time to slow down the frantic pace and figure out what is the future.

Three articles explain what might be in store in the near future. Each article is written and presented by an expert. The first one is a thought provoking article on the future of IAM. The next one is a well researched material. But I am looking forward to the presentation in the European Identity and Cloud Conference which according to me will combine the opinions presented in the other two articles.

In the first article, Ian Glazer talks about rethinking the way data is organized and hit the nail on the head by suggesting the IAM system should mirror the modern web. The idea is yet to be explored and adopted. The good part about the suggestion is that lot of rework might not be needed in order to achieve what he suggests. However, we need to see products that redesigns and redeploys identity data. This is a great opportunity for development organizations. I am yet to see any big players announcing a move in that direction. It will be something worth watching for in 2013.

The second article, a presentation by Earl Perkin talks about People Centric Security (PCS). The idea behind PCS is that the user is responsible for information security. The IAM principles will have to be explored and reassessed in a lot of ways if the idea of PCS has to materialize. This is an area that doesn't need a lot of standards. Innovative ideas combined with existing frameworks like second factor authentication, risk engines, etc can be used to adopt PCS. At the end of 2013 I hope to see some best practices and knowledge sharing by security experts with regards to PCS.

Finally, The step towards extending the existing framework is on its way as suggested by Martin Kuppinger. UMA and SCIM protocols are two such extensions. However, the adoption is still in its nascent stages and as I mentioned in the earlier post newer protocols may not inspire enterprises.
The extensions and proposals should be made to the existing frameworks and accepted by the protocol working committee. From an engineering perspective such changes are easier to implement, adopt and deploy. Agile principles should not be limited just to development but should be extended to protocol working committees so that they release extensions to existing protocols more often. This is one change I would like to see in the future. In 2013, I hope at least some of the protocols are ratified with concurrence from industry. It will help the product management teams to commit on features and release products based on standards.

I hope in 2013 we can see some new products in IAM that implement some of the ideas discussed by the experts. Otherwise, it will be another year where expert predictions result in nothing but good reading material.