• Share
  • Email
  • Embed
  • Like
  • Private Content
API Security & Oauth Patterns RSA Europe  @flascelles
 

API Security & Oauth Patterns RSA Europe @flascelles

on

  • 74,610 views

Exposing service-oriented connectivity points using Web APIs, REST creates new security challenges for the enterprise. Mr. Lascelles’ presentation will make sense of SAML, OAuth, OpenID, API keys, ...

Exposing service-oriented connectivity points using Web APIs, REST creates new security challenges for the enterprise. Mr. Lascelles’ presentation will make sense of SAML, OAuth, OpenID, API keys, HMAC, custom tokens, cookies and more, and will explain how these protocols fit together and how the enterprise can leverage such technologies for enabling trust management and access control.

Statistics

Views

Total Views
74,610
Views on SlideShare
74,048
Embed Views
562

Actions

Likes
3
Downloads
89
Comments
0

7 Embeds 562

http://www.layer7tech.com 533
http://paper.li 16
https://twitter.com 5
http://layer7.com 4
http://www.layer7.com 2
http://nouveaumonde.wordpress.com 1
http://translate.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Example problem: shared secrets that end up on traffic logs
  • Grant types (flows)Authorization codeImplicitResource owner password credentialsClient credentialsSAMLFoo
  • OAuth client is for example a webapp, an iOS app
  • What would be nice here: 3 slides before during the oauth handshake, as a resource owner, when I grant authorization, I get an email confirming the authorization I granted and a link to revoke this authorization. Or maybe there is a just a web page that allows you to see all of the authorizations you granted.Why revoke? Maybe the client is an iphone app and the resource owner lost his mobile phone. Note that the password is actually not compromised.

API Security & Oauth Patterns RSA Europe  @flascelles API Security & Oauth Patterns RSA Europe @flascelles Presentation Transcript

  • Enterprise Access Control Patterns for REST and Web API
    Francois Lascelles
    Layer 7 Technologies
    Session ID: STAR-305
    Session Classification: Intermediate
  • Today’s enterprise API drivers
    SAAS
    distributed enterprise SOA
    Integration APIs!
    partner
    Cloud APIs!
    IAAS/PAAS
    B2B
    APIs!
    enterprise boundary
    Access control?
    B2C
    APIs!
    • Sensitive data, apps
    • Mission critical
    • ID authority
    • Legacy
    developer
    mobile
  • Agenda
    WS-* web services have rich security standards and authentication/authorization mechanisms
    Web API, RESTful web services tend to use proprietary tokens, point-to-point solutions
    What are the common patterns in use?
    Which standards are emerging?
    How to use specialized infrastructure to implement access control?
    How to accommodate requesting party technical capabilities?
  • Pattern 1: API Keys in URI parameters
    https://host/api/resource?keyid=foo&keysecret=bar

    Simplest thing, common practice
    Shared secret in a URL parameter based authentication, no signature involved
    Equivalent to https://host/api/resource?username=franco&password=mysecret
    Why not use HTTP Basic instead?
  • Pattern 2: HMAC
    PUT /api/resource

    Authorization: AWS keyid:fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=

    Use the key to actually sign something
    Shared secret not sent
    Payload covered by signature -> message integrity
    Timestamp covered by signature -> less susceptible to replay
    Used by AWS, Azure
    Implementations are proprietary, not compatible
    5
  • Pattern 3: OAuth
    Retrieve resource with owner authorization
    (REST exchange)
    Autz server
    Application
    Resource provider
    Do something with my resource
    Yes, I authorize it
    Resource owner
    GET /somewhere/someresource

    Authorization: OAUTH fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=

  • OAuth Benefits
    OAuth 2.0 is poised to fill the standards gap
    Passwords remain secret
    Tokens easier to ‘control’ than passwords
    Resource-oriented => perfect for REST
    Many different flows to accommodate different use cases (two and three parties)
    Different token types
    Bearer (easy, like cookies)
    MAC (integrity, more secure)
  • What about SAML?
    A rich and established standard for making various claims regarding an identity (authentication statements, authorizations statements, attribute statements)
    SAML is well supported by existing enterprise infrastructure
    SAML is verbose
    8KB is too big a token for an authorization header or a query parameter
    You can gzip + base 64 encode the token to make it fit
    SAML is based on XML
    My API uses JSON, not XML
    It does not matter, the two should be decoupled
    Binding specifications for Web browser SSO, SOAP+WSS, but no formal binding for REST, web APIs
    SAML Bearer Profile for OAuth 2.0
  • Sample SAML binding for RESTful web service
    GET /token/joe
    Authorization: …
    200 OK
    <saml:Assertion …
    />
    GET /someresource
    Authorization: SAML PmfrTLJwMuZurA8=
    trust
    200 OK

    9
  • 10
    Step-by-step enterprise API access control
    (from an OAuth perspective)
  • Starting Point
    enterprise/provider admin
    Resources (API)
    I need
    more OAuth
    FAIL!
    OAuth Client
    (application)
    Resource owner
  • OAuth Clients Provisioning, Management
    provider admin
    app developer
    2
    1
    OAuthClients
    3
    Create/manage my account, get shared secret, define my callback
    Approve new clients, list existing client, get stats on usage
    Provision app with account id, shared secret
  • Runtime Policy Modeling, Integration
    1
    OAuthClients
    1
    1
    Prot Res Server
    Administrator declares internal APIs to be accessed using OAuth authorization
    which token types – Bearer, Mac
    which flows
    http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03
  • OAuth Handshake
    OAuthClients
    OAuthTokens
    2, 3
    2, 3
    2
    3
    OAuth Autz server
    Prot Res Server
    1
    Client redirect owner to oauth provider
    Policy looked up, flow executed: OAuth handshake as per flow.
    Client is authenticated, gets access token
    2
  • OAuth Resource Retrieval
    OAuthClients
    OAuthTokens
    3
    2
    1
    Prot Res Server
    OAuth Autz server
    Client uses access token to access resource
    Protected resource server validates incoming token, authorize specific access based on token attributes, updates usage statistics
    The API is called on behalf of, and returned to client
  • Token Refresh
    OAuthClients
    OAuthTokens
    2
    1
    2
    1
    1
    OAuth Autz server
    Prot Res Server
    2
    Client uses refresh token to extend access resources on behalf of resource owner. Autz server authenticates Client and update the token
    Client access resource using refreshed token
  • Owner-driven Token Revocation
    OAuthClients
    OAuthTokens
    2
    1
    OAuth Autz server
    Prot Res Server
    2
    FAIL!
    Resource owner revokes authorization previously granted to Client. Autz server revokes corresponding token.
    Client tries to access resource, access is refused.
    1
  • Provider-driven Token Revocation
    2
    OAuthClients
    OAuthTokens
    3
    OAuth Autz server
    Prot Res Server
    1
    FAIL!
    Client is hacked, access tokens compromised
    Administrator revokes all tokens issued to this particular client
    Hacker cannot use old tokens to access resources
    3
    Client prompts resource owner to repeat OAuth handshake. Owner does not need to change password.
  • Monitoring, Reporting
    OAuthClients
    OAuthTokens
    OAuth Autz server
    Prot Res Server
    Analytics
    Report on APIs, Clients, Owners. Monitor usage, performance.
  • Comprehensive REST Access Control
    Omg, it’s full of win
    OAuthClients
    Provisioning
    Approval Flow
    Persistence
    Querying
    Metrics
    OAuthTokens
    Persistence
    Querying
    Metrics
    Revocation
    Refresh
    *all of this*
    OAuth Autz server
    Policy Modeling
    OAuth Protocol
    Identity integration
    Token issuing
    Token refresh
    SLA enforcement
    Prot Res Server
    Policy Modeling
    Token validation
    Bearer, MAC
    Identity integration, SAML
    Integrity check
    API proxying
    SLA enforcement
    Analytics
    Reports
    Monitoring
    SLAs
    Alerting
  • APPLY
    Decouple OAuth and other access control mechanisms from actual API implementations
    Enable OAuth for existing APIs by deploying OAuth broker at perimeter
    Configure, not code
    Ensure support for OAuth 2.0 and all of its richness
    21
  • 22
    Thank you
    For more information:
    info@layer7.com