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.

Understanding the A B C of Identity and Access Management (IAM) product development

I have been working in the Identity and Access Management (IAM) area over the last few years. Working with the development team and by talking to customers and customer facing experts I have understood the journey of the code from a development environment to a powerful server. But the journey doesn't end there. The moment software gets deployed the product requirements change. The customers want tweaks to the product or want new features and suddenly we realize what we built needs to be rebuilt. Sometimes the customer doesn't want our advanced features. Some customers don't want anything new. Some customers want better support instead of new features. In this blog I have tried to capture some of my experiences and learning dealing with enterprise customer.

Adoption
Product adoption at the customer site is an important part of the product lifecycle. Enterprise customers buy a lot of products which are never deployed. There are many reasons why a product is not adopted. It is the development and product management mindset that are primarily responsible for this problem.

One major flaw is the wrong notion of supporting new features. In the IAM world it can be translated to supporting newer protocols. New IAM protocols are proposed almost every month. OAuth, OpenID, OpenID Connect, SCIM, JWT, SimpleAuth ,etc sprung up within the same period. Development teams spend months building these protocols only to realize that the customers have no plans to move to these new protocols and instead want to use the old mature protocols. Cost of re-deploying, the lack of trust in the new protocol and integration with other systems that do not adopt new protocols are some reasons behind the lack of adoption. The development organizations need to understand the use cases that will drive a need for newer protocols at the customer site with good migration and integration stories for the customer.

The other flaw is "Internet Trends". Just because the internet facing B2C firms use the protocols does not indicate a change in trend. B2C firms evolve themselves into using these protocols out of a business or technical need whereas enterprise customers are resistant to change. Strong statements and finger pointing by industry experts won't necessarily drive a change in the enterprise customer's psyche. If the enterprise customer is actively involved in the protocol standards groups or communities that drive these protocols then the chances of adoption are higher. The development teams need to work closely with the IAM architects in the customer site and understand the needs before starting work on these new protocols.

Customers in certain parts of the world are more willing to accept changes. Automobile firms such as Ford has an office in Silicon valley and is experimenting with APIs in the vehicle. 3rd party applications are being built to consume and produce data pertaining to a vehicle.Whereas there are customers in other parts of the world who still use legacy systems and do not plan to migrate to newer software stacks. The product management needs to understand the intricacies of geography location and work accordingly. Most of the time the product management sits in a mature and adoption friendly geography and dictates the terms. This net result is a skewed view of the world outside and thus poorer adoption.

With the expansion of cloud deployments almost every enterprise has been sold or in the process of being sold a cloud based solution. Apart from the usual problems of confusing license costs for cloud deployments even though the sellers may think otherwise, security concerns and ownership worries the biggest challenge is migration and integration. Most of the B2C cloud deployments involve smaller applications but a large enterprise has legacy applications that need custom integration. All this make the case for cloud solution weaker. However, according to my experience, newer deployments that do not integrate with legacy applications is a good starting point for cloud deployments and there are positive signs there.

Building the product
I come from a development background with passion for intricate details. My eclipse environment and Firefox browser are stuffed with developer tools. But, over time, I realized that the passion for building a product is a useful trait but even more important is to see where and how the product fits in the market. Again there are some problems running deep inside the development organizations.

"Standards" myth. Development builds products which might follow exact specifications of an IETF document. It is an overkill most of the times. Customers do not want the exact standards but want flexible architecture that allows them to plugin and play their code. In the IAM space a classic example is that of OAuth. The confusion should to be solved by providing customers a way to use what they need.

"Beta" feedback. Almost every customer who is involved in the beta actually doesn't use the product to its fullest. It is even more trickier in case of IAM products. They are generally large scale and to test and deploy it for a beta is time consuming and costly. Ideally, beta environments need to be hosted by development teams. They need to simulate customer environments and allow customers to use the environment. This happens rarely as the development team is running behind schedule most of the times.

"Agile". Most of the development teams have a "Fragile Agile" model. They just break the huge waterfall model into smaller chunks and call it Agile. Production code is released once every few sprints instead of every sprint. The development teams slip stories and the sprints more or less become a  formality. Test driven development is almost non existent and the hotchpotch way of building products the "Fragile" way ruins the quality. My blog on Agile failures (coming soon) will give a deeper explanation of the mess. In case of IAM products this spells doom. Invariably, the test team is behind schedule and is forced to finish their work quickly resulting in security vulnerabilities, performance problems and bugs. When these problems are exposed it shows the development team in bad light and affects the brand name. Development teams need to take a stance and figure out whether they really are Agile and does it even make sense to be Agile.

Competition
Nothing drives an organization more than the competition. It is both good and bad. But I feel there is a defensive technique used by the sales team that doesn't help the customer. We are told that no salesman gets into a feature war. Yet they put number of slides in the presentation that contradicts the previous statement. Feature wars exist and cannot be ignored. But, most of the times the features developed out of the fear of completion ends up being a bad copy of the original creators. If the market for that feature is already mature then the development teams just waste their time building it. In the IAM space it results in the development of features that may never be used. Such features help the sales team but not the customer. IAM products should have a niche and brand. The brand should be strong enough for a win. The product management needs to figure out if they want to be jack of all trades and master of none or jack of some trades and master of one.

Another classic selling strategy is the end to end selling. The presentation slides and technical demonstrations show all the happy paths of integrating the entire software stack. Almost every competitor boasts of the exact same end to end solutions. The product management needs to decide if it makes sense to integrate so many products just for the sake of competition. IAM products should have logical integrations that should not be driven out of competition but out of actual needs.

Price is another area driven by competition. Large enterprises fund development shops on an hourly basis. At the end of the year when development costs are compared with the sales revenue there is a gap. It is primarily because the products built were priced according to competition instead of its actual value. The sales team gives discount and thus put pressure on the development team to further reduce cost. The end result is less developers or substandard developers who can only take a product to its doom. IAM pricing is critical for the organization which sells the product as well as the customer who gets value from it and should not be driven by competition.


Summary
My views may sound idealistic but I can confidently say that in the IAM space there are players who have or are building a niche for themselves and building really fast. The key idea is to understand customers, know your development team well and not get too bogged down by competition. This will result in better and safer software.