Contract No.: 285248 Strategic Objective


Identity Management Generic Enabler API Specification



Download 1.78 Mb.
Page18/54
Date28.01.2017
Size1.78 Mb.
#8871
1   ...   14   15   16   17   18   19   20   21   ...   54

12Identity Management Generic Enabler API Specification

12.1Introduction to the Identity Management GE (IdM GE) API


Please check the FI-WARE Open Specifications Legal Notice to understand the rights to use FI-WARE Open Specifications.

12.1.1IdM GE API Core


IdM GE API specifications comply with existing standards for authentication and user and provile access information. The following sections provide pointers to those standards and elaborate which parts of them are considered mandatory vs optional and, when applicable, details about how the RESTful binding work.

12.1.2Intended Audience


This specification is intended for Service Consumers (with development skills) and Cloud Providers. For the former, this document provides a full specification of how to interoperate with the Identity Management Service API. For the latter, this specification indicates the interface to be provided to the client application developers to provide the described functionalities. To use this information, the reader should first have a general understanding of the Generic Enabler service

(FIWARE.ArchitectureDescription.Identity_Management_Generic_Enabler)

The API user should be familiar with:


  • RESTful web services

  • HTTP/1.1

  • JSON and/or XML data serialization formats.

  • SOAP 1.2

  • SAML 2.0

  • SCIM 2.0

  • OAuth 2.0

  • OpenID

12.1.3API Change History


Current version is: Version 2.0.0, 2013.10.18.

The most recent changes are described in the table below:



Revision Date

Changes Summary

2012.04.30

2013.10.18

  • Revision and enhancement reflecting actual development


12.1.4How to Read this Document


The following list summarizes special notations for the current and future versions of this document.

  • A bold, mono-spaced font is used to represent code or logical entities, e.g., HTTP method (GET, PUT, POST, DELETE).

  • An italic font is used to represent document titles or some other kind of special text, e.g. URI.

  • The variables are represented between brackets, e.g. {id} and in italic font. When the reader find it, can change it by any value.

12.1.5Additional Resources


Detailed specification and descriptions can be found here:

  • SAML

  • http://code.google.com/intl/de-DE/googleapps/domain/sso/saml_reference_implementation.html

  • http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security#samlv20

  • OAuth

  • http://oauth.net

  • http://en.wikipedia.org/wiki/OAuth

  • OpenID

  • http://openid.net/specs/openid-authentication-2_0.html current version

  • http://openid.net/connect/ next version based on oauth2

  • SCIM

  • Core schema

  • REST API

  • Some eExamples are provided in:

A detailed description of what parts of the used standards is considered as optional or mandatory is described in the Open Specification.


12.2General Identity Management Generic Enabler API Information

12.2.1Resources Summary


Although the access URLs for all these GEs are distinct for every instance, they follow some scheme. This is as follows:

  • One-IDM: the endpoint URLs for SAML requests are:

/IDM/SamlSsoAaServlet (http POST or GET for SAML authorisation request)

/IDM/services/AttributeAuthorityService (http POST for SAML attribute request)

  • DigitalSelf: the OAuth endpoints are:

/server/oauth2/authorize (http POST for OAuth authorisation requests)

/server/oauth2/token (http POST for OAuth token requests)

  • CGP: the full URLs to the Deutsche Telekom IdM will be provided when a tenant is booked.


  • The full description of the API is provided in the following document: GCP API Open Specifications.

  • KeyRock: there is an instance deployed at FI-LAB

12.2.2Authentication


At service side one of the herein specified authentication protocols (SAML, OAuth, OpenID) must be implemented.

12.2.3Representation Format


In case of SAML always XML is used, whereas for OAuth no body is defined.

In case of the OpenID Authentication the attributs are formatted as JSON string.


12.2.4Representation Transport


Resource representation is transmitted between client and server by using HTTP 1.1 protocol, as defined by IETF RFC-2616. Each time an HTTP request contains payload, a Content-Type header shall be used to specify the MIME type of wrapped representation. In addition, both client and server may use as many HTTP headers as they consider necessary.

12.2.5Resource Identification


The resources are uniquely identified by their URI.

12.2.6Limits


Resources are only limited by hardware resources.

12.2.7Extensions


The SAML protocol supports extensions, however this is not supported at the moment. Maybe this will be considered in the future.

Verb

URI

Description

GET

/extensions

List of all available extensions

12.2.8Faults

Synchronous Faults


  • SAML2.0:

SAML always returns a SAML response containing the field "Status" defined in the SAML specification:



Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>



In case of an error, the status code will be "Error" instead of "Success" and a detailed error message may be contained within the status block.



  • OAuth2.0:

Response Code

Description

HTTP 400

Bad Request

HTTP 401

Unauthorized

HTTP 403

Forbidden

HTTP 500

Internal Error

HTTP 501

Unsupported HTTP Method



  • OpenID:

Response Code

Description

HTTP 200

successful

HTTP 400

fault with requestmethod

HTTP 404

resource not found



  • SCIM2.0:

SCIM will respond with standard HTTP error messages identical to the OAuth2.0 case above



Download 1.78 Mb.

Share with your friends:
1   ...   14   15   16   17   18   19   20   21   ...   54




The database is protected by copyright ©ininet.org 2024
send message

    Main page