Digests some of this year’s essentials. Things are likely to be encountered in the next years too – we live in interesting times!

1. IT-SECURITY
@Contemporary Life
December 20, 2013
Oliver Pfaff

2. Use Case: Car-as-Callee
What Is It About?
?
▶
▶
▶
▶
▶
▶
Use cases
Blow horn, flash lights,
Get location,
Get energy status,
Get/change temp,
Open/close doors,
…
Dec 2013
Questions
▶ What happens between
mobiles and cars –
IT-security/IAM?
▶ For which reasons?
▶ …
3

3. Use Case: Car-as-Caller
What Is It About?
?
▶
▶
▶
▶
▶
▶
Use cases
Get personal news,
Hear blog posts,
Listen my music,
Post to Facebook walls,
Read tweets,
…
Dec 2013
Questions
▶ As for car-as-callee
4

4. Protecting Web-Based Services
Key Question: Is Classical Web Security Enough?
Web UI
endpoints e.g.
www.facebook.com
Web browser
Mobile browser
Browserbased apps
Mobile apps
Composite
applications
Dec 2013
Provider of
Web-based
services e.g.

Classical Web security
▶ Application: form-based login
▶ HTTP: SSO session cookies
▶ Transport: SSL/TLS
Web API
endpoints e.g.
graph.facebook.com
…
?
Classical Web security
▶ Application: form-based login
▶ HTTP: SSO session cookies
▶ Transport: SSL/TLS
5

5. Web-Based Services
How Does the Web Evolve?
XYZ
Mobile browser
HTTP
Web browser
XML,JSON
Browser-based apps
XML,JSON
The Web we are familiar with
HTML,XML,JSON
HTML
User
IoT
HTML
Web
application
Web container
SQL (or…)
Database
(or directory…)
Mobile apps
XML,JSON
Composite applications
1995
2000
2005
2010
Things-backed
Read/write aka
Mobile browsers/apps,
Database-backed
applications
Web 2.0, AJAX clients
Composite applications
applications, desktop
browsers, read-only
Dec 2013
6

6. Internet-of-Things
Cornerstones to this Expansion
Web/REST APIs: expose functionality for programmatic consumption
by others via Web  allowing others to add value
Mobile: smart-phones/tablets are the preferred user-devices  defines
the mode of access: via general-purpose devices from Internet
Social: users already signed-up&in at Facebook, Google, Twitter etc.
 social providers are co-actors when delivering SSO user experience
Dec 2013
7

7. One User=One Account
But With Multiple Credentials
Level of
authentication
assurance
Asymmetric
One-time
password
Step-up
authn
Re-authn
Open/close
door
Static
password
Persisted
login
Social
provider
Anonymous
Dec 2013
Step-up
authn
Re-authn
Get energy
balance
Re-authn
Virtual garage:
store car config
Selfasserted
Social
provider
Trusted
Successful
Address
verification transactions introducers
Level of identity
assurance
8

8. Use Case: Car-as-Callee
Which Trick to Do?
Public-facing
Web API endpoints
e.g. api.mycompany.com
Web
application
Resources
User
Mobile
Enter
credentials app
once
Access one Web
application in subsequent
app sessions
▶ Event:
– User accesses a Web application with her/his mobile app (tablet/smart phone)
– Recurring requests to this Web application in subsequent app sessions
▶ Goal: persistent login
– One user login allows to access a Web application in various mobile app sessions
▶ Example: login once to GMail mobile app - access GMail for a period of time
Dec 2013
9

9. Use Case: Car-as-Callee
Chickens - Birds that Do Not Fly
▶ IT-security: rely on single credential (typically a username/password-tuple)
– Lost device: for usability reasons mobile apps would store the credentials.
This presents an attack surface when mobile devices get lost
– Race condition: if such attacks succeed the user identity can be taken over
(password change by attacker)
– Recipe:
• Use initial authentication credentials (e.g. username/password) to create
subordinate, inherited credentials (login tokens) stored in mobile apps.
• Provide revocation endpoints for login tokens - protected by initial
authentication or other superordinate credentials
▶ IAM: coin an own session handling for persisted login (protocol/infrastructure)
– API anti-pattern: before 2012 (OAuth 2.0, RFC 6749) proprietary protocols
and infrastructure were needed to do this trick – increases overall integration
complexity (#n APIs  #n security realizations), repelling the external
developer community
Dec 2013
10

10. Use Case: Car-as-Callee
New Web Security Standard: OAuth-2 Parties
Revocation
endpoint
Token
endpoint
Post <user creds>
(or refresh_token)
Token
store
access/refresh_token
refresh_token
User
store
TokenInfo
endpoint
Device store
Security APIs
Resource
endpoint
Business APIs
Post,Get,Put/Patch,Delete
with access_token
API consumer
Resource
API provider
Dec 2013
11

11. Use Case: Car-as-Caller
Which Trick to Do?
User
agent
Public-facing
Web API endpoints
e.g. graph.facebook.com
User A
User
agent
User B
Web
application
Resources
composite.mycompany.com
…
User
agent
UserZ
Composite
application
Authenticates
A,B…Z
Authenticates
composite app
Owned by
consumer
user B
▶ Event:
– A Web application provides access to user-owned resources
– It is called by other applications acting on behalf of users (called
composite applications)
▶ Goal: user-managed access
– Resource owner retains control of whom may access her/his resources
▶ Example: third-party application posts to user’s Facebook wall
Dec 2013
12

12. Use Case: Car-as-Caller
Chickens - Birds that Do Not Fly
▶ IT-security: rely on 2-party authentication contexts
– Provide user credentials to third-parties (here: composite applications)
which authenticate themselves as users – anti-pattern
– Use client credentials of composite applications only
• API consumers (here: composite applications) authenticate users - okay
• API providers authenticate API consumers - okay
• API providers trust API consumers to make “I ask for John Doe” requests
only when John Doe is asking to do so – in many cases not good enough
▶ IAM: use enterprise authorization machinery (EIAM products)
– Utilize long-lived authorization policy objects established a-priori and
managed out-of-band (from the browsing sessions of users)
Dec 2013
13

13. Use Case: Car-as-Caller
New Web Security Standard: OAuth-3 Parties
Get <clientID, scope>
(establish authn/authz)
User
Authz
endpoint
Redirect with code
Redirect
with
clientID,
scope
Get
<code>
Post <client creds,code>
access_token
Composite
application
API consumer
Dec 2013
Token
endpoint
TokenInfo
endpoint
User
store
Token
store
Client
store
Security APIs
Post,Get,Put/Patch,Delete
with access_token
Resource
Resource
endpoint
Business APIs
API provider
14

14. The Trick Behind these Tricks
New Web Security Protocols Facilitate Decoupling
▶ Some Web API use cases have no adequate coverage in classical Web security
– Mobile app authentication - persisted login (cf. car-as-callee)
– Resource access authorization – in presence of intermediaries (cf. car-as-caller)
▶ For others where alternatives exist: uniform security enforcement for various
API protection use cases. Following working schedule applies:
Post, Get, Put/Patch, Delete… /resource no OAuth token
Is resource protected?
Yes
Is OAuth token present?
HTTP 401 Unauthorized
No
Post, Get, Put/Patch, Delete… /resource with OAuth token
Is token valid? Get
token metadata
Get /tokeninfo for OAuth token
HTTP 200 OK <tokenMetadata incl. validity>
Standardization ongoing
Okay (else: HTTP 401 Unauthorized)
HTTP 200 OK/201 Created <Resource>
Dec 2013
Does request match
token metadata?
Okay (else: HTTP 401 Unauthorized)
RFC 6750
15

15. Protecting Web-Based Services
Revised
Web UI
endpoints e.g.
www.facebook.com
Web browser
Mobile browser
Browserbased apps
Mobile apps
Composite
applications
Dec 2013
Provider of
Web-based
services e.g.

Classical Web security
▶ Application: form-based login
▶ HTTP: SSO session cookies
▶ Transport: SSL/TLS
Web API
endpoints e.g.
graph.facebook.com

…
New Web security
▶ Application: OAuth services
▶ HTTP: OAuth tokens
▶ Transport: SSL/TLS
16

16. Use Case: Car-as-Callee
Best Current Practice
1. Authn
2. Get VINs/
vehicles
3. Select car
4. Do things
remotely…
Public
networks
Car connect
infrastructure
Web API
infrastructure
6. Instruction
msg to IMSI
5. Backend operation
with VIN
VINs
Identity
store
User<X>:
userid,
password,
VINs…
Vehicle
object
7. Get details
IMSI
VPN
Embedded
communication
endpoint
CRM
store
Vehicle<Y>:
VIN
IMSI…
User/car pairing via VIN. Managed by maker (CRM application) and/or
owners (portal) - subject to applicable contract/security means
Dec 2013
17

17. Provider of
Web UI
Web-based
endpoints e.g.
services e.g.
www.facebook.com
Wide-area
Gateway
(data center)
Integrated mobile browser
(smart-phone as modem)
New Web security
Classical Web
security
Use Case: Car-as-Caller
Current Practices
Nearfield
Wide-area
Head unit Mobile app
(OTS)
integration
Web API
endpoints e.g.
graph.facebook.com
…
Wide-area
Vendor-specific device app
(smart-phone as modem)
Dec 2013
Composite application
(data center)
18

18. Conclusion
We Live in Interesting Times
▶ Everything is changing – new use case require new approaches:
– IT-security: classical Web security is no full answer for new use cases around
social, mobile, IoT and Web APIs
 New suite of Web security mechanisms: OAuth (IETF), OIDC (OIDF),
JOSE (IETF), UMA (Kantara)…
– IAM: old-school EIAM also is no full answer for them
 New cases (consumer users), entities (devices/things…) and
concepts (relationship management)…
▶ OAuth is the leader of ‘new Web security’ - but is also a whole zoo in itself:
– OAuth 2.0 additions turn the special-purpose tool OAuth 1.x into a Swiss-knife
 Confusion is omnipresent
– OAuth is a framework many options that leaves many decisions to implementers
 ‘New Web security’ solutions come in many colors and flavors
▶ This already is real - not abstract/academic – and will become pervasive
– Security services/infrastructure delivered by OAuth endpoints can be adopted
by environments that do not use HTTP as their native protocol
Dec 2013
19

19. Author
Oliver Pfaff, oliver.frank.pfaff@gmail.com
Dec 2013
20

20. Abbreviations
AJAX
API
Authn
Authz
CIAM
CRUD
EIAM
IAM
IdM
IMSI
IoT
JOSE
JSON
JWT
OAuth
OIDC
OIDF
OTS
Dec 2013
Asynchronous JavaScript and XML
Application Programming Interface
Authentication
Authorization
IAM for Consumer users
Create/Read/Update/Delete
IAM for Enterprise users
Identity and Access Management
Identity Management
International Mobile Subscriber
Identity
Internet of Things
Javascript Object Signing and
Encryption
Java Script Object Notation
JSON Web Token
Open Authorization
OpenID Connect
OpenID Forum
Off-The-Shelf
REST
ROPC
SAML
SOAP
SSO
UA4C
UI
UMA
VIN
VPN
XML
Representational State Transfer
Resource Owner Password
Credentials
Security Assertion Markup Language
Simple Object Access Protocol
Single-Sign-On
User Authentication for Clients
User Interface
User Managed Access
Vehicle Identification Number
Virtual Private Network
eXtensible Markup Language
21

21. Further Information
▶ Bertocci, Vittorio: OAuth 2.0 and Sign-In. Blog 2013
▶ Bray, Tim: How to Think About OAuth. Blog 2013
▶ Fielding, Roy: Architectural Styles and the Design of Network-based Software
Architectures. PhD Thesis. University of California, Irvine, 2000.
▶ Glazer, Ian: Killing Identity Management in Order to Save It. YouTube 2013
▶ Hunt, Phil: OAuth: Does It Authorize? Blog 2011
▶ Jones, Mike: The Emerging JSON-Based Identity Protocol Suite. Paper - W3C
Workshop on Identity in the Browser 2011
▶ Kiani, Khash: OAuth-Securing the Insecure. Presentation 2011
▶ Madsen, Paul: Mobile Native App-OAuth Decision Framework. Presentation 2011
▶ N.N.: BMW to have 10M connected cars in 5 years. Heads-up 2013
▶ Pautasso, Cesare; Zimmermann, Olaf; Leymann, Frank: RESTful Web Services
vs. “Big” Web Services: Making the Right Architectural Decision. Proc. of the
17th International World Wide Web Conference, Bejing, 2008.
▶ Richer, Justin: Auth* in the Extended Enterprise. Presentation - MIT Legal HackA-Thon 2013
▶ Web API directory: http://www.programmableweb.com/apis/directory
▶ Yegge, Steve: Stevey's Google Platforms Rant. Posting 2011
Dec 2013
22

22. About Web/REST APIs
Web




APIs:
Programmatic interface to a remote IT-system
Exposed for consumption across wide-area networks
Accessed by means of HTTP
Request/response contents expressed as JSON or XML
REST:
 Architectural style for Web APIs
 Utilizes HTTP to deliver CRUD operations for arbitrary
abstractions; without alien protocols such as SOAP
Examples:
 Amazon Web Services, Facebook, Force.com, Google, Twitter,
Yahoo
 Many more, cf. programmableweb.com for a directory of Web
APIs
Dec 2013
23

23. Anatomy of Web/REST APIs
CREATE – HTTP Post
In: URL, headers, JSON/XML
Out: JSON/XML
READ – HTTP Get
In: URL, headers
Out: JSON/XML
UPDATE – HTTP Patch/Put
Browser-based/
mobile apps,
composite
applications
Web API
endpoint
(e.g. servlet)
In: URL, headers, JSON/XML
Out: JSON/XML
DELETE – HTTP Delete
In: URL, headers
Out: n.a.
CREATE – HTTP Post
In: URL, headers, keywords/values
Out: HTML
Web/mobile
browsers
Dec 2013
READ – HTTP Get
In: URL, headers
Out: HTML
Web UI
endpoint
(e.g. servlet,
JSP, JSF)
24

24. API Initiatives in Automotive
▶ Published APIs:
– SDK esp. JavaScript APIs and/or Web APIs:
• Ford Vehicle API
• Genivi Web API Vehicle
• GM Vehicle API
• Tizen (Intel) Vehicle API
• QNX Automotive API
• Webinos (BMW et al.) Vehicle API
– Cf. W3C for API initiatives in automotive
▶ Unpublished APIs‎
:
– Various
Dec 2013
25

25. Taxonomy of Web Applications
Web application (e.g. war file)
Web API
Web UI
Multi-user
API client
Single-user
API client
Property
Value
Property
Value
Property
Value
Consumers
Web/mobile
browsers
Consumers
Browser-based
apps/mobile apps
Consumers
Composite
applications
Programmatic
access
No
Programmatic
access
Yes
Programmatic
access
Yes
Caller serves
multiple users
No
Caller serves
multiple users
No
Caller serves
multiple users
Yes
HTTP methods
Post/Get
HTTP methods
Request
content
application/xwww-formurlencoded
Post/Get/Put/
Patch/Delete etc.
HTTP
methods
Post/Get/Put/
Patch/Delete etc.
Request
content
application/json or
xml
Request
content
application/json or
xml
Response
content
application/xhtml
+xml, text/html
etc.
Response
content
application/json or
xml
Response
content
application/json or
xml
Dec 2013
26

26. Types of Web Application Clients
▶ Web/mobile browsers
– Provided as classical software installations resp. in app stores
– Run as standalone applications on desktops/laptops (e.g. Chrome, Firefox, IE,
Safari) or tablets/smartphones (e.g. Chrome, Firefox mobile, IE Mobile, Safari)
– Serve single users, allow to access arbitrary servers on the Web
▶ Browser-based apps
– Downloaded from Web applications (scripts in source form)
– Executed in Web browsers e.g. AJAX client for GMail access
– Serve single users, allow to access a dedicated servers on the Web
▶ Mobile apps
– Provided in app stores (binary form)
– Run as standalone applications on tablets or smart-phones e.g. GMail app
– Serve single users, allow to access a dedicated servers on the Web
▶ Composite applications aka Web server-based apps
– Provided by services on the Web
– Run in Web or application servers e.g. USPS Tracking (US Postal Service/
Google Maps APIs)
– Serve a whole user population, utilize other downstream Web applications
Dec 2013
27

27. OAuth 2.0 Clients Taxonomy
Web client vs.
OAuth Grant Types
Browser-based
app
Mobile app
Composite app
Authorization code
- (client is public)
- (client is public)
☺
Implicit
☺
☺
-
ROPC
☺
☺
-
Client credentials
- (client is public)
- (client is public)
☺
Refresh token
☺ (via ROPC)
☺ (via ROPC)
☺ (via
authorization code)
JWT/SAML bearer
token/assertion
☺
☺
☺
Custom
N.a.
N.a.
N.a.
Note: Web browsers can not act as OAuth clients (for ROPC they could post OAuth token requests if
supported by adequate forms but can not render responses; additional deltas apply for other grant types)
Dec 2013
28

28. OAuth 2.0 Clients Best Current Practice Example
Google APIs
Web client vs.
OAuth Grant Types
Browserbased app
Mobile app
Composite app
Authorization code
-
OAuth 2.0 for
OAuth 2.0 for Web
Installed Applications* Server Applications
Implicit
OAuth 2.0 for
Client-side
Applications
-
-
ROPC
-
-
-
Client credentials
-
-
-
Refresh token
-
Via authorization
code, custom
Via authorization
code
JWT/SAML bearer
token/assertion
-
-
OAuth 2.0 for
Server to Server
Applications
Custom
-
OAuth 2.0 for Devices
-
*: Requires that the application has access to the system browser or the ability to embed a browser control in the
application. Does not match RFC 6749 which classifies mobile apps as public clients which are expected to employ
the implicit grant rather than the authorization code grant
Dec 2013
29