Thursday, October 31, 2013

Landscapes in Mobile Application Security

There are different aspects in Cloud and Mobile application security - and in different angles you can look in to it.

Within the first decade of the 21st century – internet worldwide increased from 350 million to more than 2 billion and Mobile phone subscribers from 750 million to 5 billion - and today it hits 6 billion mark - where the world population is around 7 billion. Most of the mobile devices out there - even the cheapest ones could be used to access the internet.

Let me do a quick survey here. How many of you have, password protected your laptops? Answer is obvious - almost all. But do you know that only 30% of mobile users, password protect their mobile devices ? This leaves out 4.2 billion mobile devices - unprotected - out there. I am using multi-factor authentication to secure my corporate email account on Google Apps. I am using world’s deadliest - the most complex password ever to protect my corporate Salesforce account. Now what ? I leave my mobile phone unprotected. I am already logged in to Google Apps - I am already logged in to Salesforce. Now I leave all my confidential information accessible to anyone having access to my mobile device.

How about password reset? Google, Microsoft, Yahoo - and almost all cloud service providers use mobile phone based password resets. Having temporary access to your mobile device, someone can take your accounts for the life time.

Multi-factor authentication for mobile applications is also not well thought yet. That is mostly because with the false assumption - “My mobile is under my control always”. 113 cell phones are lost or stolen every minute in the U.S and $7 million worth of smartphones are lost daily. Both Google step-2 authentication and Facebook Code Generator always rely on a mobile phone for protecting web based access. But, none of their mobile applications are protected with multi-factor authentication. Phone based multi-factor authentication won’t work for mobile applications.

Why do we need to worry about all these at the corporate level? 62% of mobile workers currently use their personal smartphones for work.

These are well known facts or threats in the mobile world. Different vendors have their own solutions. Apple let you lock your device over the Internet or even wipe off  all it’s data. And again most of the mobile device management (MDM) solutions let you take control over your lost device. But, then again - how much time you leave for it to be on wrong hands will do enough damage. MDM solutions out there need to go beyond it’s simple definition to be an integral part of the corporate Identity Management system.

Over the last few years - almost - all the cloud service providers are becoming mobile friendly. All of them have provided RESTful JSON based APIs. Amazon AWS, Google Cloud Storage, Salesforce, Dropbox all of them have REST APIs . Except AWS - all the others are secured with OAuth 2.0. AWS uses its own authentication scheme.

OAuth 2.0 has ‘proven success’ in securing REST APIs. But for mobile applications OAuth 2.0 can be miserably misleading. It has four defined grant types. Authorization Code, Implicit, Resource Owner Password and Client Credentials.

Authorization code and the implicit are mostly being used for browser based applications. Its a mis-belief among application developers, that the Resource Owner and the Client Credentials grant types are for mobile applications. Those require you to provide your credentials to the application - directly. As a practice avoid it. If you develop a mobile application to access a secured cloud API using OAuth - use either the authorization code or the implicit grant type. There, your application needs to pop-up the native browser to redirect the user to the OAuth authorization server.

But - still that does not make you 100% not vulnerable to further attacks. Whenever there is a redirection through the browser - there is a possibility of a phishing attack. A rogue OAuth client application can have a “Login with Facebook” button - which will redirect you to a rogue OAuth authorization server - which looks like Facebook - where you will misinterpret it as Facebook and give away the credentials.

There are many countermeasures that can be taken against phishing. But, sadly - most of the OAuth authorization servers, including Facebook and Twitter do not follow any. Your Facebook or Twitter account credentials can be quite easily phished through your mobile phone - than from a laptop computer. It’s quite easier than you think.

If you have developed mobile applications with OAuth 2.0 - you might have encountered another limitation. You need to bake in - your client key and the client secret into the mobile application itself. This is required in the first phase of the OAuth flow - and it’s the identification of the client to the OAuth authorization server. What would happen if someone steals this from the device ?

Let’s have a look at an example. We have a mobile application which will access the Facebook friend list of an end user and stores that friend list in Google Cloud Storage using its REST API. Facebook friend list belongs to the end-user - but the Google Cloud Storage belongs to the mobile application. Mobile application has to register with Facebook as an OAuth client and gets a client key and a secret. Then using Authorization Code grant type - it can get an access token to - access the end-users friend list on-behalf of him. To store this in Google Cloud Storage, the application has to use client credentials grant type - where the authorization server is Google. To get this done - we need to bake-in the client key and the client secret into the application itself. Anyone getting access to these keys, will get access to the Google Cloud Storage too. This is an area still under research with no permanent solution yet. Solutions over there like - restrictions based on IP addresses, device Ids - will only make things bit harder - but, not fully impossible.

OAuth 2.0 has become the de facto standard for mobile application authentication. This, it self has given the applications a better failover capability in case of an attack. The recent attack against Buffer - a social media management service, which lets users cross-post in to social networking sites like Facebook and Twitter - is a very good example. Twitter, Facebook got flooded with posts from Buffer. But revoking the client key of Buffer sorted out the issue. And also attack on Buffer did not give the full control of users’ Facebook and Twitter accounts to attackers - as it was not storing passwords.

It takes an average of 20 seconds for a user to log into a resource. Not having to enter a password each time a user needs to access a resource saves time and makes users more productive and also reduces the frustration of multiple log-on events and forgotten passwords. Users only have one password to remember and update, and only one set of password rules to remember. Their initial login provides them with access to all resources, typically for the entire day or the week.

What are the challenges in building a single sign-on solution for mobile applications ?

If you provide multiple mobile applications for your corporate employees, to be installed in their mobile devices - its a pain to ask them to relogin to each application separately. Possibly all of them may be sharing the same user store. This is analogous to a case where Facebook users login into multiple third party mobile applications with their Facebook credentials.

In mobile world - this can be done in two ways.

First, each native mobile application - when it is needed to authenticate a user  - should popup the native browser - and start the OAuth flow. Your company should have a centralized OAuth authorization server, running on top of the corporate user store. All your mobile applications will redirect the user to the same Authorization Server - creating a single login session under the domain of the centralized authorization server - which indirectly facilitates single-sign on.






The other approach is known as “Native SSO”. The user experience in Native SSO is very much better
than the browser based SSO. Here you need to have a native mobile application developed for the corporate identity provider (IdP) - or the authorization server - which will be invoked by the other applications to initiate the OAuth flow - instead of popping up the browser. Although Native SSO provides better - improved user experience - it also makes phishing attacks much easier.





The other drawback in Native SSO is - it has a phase - which is not standard based. Your application should know beforehand who your Identity Provider is - and should program according to it’s interface to initiate Native SSO. Currently there is an attempt by OpenID Foundation to  build a standard Single Sign On (SSO) model for native applications installed on mobile devices. This introduces an OpenID Connect Client called an Authorization Agent - which  can obtain tokens on behalf of other installed native applications - thereby provisioning tokens to those applications and so enabling a Single Sign On experience for end users. The spec is at its very initial stage - and would require many more iterations before becoming a standard.

Lets take another example. Previous case we had an assumption that we only have a single user store - which is behind the centralized authorization server. Let’s take that assumption out. We need users outside our domain - say, from federated partners - to access our mobile applications and consume services. There needs to be a bootstrap process to establish trust between those federated partners and our authorization server. Doing this in a standard manner - the partners would require to support one of the federation standards out there. The best would be the SAML. So - we need to add partner SAML IdPs as trusted IdPs to our authorization server. And also we can define an authorization policy against each IdP - so that we know which rights they would have in our authorization server. When user being redirected to the authorization server - either through browser based or native SSO - he can pick against which IdP he wants authenticate. Based on the choice the user will be redirected to his home SAML IdP - and once authenticated - authorization server will resume the OAuth flow. This is a one time thing - and for other subsequent requests from other mobile applications - flow will be seamless to the user and would not required to being redirected to his home SAML IdP.

With all the Single Sign On use cases we discussed above - we still left with one more assumption - all the mobile applications will have a centralized authorization server. Let’s get rid of  that too.

One key requirement for any single sign on scenario is - we should be able to establish direct trust or brokered trust between applications and their users. In most of the cases this is established through IdPs. The first example we took was based on direct trust - while the second is on brokered trust. To accomplish this use case we need to build a trust relationship between all the authorization servers - taking part in - and also a middle man to mediate SSO. This use case is also highlighted in the Native SSO draft specification by OpenID Foundation - but no much details as of now.

Data in transit is another security concern. Forget about NSA and Angela Merkel. NSA has more than 5000 highly capable computer scientists - and they have control over security algorithm designs. So, lets take NSA out of the picture. In most of the scenarios mobile applications depend on TLS for data confidentiality, in transit. TLS has it’s own limitations as its based on transport and the confidentiality of the data terminates as it leaves the transport. Most of the data transport channels used within mobile applications use REST and JSON. We have JOSE working group under IETF,  working currently to produce a standard for doing message level encryption and signing for JSON payloads.

Let me take this discussion to another direction. Managed Cloud APIs. Amazon AWS, Google Cloud, Dropbox, Salesforce all expose APIs over REST and JSON. Even in this case, Twitter and Facebook. We develop mobile applications on top of these cloud APIs - to be used by our corporate employees. For the simplicity of explaining - I’ll take Twitter as the example. We have a corporate account with Twitter - which is used to tweet events related to the company - and mostly used by the marketing team. To tweet through the corporate account we need to share the official twitter password with them. Which is not ideal. Can’t we let them tweet through the same corporate account - but still authenticate with their corporate LDAP credentials ? And also - we need to enforce certain rules and policies. Any tweet mentioning client names should be blocked immediately. Also we need to collect statistics and do access controlling. In other words - to cater for all these requirements we need to turn the simple Twitter API - in to a managed API. Here we introduce an API Gateway - in between your mobile application and the Twitter API. Through API gateway we expose - our own API - which wraps the Twitter API. Now - the marketing team can authenticate to the Twitter Wrapper API using their corporate credentials and Tweet using the corporate Twitter account. The official Twitter credentials are never exposed - and kept just within the API Gateway. Twitter is a simple example - but the same applies to any cloud API - which you want to turn into a Managed Cloud API - to be consumed by your mobile applications.

Monday, October 21, 2013

Brief history of Identity Provisioning

I'll be doing a talk at the Open Source Developer Conference (OSDC) - Auckland - tomorrow and thought of putting few notes here related to my talk.

Lets explore the history of Identity Provisioning.





















OASIS Technical Committee for Service Provisioning was formed in 2001 to define an XML-based framework for exchanging user, resource, and service provisioning information. As a result, the SPML (Service Provisioning Mark Language) came up in 2003 - which was based on three proprietary provisioning standards by that time. IBM and Microsoft played a major role in building the SPML 1.0.

1. Information Technology Markup Language (ITML)

SPML 1.0 defined a Request/Response protocol as well as couple of bindings. Requests/Responses - all based on XML. Each operation has it own schema.

One of the bindings defined in SPML 1.0 is the SOAP binding. It says how to transfer SPML requests and responses wrapped in a SOAP message. All the SPML operations supported by the provisioning entity should be declared in the WSDL it self.

The other one is file binding. This binding refers to using SPML elements in a file, typically for the purposes of bulk processing provisioning data and provisioning schema documentation.

In the closing stages of SPML 1.0, IBM and MSFT felt strongly that support for complex XML objects needed to be done differently. The OASIS TC voted to postpone this effort until 2.0. As a result, IBM unofficially stated that they wouldn't be implementing 1.0 and would wait on the conclusion of the 2.0 process.

IBM and Microsoft who were part of the initial SPML specification went ahead and started building their own standard for provisioning via SOAP based services - which is WS-Provisioning. WS-Provisioning describes the APIs and Schemas necessary to facilitate interoperability between provisioning systems in a consistent manner using Web services. It includes operations for adding, modifying, deleting, and querying provisioning data. It also specifies a notification interface for subscribing to provisioning events. Provisioning data is described using XML and other types of schema. This facilitates the translation of data between different provisioning systems.

WS-Provisioning is part of the Service Oriented Architecture and has been submitted to the Organization for the Advancement of Structured Information Standards (OASIS) Provisioning Service Technical Committee.

OASIS PSTC took both SMPL 1.0 and WS-Provisioning specification as inputs and developed SPML 2.0 in 2006.

SPML 1.0 has been called a slightly improved Directory Services Markup Language (DSML). SPML 2.0 defines an extensible protocol (through Capabilities) with support for a DSML profile (SPMLv2 DSMLv2), as well as XML Schema profiles. SPML 2.0 differentiates between the protocol and the data it carries.

SPML 1.0 defined file bindings and SOAP bindings that assumed the SPML1.0 Schema for DSML. The SPMLv2 DSMLv2 Profile provides a degree of backward compatibility with SPML 1.0. The DSMLv2 profile supports a schema model similar to that of SPML 1.0. The DSMLv2 Profile may be more convenient for applications that access mainly targets that are LDAP or X500 directory services. The XSD Profile may be more convenient for applications that access mainly targets that are web services.

The SPML 2.0 protocol enables better interoperability between vendors, especially for the Core capabilities (those found in 1.0). You can “extend” SPML 1.0 using ExtendedRequest, but there is no guidance about what those requests can be. SPML 2.0 defines a set of “standard capabilities” that allow you to add support in well-defined ways.

SPML definitely addressed the key objective of forming the OASIS PSTC in 2001. It solved the interoperability issues. But - it was too complex to implement. It was SOAP biased and was addressing too much of concerns in provisioning than what actually was needed.

It was around 2009 - 2010 people started to talk about the death of SPML.

In parallel to the criticisms against SPML - another standard known as SCIM (Simple Could Identity Management) started to emerge. This was around mid 2010 - and initiated by Salesforce, Ping Identity, Google and others. WSO2 joined the effort sometime in early 2011 - and took part in all the interop events happened so far.

SCIM is purely RESTful. The initial version supported both JSON and XML. SCIM introduced a REST API for provisioning and also a core schema (which also can be extended) for provisioning objects. SCIM 1.1 was finalized in 2012 - and then it was donated to the IETF. Once in IETF, it has to change the definition of SCIM to System for Cross-domain Identity Management and it's no more supporting XML - only JSON.

As a result of the increasing pressure on OASIS PSTC - they started working on a REST binding for SPML - which is known as RESTPML around 2011. This is still based on XML and not yet active so far.

Friday, October 18, 2013

Enterprise Integration with WSO2 ESB






















Enterprise Integration with WSO2 ESB is my first book.

WSO2 ESB is one of the leading ESBs out there in terms of features, scalability, and performance. It's being battle-tested at eBay and many other Fortune 100 companies. At the time of this writing, eBay is handling more than 4 billion transactions per day through the WSO2 ESB. In this book, I will cover some of the key features of WSO2 ESB mostly used in enterprise integration. Each feature is covered at the introductory level, to help anyone who is not that familiar with the WSO2 ESB, to catch up and proceed.

I would first like to thank, Vinay Argekar, an Acquisition Editor at Packt Publishing who came up with the idea of writing a book on the most popular WSO2 product—undoubtedly the ESB. Then, I would like to thank Sneha Modi, Priyanka Shah, Subho Gupta, Romal Karani, Tanvi Bhatt, and all the others from Packt Publishing who helped me throughout to make this book a reality from the initial idea. Thank you very much for all your continuous support.

If not for Dr. Sanjiva Weerawarana and Paul Fremantle we wouldn't have had a WSO2 ESB today to talk about. They founded WSO2 in 2005 with a mission to build a new era for SOA, and WSO2 ESB is a key ingredient. Today WSO2 provides a fully open source platform with more than 16 products. I am truly grateful to both Dr. Sanjiva and Paul for everything they have done for this field and for the community. And also, for mentoring and moulding me with care and patience.

Also, I would like to thank Samisa Abeysinghe, who is our VP, Training at WSO2 for being a great mentor to me throughout all these years.

My beloved wife, Pavithra. She wanted me to write this book even more than I wanted to. If I say she is the driving force behind this book, I am not exaggerating. She simply went beyond just feeding me with all the encouragement, but also helped immensely in reviewing the book and developing samples. She was the first reader, as always. Thank you very much Pavithra.

Kasun Indrasiri, who is the Product Manager and the Architect of WSO2 ESB, added so much value to the book with his technical expertise by reviewing the book. Thank you very much Kasun. I would also like to thank Rajika, Kishanthan and Charitha for reviewing the book for technical accuracy. Your inputs are highly appreciated.

Miyuru Daminda, Dushan Abeyruwan, Isuru Udana, and all the members of the WSO2 ESB team helped me a lot, clarifying all my doubts related to the product internals. Thank you very much, I appreciate your help a lot.

Last, but not least, my parents and my sister are the driving force behind me all the time since my birth. If not for them I wouldn't be who I am today. I am so very grateful to them for leading my way to write my first book.

Although this sounds like a one-man effort—it's a team. I would like to thank everyone who supported me in different ways.

The books is now available to purchase at http://www.packtpub.com/enterprise-integration-with-wso2-esb/book