CIS13: APIs, Identity, and Securing the Enterprise

Copyright ©2013 Ping Identity Corporation. All rights reserved. 1 Confidential

API Security

Bradford Stephens (Ping) & Tim Anglade (Apigee)


•  Intros •  The “Platform Imperative” •  What does Security Mean? •  Solutions •  Wrap-Up

Contents


•  Hi! •  Former CEO of VC-Backed database startup, Drawn to

Scale. Built a distributed SQL database, Spire, from scratch.

•  Does a lot of work in big data, distributed systems, and APIs.

•  Now running Developer Evangelism + Platforms @ Ping!

Bradford Intro


•  Hi as well! •  Built financial infrastructure at NASDAQ, an eCommerce

startup, Invited Expert work at W3C and now APIs & Mobile Apps

•  Spent a few years focusing heavily on distributed systems and NOSQL databases — nosqltapes.com and nosqlsummer.org

•  Now running Developer Programs @ Apigee!

Tim Intro


Business Software is Changing

CRM

Sales

Analytics

Sharepoint

Website

Transactions Marketing

Biz Apps



Biz Apps

Salesforce Box

AWS

Shopify

Omniture

Google Apps



Biz Apps

Salesforce Box

AWS

Shopify

Omniture

Google Apps

API

API

API

API

API

API

API


The Enterprise Must Open

Understanding the API Economy—the billionaire club



API Growth Rate •  Open APIs

–  We just hit the 7,000 API mark –  8,000 by year end –  16,000 by 2015

•  Dark APIs –  Dark APIs are 5x+/- Open API growth rate –  80,000 by 2015



•  Internal apps must be refactored •  Close collaboration with Partners •  Explosion of different channels and devices •  Everything is more social


What even is security?

What does security mean in this open-default world?


The never-ending battle

•  Security is a never-ending battle between collaboration and secrets … to get work done

•  Once we’ve chosen where we fall on the spectrum, how do you keep security around it?


Major Concepts

•  Identity •  Authentication •  Authorization •  Encryption •  Accounting


Identity

•  Answers “Who are you?” •  UserIDs, Digital Certificates, ATM Cards •  A public claim asserting yourself


Authentication

•  Answers “How can you prove who you are?” •  Responding to a challenge •  Private shared secrets, best if known only to user (Private

Key)


Authorization

•  Answers “What are you allowed to do?” •  Token/Ticket Mechanism •  Certain tokens are allowed certain abilities •  Enforcing the principle of least privilege


Encryption

•  Answers “How can we keep this secret?” •  Only authorized parties can understand data •  Non-symmetric algorithms ‘mask’ data – ‘impossible’ to

reverse engineer


Accounting

•  Answers “Who did what, when?” •  Typically use a logging mechanism (Splunk) •  “Closes the loop” between Authentication and

Authorization •  Essential in identifying gaps and postmortems


So what is API Security?

•  A Secure API only allows the right people the right amount of access to resources and data

•  Has to balance collaboration in an open-by-default world vs. keeping important secrets

•  Many, many ways to do this


Identity Authentication Authorization Channel Enc. Accounting Dedicated ATM X X 802.1X X X LDAP X ActiveDirectory X X (partial) Database Table X RADIUS/Diameter X X X VPN / IPSec X X X.509 X X SSL, TLS, DTS X Basic/Digest Auth, Login X X 2-factor X Master login X X API keys X X (partial) OAuth 1.0 OAuth 1.0a X (partial) OAuth 2.0 X (partial) OpenID X OpenID Connect X SAML X X (partial) Shiro or other framework X X Splunk or other logging X Roll your own

Recap


Topology

Database

App Layer

API

User A

App 1

User B

App 2

User C

App 3


•  Use-cases –  Internal APIs –  Partner APIs –  Public APIs (consumer, open, mobile etc.)

•  Tiers (legs)

–  Server-to-Server (internal, partner) usually 2-legged authentication

–  End-user (consumer, mobile, open) usually requires 3-legged authentication

API Types


Topology

Database

App Layer

API

User A

App 1

User B

App 2

User C

App 3


•  Malicious Apps •  Well-intentioned but vulnerable App •  Well-intentional App with Malicious Users

Common Security Concerns


Topology

Database

App Layer

API

User A

App 1

User B

App 2

User C

App 3


•  Two classes –  Human & Business –  Technologies

•  Secure APIs use both!

Remedies


1.  Registration Wall –  Knowing is half the battle! –  Identify problematic apps or users –  Isolate them from other traffic –  Provide means of communicating with

well-intentioned users

Human & Business Remedies


2.  Proof –  Enhance registration by requiring proof the

account was not automatically created (captcha) or has a legit email address (activation link)

–  Phone Activation –  Driver’s license, …



3.  Traffic Shaping –  Quotas –  Throttling –  Tiered Traffic –  Dynamic IP Filters –  Dynamic ISP Filters –  Up to & including blocking –  Processes not technologies!



4.  Audits & Certifications –  More useful than you think –  Checks for dark corners in your organization –  PCI-DSS and ISO 2700X series



•  Which of these should you implement? •  All of them? (Again, security vs. freedom.) •  Don’t forget to impose those human &

business rules on internal users! –  80.123456% of DDoS cases come from inside the

house.



•  Identity •  Authentication •  Authorization •  Encryption (Channel Security) •  Accounting (Auditing)

Technical Remedies!


Identity Authentication Authorization Channel Enc. Accounting Dedicated ATM X X 802.1X X X LDAP X X (definitions) ActiveDirectory X X (definitions) Database Table X RADIUS/Diameter X X X VPN / IPSec X X X.509 X X SSL, TLS, DTS X Basic/Digest Auth, Login X X 2-factor X Master login X X API keys X X (primitives) OAuth 1.0 OAuth 1.0a X (primitives) OAuth 2.0 X (primitives) OpenID X OpenID Connect X SAML X X (primitives) Shiro or other framework X X Splunk or other logging X Roll your own

Recap


1.  Dedicated ATM connection –  You laugh, but…

Technical Remedies!


2.  Identity Providers –  LDAP –  ActiveDirectory (provides authorization as well) –  User table in your database… –  Third party: Google, Twitter, etc. — still usually

maps to a user record in your internal tables. –  Every other combination of solutions will use one

of the first three in this list!

Technical Remedies!


3.  Network Channel Security –  LAN level: 801.1X –  Beyond: use VPN/IPSec –  Both provide machine authentication and point-

to-point channel encryption –  Both would rely on a RADIUS or Diameter server

for user authentication and authorization management

Technical Remedies!


4.  Application/HTTP Channel Security –  SSL, TLS –  X.509

Technical Remedies!


4.  Authentication –  Basic/Digest Auth (over SSL) –  Login form then API key –  Optional 2-factor (code generator, keyfob, etc.) –  Plugged to LDAP, or table of API keys or

hardcoded master login (bad). –  All or nothing keys: like giving every app full

access to your facebook account

Technical Remedies!


4.  Authentication/Authorization with OAuth –  OAuth fundamentally tries to solve this problem, by

doing authentication but allowing to segment authorization per app

–  “Valet Key” analogy: the App has access to the system as you, but cannot do certain things (like change your password)

–  That valet key is a token, that automatically expires after a certain time

–  Allows for “3-legged Authentication”, not just API and App or (API and User), but API, App and User

•  Use for revokes and accounting –  You still end up doing a regular authentication

somewhere in the middle (Basic auth, login form, etc.)

Technical Remedies!


–  OAuth 1 •  Do not use OAuth 1.0: logically insecure •  OAuth 1.0a (RFC edition) fixes that, works nicely, in

use at Twitter •  Signatures are hard (made so you don’t have to rely on

SSL/TLS though) •  Malicious Apps can be kicked out and all their tokens

revoked •  Web authentication flow can use keyfobs or other multi-

factor auth systems •  Very web-centric. The ideal use-case when it was

designed was “allow Twitter to access my Flickr photos”

Technical Remedies!


–  OAuth 2.0 •  Lead author famously walked out, not all bad though! •  Hard to implement correctly, in a secure manner •  Lots of grant types •  Not as interoperable as OAuth 1 — really a framework,

for security, not a protocol anymore •  Formalizes “scopes” for specific permissions (like “post

to wall”, “see friends”, etc.) •  Introduces refresh tokens — stay away •  Introduces compatibility with SAML and JWT — stay

away •  2 token types: Bearer and MAC

Technical Remedies!


–  OAuth 2.0 Bearer Tokens •  only ones used in practice •  as insecure as a Bearer Bond •  Heavily rely on channel being secure, which is rarely

the case, even over HTTPS •  No client binding

–  App B could use a token issued for App A to log in as you to App A

–  Facebook wrote its own extension to deal with that •  Stay away from refresh tokens, it only serves a very

narrow use-case where two-tier refreshes are necessary.

Technical Remedies!


5.  Authorization –  Shiro — a Java framework to enforce

authorization rules in your apps –  SAML — full XML protocol to handle

authentication and authorization

Technical Remedies!



Recap



Connect 5!


Identity Authentication Authorization Channel Enc. Accounting Dedicated ATM X X 802.1X X X LDAP X X (definitions) ActiveDirectory X X (definitions) Database Table X RADIUS/Diameter X X X VPN / IPSec X X X.509 X X SSL, TLS, DTS X Basic/Digest Auth X X 2-factor X Master login X X API keys X X (primitives) OAuth 1.0 OAuth 1.0a X (primitives) OAuth 2.0 X (primitives) OpenID X OpenID Connect X SAML X X (primitives) Shiro or other framework X X Splunk or other logging X Roll your own

Connect 5!


•  Use-cases –  Internal APIs –  Partner APIs –  Public APIs (consumer, open, mobile etc.)

•  Tiers (legs)

–  Server-to-Server (internal, partner) usually 2-legged authentication

–  End-user (consumer, mobile, open) usually requires 3-legged authentication

API Types (again) `


•  Internal, Server-to-Server APIs –  Use OAuth 2.0 with Bearer Tokens obtained through a Client

Credentials grant (only 2-legged requirement) –  Alternatives: 802.1X with RADIUS/Diameter, X.509

•  Partner, Server-to-Server APIs –  Use OAuth 2.0 with Bearer obtained through a Client

Credentials grant (only 2-legged requirement) –  Alternatives: VPN/IPSec with RADIUS/Diameter, X.509

•  Consumer, Open or End-user Internal/Partner –  Consumer/Open APIs: use OAuth 2.0 with Bearer Tokens,

using Authentication Code or Implicit Grant flow (better support for advanced authentication options, less trust on clients)

•  Mobile APIs –  use Oauth 2.0 (3-legged requirement) with Bearer Tokens

obtained through a Resource Owner grant or OS integration if available (better UX)

Recommendations


•  Security vs. Freedom •  Devil’s advocate OAuth 1.0a isn’t all bad, and

tons of people implement it for Twitter. •  How badly do you want to protect this vs. how

badly do you want people to use it? •  All the way to physically securing the

interface…

In conclusion…


•  Questions, comments: [email protected] [email protected]

Thanks!

Technology

CIS13: APIs, Identity, and Securing the Enterprise