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:
-
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
-
http://oauth.net
-
http://en.wikipedia.org/wiki/OAuth
-
http://openid.net/specs/openid-authentication-2_0.html current version
-
http://openid.net/connect/ next version based on oauth2
-
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
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.
Response Code
|
Description
|
HTTP 400
|
Bad Request
|
HTTP 401
|
Unauthorized
|
HTTP 403
|
Forbidden
|
HTTP 500
|
Internal Error
|
HTTP 501
|
Unsupported HTTP Method
|
Response Code
|
Description
|
HTTP 200
|
successful
|
HTTP 400
|
fault with requestmethod
|
HTTP 404
|
resource not found
|
SCIM will respond with standard HTTP error messages identical to the OAuth2.0 case above
|
Share with your friends: |