identity 1.0 documentation

Simple Cloud Identity Management: Protocol 1.0 (REST API 1.0)

«  Web Services Security SAML Token Profile Version 1.1.1   ::   Contents   ::   Active Directory & Connect  »

Simple Cloud Identity Management: Protocol 1.0 (REST API 1.0)

http://www.simplecloud.info/specs/draft-scim-api-00.html

Abstract

The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier.

The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models.

It’s intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols.

In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud.

(draft 1 )

1. Introduction and Overview

The SCIM Protocol is an application-level, REST protocol for provisioning and managing identity data on the web. The protocol supports creation, modification, retrieval, and discovery of core identity Resources; i.e., Users and Groups, as well as custom Resource extensions.

Note

  • REST Protocol

  • Identity Provisioning

    • create identity
  • Ideneity Management

    • modify identity
    • retrive identity
    • discover identity
  • Identity information

    • Users
    • Groups
    • Custom Resource

(draft 1 )

1.1. Intended Audience

This document is intended as a guide to SCIM API usage for both identity Service Providers and Consumers.

Note

  • For

    • Identity Service Providers
    • Service Consumers

(draft 1)

1.2. Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119]. These keywords are capitalized when used to unambiguously specify requirements of the protocol or application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.

For purposes of readability examples are not URL encoded. Implementers MUST percent encode URLs as described in RFC3896 2.1.

(draft 1)

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 Bearer Token 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 RFC2616.

All examples assume OAuth2 bearer token; 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.

(draft 01 )

Note

  • SCIM REST = Authorization-protected Identity API sets, which require OAuth2 Bearer Tokens.

«  Web Services Security SAML Token Profile Version 1.1.1   ::   Contents   ::   Active Directory & Connect  »