We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Security.IdentityManagement R3 - FIWARE Forge Wiki

FIWARE.OpenSpecification.Security.IdentityManagement R3

From FIWARE Forge Wiki

Jump to: navigation, search

THIS CONTENT IS OBSOLETE, GO TO FIWARE.ArchitectureDescription.Security.IdentityManagement FOR THE NEW VERSION.

Name FIWARE.OpenSpecification.Security.IdentityManagement
Chapter Security,
Catalogue-Link to Implementation Identity Management
Owner UPM, Alvaro Alonso

Contents

Preface

Within this document you will find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE_Product_Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE project.

Copyright

  • Copyright © 2012-2014 by NSN. All Rights Reserved.
  • Copyright © 2012-2014 by DT. All Rights Reserved.
  • Copyright © 2012-2015 by UPM. All Rights Reserved.

Legal Notice

Please check the following Notice understand the rights to use these specifications.

Overview

On the one hand the ever-growing tsunami of today’s shore-bound technologies can often overwhelm the user, significantly affecting his daily life. On a daily basis, he is forced to depend on his technological competence. The smooth running of his affairs depends on user’s ability to handle a whole raft of often transient technologies. On account of very intensive, at times forced usage of the Internet and diverse services, the user encounters the need to transfer his “network-duties” to the networks as much as possible.

In other words, he seeks to find a convenient problem solver, which will allow him to cope easily and securely with services. Thus, the need arises for a clever composed Identity Management system, which will address the users’ requirements. An Identity Management system is intended to undertake the complex task of handling, communicating with and coordinating between the slew of today’s diverse technologies. Provide user-friendly technologies, putting the end user and his needs squarely at centre of the architecture (user-centric approach) whilst protecting the users’ privacy.

On the other hand the computing resources are being actively exploited by the Enterprises lately through the use of cloudification and virtualisation technologies. Nevertheless, with regard to such an evolution on the Web, the Enterprises still have to keep in mind the Identity Management issues and should be able to deliver such technologies to their customers. Thus, the Identity Management Enabler could also deliver a multi-tenant user and profile management solution that allows Enterprises to manage consumers of their (Web based) services in the Cloud securely. Instead of developing and operating the user and profile management by themselves, it can be hosted in the Cloud as a tenant instance and will be delivered on demand.

Target usage

Identity Management (IdM) encompasses a number of aspects involved with users' access to networks, services and applications, including secure and private authentication from users to devices, networks and services, Authorisation & Trust management, User Profile management, Single Sign-On (SSO) to service domains and Identity Federation towards applications.

Basic Concepts

Relevant Concepts and Ideas

Identity Management encompasses a number of aspects involved with users' access to networks, services and applications, including secure and private authentication from users to devices, networks and services, Authorisation & Trust management, User Profile management, Single Sign-On (SSO) to service domains and Identity Federation towards applications. The Identity Manager is the central component that provides a bridge between IdM systems at connectivity-level and application-level.

Furthermore, Identity Management is used for authorising foreign services to access personal data stored in a secure environment. Hereby usually the owner of the data must give consent to access the data; the consent-giving procedure also implies certain user authentication.

Identity Management is used in multiple scenarios spanning from Operator oriented scenarios towards Internet Service Providers (ISP). End users benefit from having simplified and easy access to services (User Centric Identity Management).

User Life-Cycle Management

The IdM offers tools for administrators to support the handling of user life-cycle functions. It reduces the effort for account creation and management, as it supports the enforcement of policies and procedures for user registration, user profile management and the modification of user accounts. Administrators can quickly configure customized pages for the inclusion of different authentication providers, registration of tenant applications with access to user profile data and the handling of error notifications. For end users, the IdM provides a convenient solution for registering with applications since it gives them a means to re-use attributes like address, email or others, thus allowing an easy and convenient management of profile information. Users and administrators can rely on standardised solutions to allow user self-service features like:

  • User registration and login resp. logout,
  • Checks for password strength,
  • Password reset or renewal procedures or
  • Secured storage of user data.

Flexible Authentication for End Users

In addition to providing a native login, the IdM supports the integration of multiple 3rd party authentication providers. Foremost, it supports in a first step the configuration of preferred identity providers through the administrators. The use of 3rd party IdMs lowers the entry barriers for a native user to register, since the user can link to his preferred IdM and use this account for authentication.

3rd Party Login to Services

3rd party login supports customers of the IdM to enhance the reach of their websites by means of attracting users without forcing them to register new user accounts on their sites manually. 3rd party login allows users to register to the customers’ sites with already existing digital identities from their favourite 3rd party identity providers, such as Google, Facebook or Yahoo. Thus, 3rd party login lowers the obstacles of registration processes and increases the number of successful business flows on the customers’ sites.

Web Single Sign-On

As it is possible to configure several applications that shall be linked to his IdM, the main benefit for users is a single sign-on (SSO) to all these applications.

Hosted User Profile Management

The IdM offers hosted user profile storage with specific user profile attributes. Applications do not have to run and manage their own persistent user data storages, but instead, can use the IdM user profile storage as a Software as a Service (SaaS) offering.

Multi-Tenancy

A multi-tenancy architecture refers to a principle in software architecture where a single software instance runs on a server, serving multiple client organisations/customers (tenants). Multi-tenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organisations. With a multi-tenant architecture, a software application is designed to virtually partition its data and configuration, and each client organisation works with a customized virtual application instance. In a multi-tenancy environment, multiple customers share the same application, running on the same operating system, on the same virtualized hardware, with the same data storage mechanism. The distinction between the customers is achieved during application design, thus customers do not share or see each other's data. The concept allows each tenant to apply their own branding to login or registration UIs or for user self-services to create a user experience that is aligned with the one offered in a tenant application.

Example Scenarios

General roles and responsibilities

This section introduces the general architectural roles and responsibilities underlying the integration between the IdM-System on the one hand side and services as well as product management and product presentation on the other hand.

Generally, three responsibilities can be identified:

  • The IdM-System is responsible for identity management processes such as login, logout, registration and the like and for customer management processes such as customer data management.
  • A service provider is responsible for any process that has to do with service provisioning to users. This responsibility encompasses things like evaluating the users entitlements based on authorisation data as provided by the IdM-System, serving the services which the user is entitled to use, and providing UIs and service-related information and processes to the user. The service provider, sharing a certain service level agreement with the IdM provider, is realizing the service sold to the customer of the partner.
  • A product provider is responsible for any process to do with defining and offering sellable products to the partners’ customer. Typically, the product provider runs a storefront such as a web-store or a landing page presenting the available (subscription) products to the potential customers. The product provider will typically be the IdM-System partner, and is also responsible for all customer communication as well as for all legal aspects of the customer relation.

Integration scenarios: Simple scenario with a single storefront

In the simplest scenario, the product provider offers a single “storefront” where he sells products to B2C customers; the storefront is a web store.

Apart from the storefront where the customer can browse and buy products, the customer can consume the service using another web-site, namely the “player”. The player is presented by the service-provider, which may or may not be the partner himself.

In this simple scenario, the partner also uses the IdM-Systems customer self care component to allow the customers to manage their customer- and account-data as well as their subscriptions / contracts.

The storefront

The storefront is a website which is available for authenticated and non-authenticated users. Generically, the storefront may look as in the following sketch:

The storefront is to be provided by the product provider and displays the commercial offers. In the present design, the product details are displayed after clicking on the corresponding links on the cover flow.

When the user has authenticated and is logged in (see below for corresponding wireframes) the storefront may present a more personalized user experience as in the following wireframe:


In this design, the authenticated user can access his personal settings via the drop-down menu on the top right hand side:

It is of course up to the product provider how he wants to model the user interface for the storefront.

In terms of the technical integration between the IdM-System and the storefront website, the following interactions take place during login:

  • When the user wants to log in to the storefront, he is forwarded to the IdM-SYSTEM using an IdM protocol flow. Generically, for web interactions the SAML flow is suggested.
  • The IdM-System will present a login-page to the user. Depending on the configuration, the login-page allows the user to log in with IdM-System credentials or using 3rd party accounts such as provided by Facebook, Google or others. Also, the login-page may allow the potential user to register himself (create a new account).
  • After a successful login, the IdM-System forwards the web-browser of the user to a return-to-URL. Information on the user and his customer- and authorisation-attributes as generated on registration is transferred to the storefront via the used IdM-protocol, which is used during login. Based on this information, the storefront may personalize the information presented to the user as in the example above.
The player: Product consumption

The player is a website which allows consumption of the digital products offered on the storefront. The player may contain offerings to both authenticated and non-authenticated users. Generically, the player may look as in the following sketches, once for a non-authenticated and once for an authenticated user:

In terms of the technical integration between the IdM-System and the player website, the following interactions take place during login:

  • When the user wants to log in to the player, he is forwarded to the IdM-System using an IdM-protocol flow. Generically, for web interactions the SAML-flow is suggested. For the IdM-System to recognize the player as the requestor of the authentication, the call to the IdM-System needs to include the necessary information of the IdM-protocol as configured in the IdM-System.
  • The IdM-System will present a login-page to the user. Depending on the configuration, the login-page allows the user to log in with IdM-System credentials or using 3rd party accounts such as provided by facebook, Google or others.
  • After a successful login, the IdM-System forwards the web-browser of the user to a return-to-URL. Information on the user and his customer- and authorisation-attributes as generated on registration is transferred to the player via the used IdM-protocol. The player will have to decide on the basis of authorisation attributes as provided by the IdM-System, which contents the authenticated user is entitled to consume.

Main Interactions

Architecture

Identity Generic Enabler - High Level Architecture

Modules and Interfaces

The Identity Management System consists of the following building blocks:

- IdM Portal

Providing the interface to the user / application. The functionality includes user profile management and modification of user accounts (e.g. password settings and/or secured storage of user data). The portal is a separate element which most systems based on an IdM GEi will provide. It will be designed to individual needs and therefore not not part of the IdM GE specification.

- IdM API

You will find links to the REST API of the GEri in FIWARE catalogue. It support standardised security protocols, as there are SAML 2.0, OAuth 2.0, and SCIM 2.0.

- IdM system

The core component handling the authentication requests of the users, by providing e.g. federated IdM for Web-SSO or basic authentication features for devices and services.

- Authentication framework

The authentication framework consists of the Extractor and the Authentication Pipeline. The Extractor extracts the authentication data from different sources. Each one of them is specialized in extracting a special kind of data. The data will be collected and then handed to the authentication pipeline in order to select the correct authentication. Following authentication methods are supported:

- SAML stack
Security Assertion Markup Language is an XML-based standard for exchanging authentication and authorisation data between security domains
- OAuth2 stack
Open Authorisation Protocol is an open standard for authorisation.
- User name / password
As well basic authentication mechanisms like user name / password are provided.

- Database

It is a central repository that stores the user data, profiles and preferences, as well as the service provider preferences. This could be implemented as a distributed storage system, depending on the usage scenario.


Identity Generic Enabler - Core Components

Beyond that, there may be some additional and necessary network security components in place (e.g. Firewall, router, etc.). Next to that a Public Key Infrastructure (PKI) would be necessary to enable signatures (e.g. for SAML or https).

Interface Descriptions

The IdM GE offers a number of well-defined interfaces, including interfaces that provide support to different authentication mechanisms. In the following, the several interfaces that a FIWARE compliant IdM GE may offer are described with the help of message flows and reference code examples.

Overview on provided standardised interfaces

This section provides an overview of the Identity Management Generic Enabler (IdM GE) components. We also define minimally required and optional components and supported API standards for GE implementations. The general structure of a FIWARE IdM GE is sketched in the following figure:

FIWARE IdM GE - Overall Structure

An IdM GE offers configuration and maintenance functionalities for FIWARE Operators. This may be offered as a GUI, configuration files, standards based API (e.g. JMX [1]) or any combination of these. Third party application developers may register their applications with the IdM GE using these functionalities. This registration process must be implemented through a Web user interface called Application Developer Portal. The registration should include operator review and approval. End users register to FIWARE using the End User Portal. This is also implemented as a Web user interface. End users may also review and modify their personal data and maintain their privacy settings using this portal. The access to the End User Portal should be controlled by the FIWARE Authorization PDP GE. Other FIWARE components may access the IdM GE through Core APIs.

This component must support OAuth 2.0 [2] for authorisation. At least the authorization code grant (4.1) and resource owner password credentials grant (4.3) flows must be supported. Optionally implicit grant (4.2) may also be supported. IDM GE implementations should also allow configuring trusted FIWARE components to access protected resources using (4.4) client credentials grant. For access token formats at least bearer tokens [3] must be supported. Access control decisions are made by access control policies residing in the Authorization PDP GE. Policies may require additional information from the IDM GE to make the decision, including, but not limited to token parameters and status, user groups/roles, client settings, user privacy preferences. These may be retrieved from the IDM GE using the Access information API. Optionally IDM GE may provide an API for user and role management. If such an API is provided then it should be compliant with SCIM 2.0 [4]. Only mandatory SCIM operations and features must be supported (there are very few optional features).

SAML

The IdM GE makes use of SAML 2.0 in the following two cases:

- Authenticating federated relying parties,

- Authenticating the users on behalf of the federated relying parties (in a second step,to inform them that these Users are authorised to access their services)


The advantages of SAML 2.0

  • Provides a means of exchanging data between security domains (i.e. the IdM GE and its federated service providers (relying parties))
  • Provides the SSO feature for the federated service providers to the Users
  • Service providers do not need to authenticate users themselves
  • Provides security features such as digital signatures to certify the integrity of the exchanged data (and certified attributes)
  • Standardised, non-proprietary protocol (e.g. also supported by Google)

The following diagrams illustrate the main SAML message flows. In the case of FIWARE the User will be the browser, the Relying Party will be the FIWARE GE using SAML and the SAML IdM will be the IdM GE provided by FIWARE.

Identity Generic Enabler - SAML Authentication Flow

Authentication Request

<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="aaf23196-1773-2113-474a-fe114412ab72"
  Version="2.0"
  IssueInstant="2004-12-05T09:21:59Z"
  AssertionConsumerServiceIndex="0"
  AttributeConsumingServiceIndex="0">
  <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
  <samlp:NameIDPolicy
    AllowCreate="true"
    Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>

Authentication Response

  <samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_2"
InResponseTo="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z"
    Destination="https://sp.example.com/SAML2/SSO/POST">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_3"
      Version="2.0"
      IssueInstant="2004-12-05T09:22:05Z">
      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
      <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
      <saml:Subject>
        <saml:NameID
          Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
          3f7b3dcf-1674-4ecd-92c8-1544f346baf8
        </saml:NameID>
        <saml:SubjectConfirmation
          Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
          <saml:SubjectConfirmationData
            InResponseTo="identifier_1"
            Recipient="https://sp.example.com/SAML2/SSO/POST"
            NotOnOrAfter="2004-12-05T09:27:05Z"/>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions
        NotBefore="2004-12-05T09:17:05Z"
        NotOnOrAfter="2004-12-05T09:27:05Z">
        <saml:AudienceRestriction>
          <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
        </saml:AudienceRestriction>
      </saml:Conditions>
      <saml:AuthnStatement
        AuthnInstant="2004-12-05T09:22:00Z"
        SessionIndex="identifier_3">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
         </saml:AuthnContextClassRef>
        </saml:AuthnContext>
      </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>

OAuth2

OAuth's main focus is on "protected resources" of the user that a consumer wishes to access. A protected resource can be anything from an attribute to a service API.

The advantages of OAuth 2.0:

  • A standardized protocol supported by a wider set of Service Providers (Facebook, Google, LinkedIn, etc.).
  • Differentiates temporary and permanent grants. When the user grants access for a consumer to a specific resource, the consumer receives an access token and optionally a refresh token. With the access token, the consumer can use the resource for a short period only. If a refresh token is also granted, then the consumer may request a new access token at any time, so the user is not needed to be online to authorise access when the consumer uses the resource.
  • The user is in full control of who can access his resources, servers should support listing, revoking and editing grants.
  • Consumers can be easily implemented, they can vary from complex web applications to a few lines of Javascript code running in a browser. (Note that the latter also uses a slightly simplified scenario without an authorisation code.)
  • The specification leaves most details to the implementation, defines only the most necessary parts. Consequently, it is possible to customise the scenarios to ones needs and environment, so despite it's quite new it's widely supported.
Identity Generic Enabler - OAuth 2.0 Authentication Flow

Get Authentication Code Request

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

Get Authentication Code Response

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz

Get Access Token Request

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Get Access Token Response

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
}

Refresh Access Token Request

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Refresh Access Token Response

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":3600,
}


Username / Password

A user can be identified by providing a <user name> and a <password>, which will be verified against the database. They are sent using HTTP POST from the browser to the server. In case the credentials are correct the client is redirected back to the requested service; else the response is an html page containing the error message.

Although username and password may be used in a SAML-based authentication, it is mentioned here as specific direct authentication method, even if no SSO is used.

Access information API

Access information API is used by the integration of the IDM GE and the Authorization PDP GE. It provides option for the Authorization PDP to retrieve additional information required to make the access control decision. The information retrieved may depend on the concrete use case and/or policy, therefore only general guidelines are given for this API. The API should be RESTful and should return the requested information in JSON format. In case the returned information includes user data or other resource defined by the SCIM 2.0 schema, the information should be returned in SCIM compliant format. An example request/response used in a concrete use case is shown below.

  • Token Information Request
GET /tokeninfo/1?access_token=7c3dcd81-a71d-404d-baf7-e8f8363ffa22 HTTP/1.1 Host: server.example.com
  • Token Information Response
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache
{
    "id":"7c3dcd81-a71d-404d-baf7-e8f8363ffa22",
    "type":"bearer",
    "scope":[
       "address",
       "email",
       "openid",
       "phone",
       "profile",
       "scim_admin",
       "scim_reader"
    ],
    "purpose":"access_token",
    "grantType":"authorization_code",
    "protocol":"oauth2",
    "validUntil":"2013-09-24T11:03:44.360+0200",
    "validFrom":"2013-09-24T10:03:44.450+0200",
    "user":{
       "id":"10000297",
       "meta":{
          "created":"2013-09-13T15:24:44.000+0200"
       },
       "schemas":[
          "urn:scim:schemas:core:2.0:User",
          "urn:scim:schemas:extension:enterprise:2.0:User"
       ],
       "userName":"john.doe",
       "name":{
          "familyName":"ss",
          "givenName":"sss"
       },
       "displayName":"Test business client",
       "emails":[
          {
             "value":"ss",
             "primary":true
          }
       ],
       "phoneNumbers":[
          {
             "value":"sss",
             "primary":true
          }
       ],
       "addresses":[
          {
             "streetAddress":"",
             "locality":"s",
             "region":"",
             "postalCode":"",
             "country":"SH",
             "primary":true
          }
       ],
       "groups":[
          {
             "value":"user"
          }
       ],
       "urn:scim:schemas:extension:enterprise:2.0:User":{
          "organization":"10000000"
       }
    },
    "created":"2013-09-24T10:03:45.023+0200",
    "client":{
       "id":"10000471",
       "contracted_resources":[
          "sms"
       ]
    }
}

Basic Design Principles

The design of the Generic Enabler provides the following basic design principles:

  • user centricity
  • easy integration into services
  • support of the entire lifecycle of identities
  • intuitive usage and administration

Main Functionality

This enabler provides authentication/access control and identity/attribute assertions as a service to relying parties. The relying parties are typically service providers that provide easy and secure access to their services to users/IoT/other services for instance by means of SSO and that rely on (personal user) attributes (e.g. preferences, location, home address, etc.). The users need easy access (SSO) to the growing number of services, and many of them also prefer their personal/identity attributes to be maintained by a trusted party, which also protects the users’ privacy. The Identity Management core generic enabler can be used by such a trusted party, which we also call an identity provider (for SSO) and attribute broker. The Identity Management GE is a core Security GE that provides services to its relying parties via open protocols such as OAuth [OAuth] and OASIS SAML v2.0 [SAML]. Motivated by the IoT, the enabler also covers new user attributes such as things, as well as it manages the identity of things themselves (attributes, current users, location, use history, etc.). The large number of sensors and mobile devices poses new challenges; identity federation and single-sign-on support ease of use. The authentication feature of the enabler also covers authentication of things to services, objects, and users and vice-versa.

It also supports user SSO across multiple things. Motivated by Cloud computing, the enabler can be run in the cloud as well. Special care is taken by the architecture and the supported protocols so that the sensitive data is not exposed to the threats related to the nature of clouds (e.g. deployment in a public cloud).

Resolution of Technical Issues

Currently there are no known technical issues. In case the user of the Generic Enabler experiences a technical issue please contact the provider of the GE.

Detailed Specifications

Open Specification

IdM GE open specifications rely on a well-known set of standard specifications. Following are the resources to easily refer to these standards:

  • SAML
  • OAuth2
  • SCIM


Open API Specification


References

[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



Re-utilised Technologies/Specifications

The Identity Management GEis are based on the following technologies:

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FIWARE level, please refer to FIWARE Global Terms and Definitions


  • Access control: is the prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner (ITU-T Recommendation X.800). More precisely, access control is the protection of resources against unauthorized access; a process by which use of resources is regulated according to a security policy and is permitted by only authorized system entities according to that policy (RFC 2828).
  • Account: A (user) account is “typically a formal business agreement for providing regular dealings and services between principal sand business service providers.” OASIS Security Assertion Markup Language (SAML).
  • Authentication (AuthN): We adopted the following definition of authentication from RFC 3588: "Authentication is “the act of verifying the identity of an entity (subject)".
TrustInCyberspace adds the term “level of confidence” to this definition:
Authentication is the process of confirming a system entity’s asserted identity with a specified, or understood, level of confidence.” This definition holds all necessary parts to examine authentication in broad sense. First of all it does not narrow the authentication to human users, but refers to a generic “system entity”. See authentication reference architecture description for a closer look at different identities that could be authenticated.
Secondly it introduces the often neglected concept of “level of confidence” which applies to each authentication of an identity. No computer program or computer user can definitely prove the identity of another party. There is no authentication method that can be secured against any possible identity-theft attack, be it physical or non-physical. It is only possible to apply one or more tests, which, if passed, have been previously declared to be sufficient to go on further. The problem is to determine which tests are sufficient, and many such are inadequate.
The original Greek word originates from the word 'authentes'='author'. This leads to the general field of claims and trust management, because authentication could also mean to verify the “author” / issuer of any claim.
The confirmation or validation process of authentication is actually done by presenting some kind of proof. This proof is normally derived from some kind of secret hold by the principal. In its simplest form the participant and the authentication authority share the same secret. More advanced concepts rely on challenge/response mechanisms, preventing the secrets to be transmitted. Refer to Authentication Technologies for a detailed list of authentication methods used today.
As stated above, each authentication method assures only some level of trust in the claimed identity, but none could be definite. Therefore it makes sense to distinguish the different authentication methods by an associated assurance level, stating the level of trust in the authentication process.
As this assurance level depends not only on the technical authentication method, but also on the overall computer system and even on the business processes within the organization (provisioning of identities and credentials), there is no ranking of the authentication methods here.
  • Authentication protocol: "Over-the-wire authentication protocols are used to exchange authentication data between the client and server application. Each authentication protocol supports one or more authentication methods. The OATH reference architecture provides for the use of existing protocols, and envisions the use of extended protocols which support new authentication methods as they are defined." (OATH)
  • Federation: The term federation “is used in two senses - "The act of establishing a relationship between two entities. An association comprising any number of service providers and identity providers.” OASIS Security Assertion Markup Language (SAML)
“A federation is a collection of realms that have established a producer-consumer relationship whereby one realm can provide authorized access to a resource it manages based on an identity, and possibly associated attributes, that are asserted in another realm.
Federation requires trust such that a relying party can make a well-informed access control decision based on the credibility of identity and attribute data that is vouched for by another realm.” WS-Federation @ IBM
Remark: Federation according to WS-Federation @ IBM is similar to the concept of a Circle of Trust.
  • Identifier: Identifiers can be understood as a dedicated, publicly known attribute of an identity that refers to that identity only. Typically, identifiers are valid within a specific domain. Special types of identifiers are valid globally, due to the use of popular domain naming and resolution protocols such as DNS, which implies addressing capabilities to the identity. OASIS Security Assertion Markup Language (SAML) defines identifier as follows:
An identifier is “a data object (for example, a string) mapped to a system entity that uniquely refers to the system entity. A system entity may have multiple distinct identifiers referring to it. An identifier is essentially a "distinguished attribute" of an entity.”
  • Identity (Digital): The term identity and its meaning have been discussed controversially in the “identity community” for many years. Until now, there is no commonly agreed definition of that notion. The IdM and AAA reference architecture applies the following three definitions of identity.
The Identity Gang defines the term digital identity as follows:
A digital identity is “a digital representation of a set of Claims made by one party about itself or another digital subject.”
The following comments were added:
A digital identity is just one set of claims about a digital subject. For any given digital subject there will typically be many digital identities.
A digital identity can be created on the fly when a particular identity transaction is desired or persistent in a data store to provide a representation that can be referenced.
A digital identity may contain claims made by multiple claimants.
A digital identity may be signed by a digital identity provider to provide assurance to a relying party.
This definition emphasizes two facts:
Normally, a principal (subject) has multiple digital identities or personas.
Identities are made out of attributes (claims).
Therefore, the scope of identity management in the reference architecture has two viewpoints: For once it focuses on identities and personas itself, and on the other side, it deals with the attributes of these identities and personas.
The Liberty Alliance Project (LAP) defines digital identity as follows:
Digital identity is “the essence of an entity. One’s identity is often described by one’s characteristics, among which may be any number of identifiers. A Principal may wield one or more identities.”
RSA uses the following definition of digital identity:
“Digital identity consists of an identity assertion and the characteristics, sometimes called attributes that are collected or observed through our computerized relationships. It is often as simple as a user name and password.”
The definition of RSA adds one important aspect to the identity discussion: Even the simplest user name and password combinations without any additional attributes or claims constitute an identity.
  • Identity context: is “the surrounding environment and circumstances that determine meaning of digital identities and the policies and protocols that govern their interactions.” (Identity Gang)
  • Identity management (IdM): comprises “the management of identity information both internally and when it is passed from one entity to another.” Open Mobile Alliance (OMA)
  • Identity provider: The Open Mobile Alliance (OMA) defines the term identity provider (IdP) as follows - An identity provider is “a special type of service provider […] that creates, maintains, and manages identity information for principals, and can provide […] assertions to other service providers within an authentication domain (or even a circle of trust).”
Another notion defines identity provider as “an agent that issues a digital identity [that] is acting on behalf of an issuing Party.” (Identity Gang)
The following definition of identity provider descends from WS-Federation @ IBM: “An identity provider is an entity that acts as an authentication service to end requestors and as data origin authentication service to service providers […]. Identity providers are trusted (logical) 3rd parties which need to be trusted both by the requestor […] and the service provider which may grant access to valuable resources and information based upon the integrity of the identity information provided by the identity provider.”
The Identity Provider is part of the Identity Management infrastructure.
  • Single sign-on: is “From a Principal’s perspective, single sign-on encompasses the capability to authenticate with some system entity—[…] an Identity Provider - and have that authentication honored by other system entities, [termed] Service Providers […]. Note that upon authenticating with an Identity Provider, the Identity Provider typically establishes and maintains some notion of local session state between itself and the Principal’s user agent. Service Providers may also maintain their own distinct local session state with a Principal’s user agent.” Liberty Alliance Project (LAP)


Personal tools
Create a book