The document discusses how Identity and Access Management (IAM) can be applied to Representational State Transfer (REST) web services and contrasts it with traditional SOAP-based services. It covers various aspects such as initial and federated authentication, single sign-on, and authorization in the context of RESTful services, highlighting the challenges and opportunities unique to this architectural style. Ultimately, it concludes that IAM for REST must cater to different types of clients and establish new methods to support the authentication and authorization needs inherent to RESTful applications.

1. Does REST Change the
Game For IAM?
Oliver Pfaff
February 29, 2012

2. Contents
▶ Questions
▶ Fundamentals
▶ Observations
▶ Answers
– Employing IAM
– Delivering IAM
▶ Conclusions
▶ References
February 2012 - All rights reserved 2

3. Questions
▶ IAM for REST:
– How to provide IAM functionality for RESTful Web services?
▶ REST for IAM:
– How to use RESTful Web services to deliver IAM functionality?
February 2012 - All rights reserved 3

4. Fundamentals
Characterizing RESTful Web Services
▶ Message layout:
Response: – JSON, XML (or else)-in-HTTP for
JSON, XML requests and responses
or arbitrary ▶ Clients:
data
– Content-unaware clients (Web
browsers)
Request: – Content-aware clients (e.g. apps
JSON, XML utilizing WADLs/WSDLs or client-
or arbitrary
side classes based on e.g. JAX-RS)
data
▶ Aiming at following callers:
– Humans (represented by their user
agents)
HTTP – Applications (facilitating machine-
body to-machine interactions)
POST: create
GET: read
▶ Service descriptions/contracts:
HTTP
PUT: update header
– WADL, WSDL 2.0
DELETE: delete – XSD
February 2012 - All rights reserved 4

5. Fundamentals
Vs. SOAP-Based Web Services
▶ Message layout:
XML, – XML-in-SOAP-in-HTTP for requests
arbitrary and responses
data via ▶ Clients:
attach-
ments – Content-aware clients (e.g. Web
service clients utilizing WSDLs or
client-side classes based on e.g.
SOAP JAX-WS)
body
▶ Aiming at following callers:
SOAP
– Applications (facilitating machine-
header to-machine interactions)
▶ Service descriptions/contracts:
HTTP – WSDL
body
– XSD
POST: request-response HTTP
GET: soap-response header
February 2012 - All rights reserved 5

6. Fundamentals
Vs. Traditional Web Applications
▶ Message layout:
Response: – URL query or HTML form
HTML,
arbitrary
parameters-in-HTTP (for requests)
data via – HTML-in-HTTP (for responses)
MIME type ▶ Clients:
Request: – Content-unaware clients (Web
empty or browsers)
keyword/ ▶ Aiming at following callers:
value pairs
as URL query
– Humans (represented by their user
or HTML form agents)
parameters ▶ Service descriptions/contracts:
– None
HTTP
body
POST: user input HTTP
GET: read header
February 2012 - All rights reserved 6

7. Fundamentals
Relevance of RESTful Web Services
▶ For those starting from traditional Web applications, RESTful Web services
provide a more natural evolution path than SOAP-based Web services:
– Conceptually RESTful Web services present a superset of traditional Web
applications: RESTful Web services can serve off-the-shelf Web browsers
– SOAP-based Web services and traditional Web applications are rather disjoint:
SOAP-based Web services can not serve off-the-shelf Web browsers
▶ Constrained clients (apps upon smart phones) tend to prefer RESTful Web
services (with JSON) over traditional Web applications (HTML). For bandwidth
reasons, XML (hence SOAP) is avoided by such clients.
– The popularity of smart phones pushes application providers towards JSON as
preferred form-factor for exchanged data.
– REST provides the architectural style for that.
▶ The so-called API economy rather depends on REST than SOAP style: composite
applications/mashups rather build upon RESTful Web services than SOAP-based
Web services. For instance, www.programmableweb.com currently lists:
– 3557 APIs for the REST style
– 966 APIs for the SOAP style
February 2012 - All rights reserved 7

8. Observations
Content Data vs. Protocol Stack
▶ RESTful Web services are a bit of a chameleon:
– With respect to their support of structured data aiming at consumption by
content-aware clients, RESTful Web services compare to SOAP-based Web
services rather than traditional Web applications
– With respect to the employed protocol stack, RESTful Web services compare to
traditional Web applications rather than SOAP-based Web services
▶ Hence, IAM and security mechanisms designed for the
– HTTP layer provide candidates for usage with RESTful Web services e.g.
• HTTP authentication
• SSL/TLS
– SOAP layer are unavailable for RESTful Web services e.g.
• WS-Trust (as key IAM enabler for SOAP-based Web services)
• WS-Security (as key security enabler for SOAP-based Web services)
February 2012 - All rights reserved 8

9. Observations
Referring to Resource Instances
▶ When RESTful Web services are used to implement CRUD functionality, they
need to refer to instances of resource objects (e.g. John Doe’s contact list).
▶ This can be done by means contained in HTTP requests (headers and/or bodies).
Details are specific to the actual implementations including following options:
– Instances of resource objects are referred to by path parts in HTTP request
URLs (GET, PUT, DELETE) – the best practice approach
– Instances of resource objects are referred to by query parts in HTTP request
URLs (GET) resp. body parts in HTTP requests (PUT, DELETE)
▶ Note: POST serves the (initial) creation of an instance of a resource object.
Identifiers for (new) instances of resource objects are implicitly assigned.
February 2012 - All rights reserved 9

10. Answers – Employing IAM
IAM Fingerprint of RESTful Web Services
▶ The section “employing IAM” identifies the IAM fingerprint of RESTful Web
services
▶ Following topics are considered:
– Initial authentication: refers to the authentication of REST requestors resp.
requests through credentials (e.g. passwords, shared secret keys for one-
time-password authentication, public key certificates) sustained by the REST
responder or within its domain
– Federated authentication: refers to the authentication of REST requestors
resp. requests through credentials not sustained by the REST responder or
within its domain
– Single-sign-on: refers to the ability to subsequently authenticate at multiple
systems or applications and access them after a single initial or federated
authentication
– Authorization: refers to the determination whether requestors may access
particular resources according specific actions and its enforcement
February 2012 - All rights reserved 10

11. Answers – Employing IAM
Initial Authentication – Standards-Based
▶ To establish initial authentication, REST responders need to challenge requestors
to present credentials. The mechanisms catalog comprises means:
– Beneath the HTTP layer: SSL/TLS client authentication (RFC 2818)
– On HTTP header level: HTTP-defined authentication means (RFC 2616)
• Classical: Basic and Digest (RFC 2617), Negotiate (RFC 4559)
• Emerging: MAC (draft-ietf-oauth-v2-http-mac-01.txt), Bearer (draft-ietf-
oauth-v2-bearer-17.txt)
– On HTTP payload level:
• Traditional Web applications use HTML forms for user authentication with
static or one-time-passwords (and other means). This is achieved through
dedicated login Web applications to which users are redirected.
o RESTful Web services may use such means when responding to requests
from Web browsers (aiming at user authentication)
o When serving content-aware clients (aiming at system authentication)
means requiring interactions with users are no option
• When aiming at system authentication with schemes not natively supported
on HTTP header level or underneath the HTTP layer, RESTful Web services
need to consider dedicated non-interactive login applications (cf. below).
February 2012 - All rights reserved 11

12. Answers – Employing IAM
Initial Authentication – Proprietary
▶ The current practice for authenticating non-user requestors of RESTful Web
services is to establish ID/API key-tuples through a registration process.
– This is equivalent to username/password-tuples which are established for users
accessing traditional Web applications
▶ By default, the API keys are shared secrets. They are employed with HTTP Basic
or proprietary authentication schemes (in case there is a need to protect [a
subset] of the message contents through cryptographic checksums)
– HTTP Digest authentication also allows to protect some message contents
through cryptographic checksums but is not used in practice
▶ Proprietary schemes to authenticate REST API calls present an anti-pattern:
– It can be commonly found (quote: “Everyone feels the need to write a custom
authentication protocol”, cf. broadcast.oreilly.com/2009/12/principles-for-
standardized-rest-authentication.html)
– The MAC access authentication scheme for HTTP provides means to avoid this
anti-pattern in future:
• This scheme is currently being developed in the IETF (oauth working group)
• It evolves from OAuth but is not tightly bound to the native OAuth use case
of delegating authorization and can be used on a broader base.
February 2012 - All rights reserved 12

13. Answers – Employing IAM
Federated Authentication
▶ SAML provides the plain vanilla approach to identity federation for traditional
Web applications:
– Defines an XML vocabulary (SAML assertion and protocol syntaxes) to cover a
variety of federated identity management use cases including cross domain
SSO, attribute querying, and SLO.
– Defines 3-party exchanges (actors: user agent, SP, IdP) and 2-party
exchanges (actors: SP, IdP) based on HTTP
– Provides a means to remote initial authentication to an external IdP that is
entity-centric (does not bind or authenticate contents of exchanged messages)
▶ SAML messages pass transparently through user agents and thus may be
considered to federate user and system authentication for RESTful Web services
provided:
– IdPs support means of initial authentication available to non-Web browser
REST clients (esp. non-interactive means of authentication)
– IdPs and SPs employ redirections means supported by non-Web browser REST
clients (e.g. SAML Redirect rather than POST bindings)
– Single-sign-on constraints (cf. below) are not expected to be met in an
orthodox fashion (SAML’s requirement that bearer assertions are not replayed
and REST’s requirement that services are stateless do conflict)
February 2012 - All rights reserved 13

14. Answers – Employing IAM
Single-Sign-On
▶ The REST architecture style assumes services to be stateless: RESTful Web
services shall not store client-specific contexts between requests
▶ Hence (orthodox) RESTful Web services will abstain from the current practices of
traditional Web applications: sustain local state about authenticated users and
identify this state in exchanges with Web browsers by means such as:
– HTTP cookie headers (cf. RFC 2965)
– URL query parameters
– HTML form contents
▶ This does constrain RESTful Web services in providing single-sign-on experiences
for user authentication (not so much an issue for system authentication):
– Encourages Kerberos style: rather than identifiers referring to state sustained
elsewhere, self-contained objects representing an authenticated system entity
should be transferred.
– This comes with challenges on side of IT-security (data origin authentication,
proof-of-possession for those self-contained objects as well as their binding to
message contents) and non-functional characteristics (per message
overhead).
February 2012 - All rights reserved 14

15. Answers – Employing IAM
Authorization
▶ Authorization is a local matter of RESTful Web service providers. It does not add
further dependencies between consumers and producers of REST services (unless
specific use cases such as user consent [e.g. OAuth] are to be addressed).
▶ With PEPs (e.g. servlet-filters) that recognize request contents on the HTTP
header level only, access control can be achieved on following granularity:
– For RESTful Web services identifying resource instances in the URL path
• Create operation: requested resource class
o For example, the Group resource class in SCIM
(www.simplecloud.info/specs/draft-scim-core-schema-00.html) identified
by http(s)://hostname:port/Groups allowing to decide e.g. may John
Doe create a group (endpoint and type of operation)
• Read/update/delete operations: requested resource instance
o For example, the Group resource instance with id=01234-56789 in SCIM
identified as http(s)://hostname:port/Groups/01234-56789 allowing
to decide e.g. may John Doe delete this instance of group (endpoint, type
of operation, and instance of resource object)
▶ If further details of actual requests shall be considered in authorization decision
making, PEPs for RESTful Web services need to understand HTTP request bodies.
Such PEPs may reside in the actual business application or the REST stack.
February 2012 - All rights reserved 15

16. Answers – Delivering IAM
RESTful IAM Services
▶ The section “delivering IAM” considers the realization of IAM functionality through
RESTful Web services
▶ Following use cases are considered:
– User provisioning: IAM services concerned with creating, maintaining, and
terminating user objects
– Login applications: IAM services concerned with performing initial
authentication through an application dedicated to this purpose
– Identity federation: IAM services using federated authentication to split
identity management tasks according the roles of IdPs and SPs as the
producers and consumers of authenticated information about system entities
– Claims-based identity management: IAM services supporting the consumption
of identity data according a clean dependency injection model (consumers of
identity data such as business applications shall be decoupled from means of
storing and managing the identity data)
– Authorization management: IAM services supporting the tasks of authorization
policy management and authorization decision making
February 2012 - All rights reserved 16

17. Answers – Delivering IAM
User Provisioning
▶ User provisioning is concerned with creating, reading, updating, and deleting
user objects (comprising identifiers, attributes, credentials…) in persisted storage
▶ RESTful Web services are capable of providing CRUD functionality for arbitrary
business objects through a variety of input formats (e.g. URL query or HTML
form parameters, JSON, XML) and output formats (e.g. HTML, JSON, XML) via
HTTP
▶ This includes user objects (represented as e.g. entries in an LDAP server) and
makes RESTful Web services a straight-forward candidate for addressing the user
provisioning use case
▶ SCIM (www.simplecloud.info) provides a specification addressing the user
provisioning according the REST style
February 2012 - All rights reserved 17

18. Answers – Delivering IAM
Login Applications
▶ Traditional Web applications use dedicated login applications to
– Brand and customize login screens for initial authentication (esp. initial
authentication with usernames/static passwords)
– Support authentication schemes not natively supported on HTTP or SSL/TLS
level (e.g. one-time-passwords such as RFCs 2289/4226/6238)
▶ Such dedicated login Web applications may be provided as RESTful Web services:
– Does not result in new functionality for the initial authentication of users
(conducted via Web browsers)
– Provides a solution-specific way of performing initial authentication of systems
as clients of RESTful Web services for schemes not natively supported on HTTP
or SSL/TLS level
– Imposes constraints on REST-friendliness of single-sign-on esp. transfer of
authentication context to another application as a consumer.
February 2012 - All rights reserved 18

19. Answers – Delivering IAM
Identity Federation
▶ The well-known identity federation techniques address traditional Web applications
and SOAP-based Web services:
– Traditional Web applications: SAML, OpenID
– SOAP-based Web services: WS-Trust, WS-Federation
▶ There is not yet a standardization effort that would shape IdP and SP components
as well as their protocol interactions according the REST style (here: as RESTful
IdP and SP services that address use cases in federated identity management such
as cross-domain SSO, SLO and attribute exchange)
▶ Some initiatives look at a subset of this problem: the expression of assertions/
statements about an authenticated system entity in non-XML formats esp. JSON:
JWT (JSON Web Token, draft-jones-json-web-token-07.txt, cf.
tools.ietf.org/html/draft-jones-json-web-token-07).
– The goal to address the identity federation use case and retain its main
concepts while avoiding the per-message overhead of XML encodings.
– For a survey of specifications defining and using JWT cf.
www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_30.pdf
February 2012 - All rights reserved 19

20. Answers – Delivering IAM
Claims-Based Identity Management for REST
▶ In claims-based identity management, the consumers of identity data:
– Deliberately ask for identifying information (e.g. UID) and attributes or
contexts (e.g. group memberships, role assignments) they depend on.
Corresponding information is expected to travel in-band with request objects
– Do not lookup supplementary information about requestors from sources in
their backend
▶ This concept goes well with SOAP-based Web services. WS-Trust STSs are key
components in delivering claims-based identity management:
– WS-Trust RST messages allow to request a variety of identity-related
information (identifiers, attributes, contexts such as group assignments and
role membership, authentication state)
– WS-Trust STS components allow to encapsulate the supply and management
of such information
– The integration of WS-Trust exchanges with WS-stacks reliefs the actual
implementations of the Web service providers and consumers from handling
details
▶ A corresponding machinery does not exist for RESTful Web services. Their
current potentials towards claims-based identity management are limited.
February 2012 - All rights reserved 20

21. Answers – Delivering IAM
Authorization Management
▶ OAuth 2.0 introduces a system component called authorization server:
– This component encapsulates the authorization management for OAuth
– It has following interactions with resource owners (end users represented by
Web browsers as user agents), OAuth intermediaries (composite applications),
and OAuth resource servers:
• Resource owners: user authentication, delegation of access rights
• OAuth intermediaries: system authentication, acquisition of tokens resp.
token credentials
• OAuth resource servers: system authentication, validation of access tokens
or supply of keying information to facilitate validation by resource servers
(subject to type of access token – MAC vs. Bearer)
▶ OAuth authorization servers are candidates for an implementation according the
REST style:
– This component needs to serve accesses from Web browsers in parallel to
accesses from other clients (OAuth intermediaries and resource servers)
– It emerges from a REST-aware environment
February 2012 - All rights reserved 21

22. Conclusions
IAM for REST
▶ Delivering IAM to enable RESTful Web services needs to differentiate according
the caller types:
– Web browsers: to a large extent IAM for RESTful Web services resembles that
for classical Web applications with some REST style-imposed constraints on
achieving SSO
– Other content-aware clients: new requirements dominate as
• Additional media types (e.g. JSON, XML) in HTTP requests need to be
handled beyond the classical URL query and HTML form parameters
• For unattended clients (e.g. composite applications) it is difficult to
impossible to use techniques that depend on user attention or interaction
▶ RESTful Web services have a completely different IAM fingerprint than SOAP-
based Web services. This is due to the absence of the SOAP-based IAM and
security mechanisms.
▶ Their IAM fingerprint is closer to that of classical Web applications. But the
advent of new caller types and media types requires new mechanisms to address
topics such as API authentication and authorization.
– OAuth is an example for a new IAM mechanism that addresses IAM for
RESTful Web services (according a specific use case)
February 2012 - All rights reserved 22

23. Conclusions
REST for IAM
▶ Supplying IAM services via REST (e.g. user data, authentication, authorization or
policy services) is pretty straight-forward since it is simple to RESTify an already
existing functionality or create it from scratch.
▶ Challenges are on the side of:
– How to establish clients for RESTful IAM services and make it convenient for
(other) services or their consumers to integrate it?
– How to establish security for RESTful IAM services?
▶ Current state of using RESTful Web services for delivering IAM functionality:
– Things already underway:
• RESTful user provisioning (SCIM)
– Not (yet) underway (on the level of standardization initiatives):
• RESTful claims-based identity management
• RESTful authorization management
February 2012 - All rights reserved 23

24. References
▶ Fielding, R.: Architectural Styles and the Design of Network-based Software
Architectures. PhD Thesis. University of California, Irvine. 2000
▶ Hadley, M.; Sandoz, P. (eds): JAX-RS: Java API for RESTful Web Services. JSR-
311, Java Community Process. 2008
▶ N.N.: Jersey. JAX-RS reference implementation
▶ Pautasso, C.; Zimmermann, O.; Leymann, F.: RESTful Web Services vs. “Big”
Web Services: Making the Right Architectural Decision. Proc. of the 17th
International World Wide Web Conference, Bejing. 2008
▶ Pautasso, C.: REST-Inspired SOA Design Patterns (and Anti-Patterns). 2nd
International SOA Symposium, Rotterdam. 2009
February 2012 - All rights reserved 24

25. Author
▶ Oliver Pfaff
oliver.frank.pfaff@gmail.com
February 2012 - All rights reserved 25