Does REST Change the Game for IAM?

Does REST Change theGame For IAM?Oliver PfaffFebruary 29, 2012

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

FundamentalsCharacterizing 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 – XSDFebruary 2012 - All rights reserved 4

FundamentalsVs. 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 – XSDPOST: request-response HTTPGET: soap-response headerFebruary 2012 - All rights reserved 5

FundamentalsVs. 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 headerFebruary 2012 - All rights reserved 6

FundamentalsRelevance 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 styleFebruary 2012 - All rights reserved 7

ObservationsContent 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

ObservationsReferring 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

Answers – Employing IAMIAM 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 enforcementFebruary 2012 - All rights reserved 10

Answers – Employing IAMInitial 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

Answers – Employing IAMInitial 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

Answers – Employing IAMFederated 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

Answers – Employing IAMSingle-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

Answers – Employing IAMAuthorization▶ 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

Answers – Delivering IAMRESTful 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 makingFebruary 2012 - All rights reserved 16

Answers – Delivering IAMUser 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 styleFebruary 2012 - All rights reserved 17

Answers – Delivering IAMLogin 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

Answers – Delivering IAMIdentity 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.pdfFebruary 2012 - All rights reserved 19

Answers – Delivering IAMClaims-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

Answers – Delivering IAMAuthorization 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 environmentFebruary 2012 - All rights reserved 21

ConclusionsIAM 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

ConclusionsREST 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 managementFebruary 2012 - All rights reserved 23

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. 2009February 2012 - All rights reserved 24

Does REST Change the Game for IAM?

by Oliver Pfaff

Accessibility

Categories

Upload Details

Usage Rights

Statistics