Project at a glance

SEMIRAMIS - Secure Management of Information across multiple Stakeholders

 

Project number: 250453

Selected under theme: CIP-ICT-PSP.2009.7.1 / CIP-Pilot Actions

 

Start date: 01/03/2010

Duration:    30 months

Partners:

Atos (Coordinator)

Stuttgart University

Murcia University

Engineering Ingegneria Informatica

European Organisation for Security (EOS)

Portugal Telecom

Ceuti City Council

Lecce City Council

Polska Telefonia

PDF Print E-mail

technical-info2

 

Description of the Technical Elements of the SEMIRAMIS Architecture

The Overall Picture

SEMIRAMIS has designed and developed an infrastructure, which is able (a) to bridge between heterogeneous identity federations, (b) to aggregate personal data from various storages across Europe, (c) to simplify significantly the user interaction within several processes, and, finally, (d) to support security and privacy at a very high level. However, in order to achieve all desired goals, the current approach of identity federations has been broken up and new components have been introduced: Instead of the common three entities (User, Identity Provider, Service Provider), the SEMIRAMIS infrastructure consists of six elements, the User, the Service Provider, the Authentication Provider, the Attribute Provider, the Identity Aggregator and the Federation Proxy.

The User

The User is being seen as a person who wishes to access a service offered by one or more Service Providers. In order to use these services, he has to provide pieces of his private data, which are stored at one or more Attribute Providers throughout Europe. In addition, he has one or more accounts that he can use to log in at the Authentication Providers. Within SEMIRAMIS, it is assumed that the User uses a web browser to access the service as well as the intermediate supporting components such as Identity Aggregator, Authentication Provider, Attribute Provider, etc., via HTTP/HTTPS.

Service Provider

The Service Provider offers services, which may require personal data, to Users. Instead of getting this data directly from the Users, Service Providers may also contract the Users’ Identity Aggregators in order to let them aggregate the pieces of data stored at different places throughout Europe. Although the definition of the set-up and maintenance of Service Provider components is not within the scope of SEMIRAMIS, it is assumed that the services are web based in order to allow Users access via HTTP/HTTPS and that the request for authentication and attributes is carried out by using SAML.

Authentication Provider

The Authentication Provider is in charge of authenticating the User. Usually, it receives authentication requests that are directed from a Service Provider via Identity Aggregators and possibly also via Federation Proxies to it. However, the technical solution for implementing Authentication Providers is being chosen by the Authentication Provider’s technical manager itself and is, therefore, out of scope of SEMIRAMIS. However, this component has to support SAML in order to receive authentication requests and to generate and send SAML Authentication Assertions, which are assumed to be the answer to an authentication request.

Attribute Provider

The Attribute Provider hosts (parts of) the User’s digital identity. Similar to the Authentication Provider, it receives requests from a Service Provider via the SEMIRAMIS infrastructure including Identity Aggregators and Federation Proxies. Instead of an authentication request, the Attribute Provider receives an attribute request, retrieves the requested User’s attributes from the accordant storage, generates a SAML Attribute Assertion and sends it back to the requestor. Much of the design of Attribute Providers is left to the decision of the managers, but an Attribute Provider should be able (1) to offer the User an interface to define attribute release policies, which may include the settings ’release always‘, ’release to defined service providers‘, ’request approval‘, and ’release never‘, (2) to provide the User the ability to approve the release of attributes whilst executing the attribute request (e.g., based on a web frontend), and (3) to support SAML in order to generate and send SAML Attribute Assertions.

Identity Aggregator

The Identity Aggregator is able to retrieve parts of the User’s digital identity from several sources, such as different Authentication and Attribute Providers. In order to carry out this service, it has to be equipped with several functionalities, as seen on the figure to the right. The two major functions are the Attribute Translator, which is able to translate attributes from one language into another, and the Policy Module, which defines how to treat requests and assertions being received. The Identity Aggregator obtains the directions for forwarding the received messages either from configuration files or from User interaction, e.g., by displaying a web frontend asking for the location of the User’s attributes. The Identity Aggregator has to support SAML, since it receives, analyses, generates, and sends SAML Assertions.

Federation Proxy

The Federation Proxy is located at the borders of each federation. It is set up in order to bridge between connected federations, since they may have different languages, different attribute types, different values, or different levels of security. Thus, whenever a message shall be sent from one federation to another, the Federation Proxy in between checks origin and destination and decides, based on its configuration, if a translation is necessary, if a protocol change must be carried out, and even if the message is allowed to reach its destination. Therefore, it has to support SAML, since it receives, analyses, generates, and sends SAML Assertions. 

 

 
Joomla Templates by Joomlashack