Wednesday, August 13, 2014

[Book] Advanced API Security: Securing APIs with OAuth 2.0, OpenID Connect, JWS, and JWE

APIs are becoming increasingly popular for exposing business functionalities to the rest of the world. According to an infographic published by Layer 7, 86.5% of organizations will have an API program in place in the next fi ve years. Of those, 43.2% already have one. APIs are also the foundation of building communication channels in the Internet of Th ings (IoT). From motor vehicles to kitchen appliances, countless items are beginning to communicate with each other via APIs. Cisco estimates that as many as 50 billion devices could be connected to the Internet by 2020.

This book is about securing your most important APIs. As is the case with any software system design, people tend to ignore the security element during the API design phase. Only at deployment or at the time of integration do they start to address security. Security should never be an afterthought—it’s an integral part of any software system design, and it should be well thought out from the design’s inception. One objective of this book is to educate you about the need for security and the available options for securing an API. Th e book also guides you through the process and shares best practices for designing APIs for rock-solid security.

API security has evolved a lot in the last five years. The growth of standards has been exponential. OAuth 2.0 is the most widely adopted standard. But it’s more than just a standard—it’s a framework that lets people build standards on top of it. Th e book explains in depth how to secure APIs, from traditional HTTP Basic Authentication to OAuth 2.0 and the standards built around it, such as OpenID Connect, User Managed Access (UMA), and many more. JSON plays a major role in API communication. Most of the APIs developed today support only JSON, not XML. Th is book also focuses on JSON security. JSON Web Encryption (JWE) and JSON Web Signature (JWS) are two increasingly popular standards for securing JSON messages. The latter part of this book covers JWE and JWS in detail.


Another major objective of this book is to not just present concepts and theories, but also explain each of them with concrete examples. The book presents a comprehensive set of examples that work with APIs from Google, Twitter, Facebook, Yahoo!, Salesforce, Flickr, and GitHub. Th e evolution of API security is another topic covered in the book. It’s extremely useful to understand how security protocols were designed in the past and how the drawbacks discovered in them pushed us to where we are today. Th e book covers some older security protocols such as Flickr Authentication, Yahoo! BBAuth, Google AuthSub, Google ClientLogin, and ProtectServe in detail.

There are so many - who helped me writing the book. Among them, I would first like to thank Jonathan Hassel, senior editor at Apress, for evaluating and accepting my proposal for this book. Th en, of course, I must thank Rita Fernando, coordinating editor at Apress, who was extremely patient and tolerant of me throughout the publishing process. Thank you very much Rita for your excellent support—I really appreciate it. Also, Gary Schwartz and Tiff any Taylor did an amazing job reviewing the manuscript—many thanks, Gary and Tiff any! Michael Peacock served as technical reviewer—thanks, Michael, for your quality review comments, which were extremely useful. Thilina Buddhika from Colorado State University also helped in reviewing the first two chapters of the book—many thanks, again, Thilina!

Dr. Sanjiva Weerawarana, the CEO of WSO2, and Paul Fremantle, the CTO of WSO2, are two constant mentors for me. I am truly grateful to both Dr. Sanjiva and Paul for everything they have done for me. I also must express my gratitude to Asanka Abeysinghe, the Vice President of Solutions Architecture at WSO2 and a good friend of mine—we have done designs for many Fortune 500 companies together, and those were extremely useful in writing this book. Thanks, Asanka!

Of course, my beloved wife, Pavithra, and my little daughter, Dinadi, supported me throughout this process. Pavithra wanted me to write this book even more than I wanted to write it. If I say she is the driving force behind this book, it’s no exaggeration. She simply went beyond just feeding me with encouragement—she also helped immensely in reviewing the book and developing samples. She was always the first reader. Thank you very much, Pavithra.

My parents and my sister have been the driving force behind me since my birth. If not for them, I wouldn’t be who I am today. I am grateful to them for everything they have done for me. Last but not least, my wife’s parents—they were amazingly helpful in making sure that the only thing I had to do was to write this book, taking care of almost all the other things that I was supposed to do.

The point is that although writing a book may sound like a one-man effort, it’s the entire team behind it who makes it a reality. Thank you to everyone who supported me in many different ways.

I hope this book effectively covers this much-needed subject matter for API developers, and I hope you enjoy reading it.

Amazon : http://www.amazon.com/Advanced-API-Security-Securing-Connect/dp/1430268182

Monday, December 16, 2013

Bring Your Own IDentity (BYOID) vs Take Your Own IDentity (TYOID)

There are many places that talk about Bring Your Own IDentity (BYOID) - but quite rare they talk about Take Your Own IDentity (TYOID). What is the difference or both having the same meaning?

Both look almost the same. The difference lies on how you look at it.

BYOID is relying party centric - while TYOID is identity provider centric.

Let me explain this bit more.

If you have an Identity Management system that supports BYOID, that should be able to mediate different heterogeneous identity protocols and standards. To elaborate more on that, you should let people authenticate with their own Facebook credentials (OAuth 2.0), Twitter credentials (OAuth 1.0), Google / Yahoo credentials (OpenID), Salesforce credentials (SAML 2.0) and many more. The overall credential management and mapping cost is at the relying party end.

If you have an Identity Management system that supports TYOID - its identity provider centric - and you need not to rely on the capabilities of the relying party Identity Management system. Say, you got to talk to a partner system that only knows SAML based authentication. The partner service will trust your SAML IdP. When the users from your domain, want to authenticate - they will be redirected to your own IdP. Now, the users can login to the SAML IdP with their Kerberos credentials - and authenticate to the partner service via SAML.

Here, the partner service supported BYOID - by trusting the SAML2 IdP of an out side domain - and at the same time - the local Identity Management system of the out side domain supported TYOID by letting its users authenticate with their own Kerberos credentials. Similarly, it could also let users authenticate with any format of internal credentials or any social login.

Tuesday, December 3, 2013

BYOID with WSO2 Identity Server

Enterprises grow today with acquisitions, mergers and partnerships. Integration between systems that were never designed to work together is harder.

Recently we integrated WSO2 App Factory with Codenvy - so you can use Codenvy as the cloud IDE for the projects created and managed in WSO2 App Factory. The integration was quite easy - as both the sides supported OAuth. Codenvy could act as an OAuth client, while WSO2 App Factory, as the OAuth authorization server. With this, Codenvy let WSO2 App Factory users to use their own identities from WSO2 domain and log in.

Life is not easy as this always.

We have also met customers who had the requirements of integrating heterogenous identity management systems together. Once the company Foo created a partnership with the company Bar, the Bar users coming from its own user store should be able to access the applications hosted in company Foo. The challenge is, applications in company Foo, do not know how to talk to the user store in company Bar. Ideally we should let the users from company Bar to bring their own identities.

If we are to change either of the side - then, the cost is quite high. Enterprises today, are looking for solutions that could mediate heterogeneous identity protocols - that would permit 'Bring Your Own Identity (BYOID)'.

WSO2 Identity Server is capable of supporting BYOID with Chained Collaborative Federation (CCF) pattern.

Identity Server can mediate identities between OpenID, OAuth 1.0, OAuth 2.0, SAML 2.0 and OpenID Connect - and has an extensible architecture to extend to your custom needs.

Social login is also a key part in BYOID.

Most enterprises let customers and even the employees associate their social logins with the corporate credentials. In that way, they can bring the social identity, in to the enterprise.

WSO2 Identity Server, has the capability to support OpenID association with its released version (so you can integrate your Google account) and in the future releases we are planning to add seamless integration with Facebook, Twitter and LinkedIn accounts.

Fine-grained Access Control for APIs

OAuth is the de facto standard for API security and it's all about access delegation.

The resource owner delegates a limited set of access rights to a third party. In OAuth terminology, this is the “scope”. A given access token has a scope associated with it and it governs the access token’s capabilities.

XACML (eXtensible Access Control Markup Language) is the de facto standard for fine-grained access control. OAuth scope can be represented in XACML policies.

Say, for example a user delegates access to his Facebook profile to a third party, under the scope “user_activities”. This provides access to the user's list of activities as the activities connection. To achieve fine-grained access control, this can be represented in a XACML policy.
<Policy>
     <Target>
          <Anyof>
                <AllOf>
                     <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
                                user_activities
                         <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:scope:scope-id" category="urn:oasis:names:tc:xacml:3.0:attribute-category:scope" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false">
                      </Match>
                </AllOf>
         </AnyOf>
    </Target>
    <Rule Effect="Permit" RuleId="permit_rule">
    </Rule>
    <Rule Effect="Deny" RuleId="deny_rule">
    </Rule>
</Policy>
The above policy will be picked when the scope associated with the access token is equal to user_activities. Authorization Server first needs to find all the scopes associated with the given access token and build the XAML request accordingly. Authorization Server first gets the following introspection request.

token=gfgew789hkhjkew87
resource_id=GET https://graph.facebook.com/prabathsiriwardena/activities

Authorization Server now needs to find the scope and the client id associated with the given token and build the XACML request.
<Request>
      <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:oauth-client">
           <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:client:client-id">
               <AttributeValue 
                     DataType="http://www.w3.org/2001/XMLSchema#string">32324343434</AttributeValue>
          </Attribute>
     <Attributes>
    <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
         <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
             <AttributeValue
                     DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
        </Attribute>
    </Attributes>
    <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:scope">
       <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:scope:scope-id">
              <AttributeValue  
                      DataType="http://www.w3.org/2001/XMLSchema#string">user_activities</AttributeValue>
       </Attribute>
    </Attributes>
    <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
        <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
              <AttributeValue 
                      DataType="http://www.w3.org/2001/XMLSchema#string"> 
                                       https://graph.facebook.com/prabathsiriwardena/activities</AttributeValue>
        </Attribute>
    </Attributes>
</Request>
The above request will pick the policy we defined first and evaluate the rules. Each rule can define the criteria, whether to permit or deny.

  1. User / System accesses the API passing an access token.
  2. API Gateway intercepts the request - finds the access token and calls OAuth Authorization Server (Introspection endpoint) to validate it. 
  3. Authorization Server, finds the scopes and the client id associated with access token, builds a XACML request can call XACML PDP. 
  4. XACML PDP evaluates the XACML requests against its policy set and returns back a XACML response. 
  5.  OAuth Authorization Server sends back a Introspection Response which indicates the validity of the token. 
  6. API Gateway validates Introspection Response and then invokes the backend business API.