You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

CIFER API Framework vis-a-vis SCIM API and SCIM Schema

CIFER Framework

4. Authentication and Authorization

The framework does not specify authentication or authentication methods. Some acceptable methods include:
    1. Basic auth over https
    2. Client certificate auth over https
    3. Encrypted and signed content over any transport

SCIM API

2. Authentication and Authorization

The SCIM protocol does not define a scheme for authentication and authorization therefore implementers are free to choose mechanisms appropriate to their use cases. The choice of authentication mechanism will impact interoperability. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication/authorization schemes. In particular, OAuth2[RFC6750] is RECOMMENDED. Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken. Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using the 401 response code in accordance with section 10.4.2 of Section 10.4.2 [RFC2616].

All examples assume OAuth2 bearer token [RFC6750]; e.g.,

GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: example.com
Authorization: Bearer h480djs93hd8

The context of the request (i.e. the user for whom data is being requested) MUST be inferred by service providers.

CIFER Framework

5.1.1. URI syntax

A major version of a particular CIFER API must be indicated in the URI path (for example, "/v2/"). A major version will differentiate incompatible representations, parameters or headers. A major version change is also indicated by a change in field type. Any minor version will be indicated in the response metadata not in the URI path (see response section below).


SCIM API

3.11.  API Versioning

   The Base URL MAY be appended with a version identifier as a separate
   segment in the URL path.  At this time the only valid identifier is
   'v1'.  If specified, the version identifier MUST appear in the URL
   path immediately preceding the resource endpoint and conform to the
   following scheme: the character 'v' followed by the desired SCIM
   version number; e.g., a version 'v1' User request is specified as /v2
   /Users.  When specified service providers MUST perform the operation
   using the desired version or reject the request.  When omitted
   service providers SHOULD perform the operation using the most recent
   API supported by the service provider.


CIFER Framework

5.1.2. Request/response grammar

1. Default representation language is Javascript Object Notation (JSON).
2. XML can be requested, but support is not required.


SCIM API

3. API

All requests to the service provider are made via Section 9 [RFC2616] on a URL derived from the Base URL.  Responses are returned in the body of the HTTP response, formatted as JSON.  Response and error codes SHOULD be transmitted via the HTTP status code of the response (if possible), and SHOULD also be specified in the body of the response.

  • No labels