description of eais and their requirements for...

Document name: SP4 / WP44 Page: 0 of 105

Reference: D44.1 Dissemination: PU Version: 2.0 Status: final

Description of EAIs and their

Requirements for Integration

D44.1 – Description of Enterprise Application Infrastructures

and their Requirements for Integration

Abstract: This document provides an overview of Enterprise Application Integration (EAI) solutions, the possibilities of integrating an EAI solution within the FutureID architecture, an analysis of the integration of EAI solutions into FutureID and the proposal of an abstract FutureID EAI-AIS integration architecture.

This document is issued within the frame and for the purpose of the FutureID project. This project has received funding from the

European Union’s Seventh Framework Programme (FP7/2007-2013) under Grant Agreement no. 318424.

This document and its content are the property of the FutureID Consortium. All rights relevant to this document are determined by

the applicable laws. Access to this document does not grant any right or license on the document or its contents. This document or

its contents are not to be used or treated in any manner inconsistent with the rights or interests of the FutureID Consortium or the

Partners detriment and are not to be disclosed externally without prior written consent from the FutureID Partners.

Each FutureID Partner may use this document in conformity with the FutureID Consortium Grant Agreement provisions.

Document Identification

Date 30/05/2013

Status final

Version 2.0

Related SP / WP

SP4 / WP44 Document Reference

https:/dms-prext.fraunhofer.de/livelink/livelink.exe?func=ll&objId=2876416&objAction=browse&viewType=1

Related Deliverable(s)

D21.3, D22.3, D42.3

Dissemination Level

PU

Lead Participant

ATOS Lead Author ATOS

Contributors FHG, ATOS, AG, ULD, EEMA

Reviewers SK, TUD

No

t to

be d

istr

ibute

d o

uts

ide t

he F

utu

reID

Consort

ium

Shaping the Future of Electronic Identity Description of EAIs and their Requirements for Integration



1. Executive Summary

The goal of the current document is to provide an overview of Enterprise Application Integration

solutions (EAI), the possibilities of integrating an EAI with the FutureID architecture, an analysis

of the integration of EAI into FutureID and the proposal of an abstract FutureID EAI-AIS

integration architecture.

The document shows the definition of EAI and the most important issues to know regarding EAIs

and their integration. A vision of current EAIs is presented in this report and a selection of the

market leaders is studied. The selection of the leaders has been taken from a Gartner report

[GAR-MC1] that provides the most important examples.

In this report, the integration of Federated Identity Management (fIdM) into EAI infrastructures is

studied. The application of fIdM in EAI intra-organizational and inter-organizational scenarios is

fundamental for FutureID.

Finally it described the inclusion of EAI in FutureID architecture. Starting from the previous EAI

research and trying to find the common points extracted from the study of EAI solutions, the

architecture of the component of FutureID, “Application Integration Services”, is also constructed

at a high level according to its integration into EAI solutions.

The present document is an important input for D44.3 Technical specification of interfaces,

modules and documentation for the application integration services, which will start by taking the

findings of the present document related to the outlined architecture. The application Integration

Services (AIS) enables integration of enterprise applications and EAI with FutureID

infrastructure.

The AIS capability for connecting with different fIdM protocols (such as SAML Open-ID, WebID),

contributes to the added value of FutureID for linking different sorts of systems in an Enterprise

Application Integration.

The federated identity management in FutureID provides the sharing of data and business

processes in Enterprise Application Integration and enables a business oriented approach by

providing secure, privacy-aware, and ubiquitously usable identity management.




2. Document Information

2.1 Contributors

Name Partner

Charles Bastos Rodriguez

Nuria Ituarte Aranda

ATOS

Sebastian Kurowski FHG

Jens Kubieziel AG

Marit Hansen

Meiko Jensen

ULD

Jon Shamah EEMA

2.2 History

Version Date Author Changes

0.1 14/03/2013 ATOS Initial version

0.2 08/05/2013 ATOS, EEMA, FHG,

AG, ULD

Version with

contributions for

chapters 1-8.

0.3 13/05/2013 ATOS, EEMA,

FHG, AG, ULD

Version with all the

contribution for

partner’s revision.

0.4 14/05/2013 ATOS, EEMA,

FHG, AG, ULD

Version for internal

review

1.0 30/05/2013 ATOS, EEMA Addressed internal

review comments

2.0 12/12/2013 ATOS, EEMA, FHG,

ULD

Replacement of terms

used to refer on

architecture

components




2.3 Table of Figures

Figure 1: Common Schema of EAI architecture ..................................................................................... 40 Figure 2: FutureID Architecture including EAI. ...................................................................................... 41 Figure 3: WebSphere hybrid integration model with FutureID ............................................................. 46 Figure 4: WebSphere common integration model with FutureID ......................................................... 47 Figure 5: Oracle Fusion Middleware ........................................................................................................ 50 Figure 6: Oracle solution architecture for FutureID ............................................................................... 51 Figure 7: webMethods solution architecture for FutureID ................................................................... 59 Figure 8: TIBCO architecture integration for FutureID components.................................................... 66 Figure 9: Microsoft BizTalk Solution ....................................................................................................... 71 Figure 10: Microsoft EAI solution for FutureID ...................................................................................... 75 Figure 11: Overall architecture for Netweaver ........................................................................................ 78 Figure 12: Solution architecture using SAP ........................................................................................... 79 Figure 13: An example EAI project (MACom) [IRA-2003] ...................................................................... 82 Figure 14: IdP issue when integrating applications from different business units (Abstraction from

Figure 13) ............................................................................................................................................ 84 Figure 15: Intra-organizational EAI and possible authentication workflows, without fIdM ............... 85 Figure 16: Organizational Structure of the Lufthansa Group. Created from [FAK-2008] ................... 87 Figure 17: Scenario of fIdM in organizationally fragmented value chains. (Processes are pictured

above, information systems at the bottom. The EAI layer is in the middle) ............................... 89 Figure 18: Federation Scenario for Cloud Service Integration ............................................................. 91 Figure 19: Example of automated provisioning using SPML. Modified for Cloud Computing from

[PET-2003] .......................................................................................................................................... 92 Figure 20: FutureID Environments for Application Integration Services ............................................ 95 Figure 21: Modules and Interfaces of the FutureID Application Integration Services Component .. 98

2.4 Table of Tables

Table 1: Supported specifications and APIs for Web services security for IBM Websphere ........... 49 Table 2: Oracle Identity Federation Profiles and Bindings for SAML 2.0 ............................................ 53 Table 3: Oracle Identity Federation Profiles and Bindings for SAML 1.x and WS-Federation .......... 54 Table 4: Oracle Identity Federation Profiles and Extensions for OpenID 2.0 ...................................... 56 Table 5: Standards bodies in which TIBCO participates, taken from [TIB-WS] .................................. 70 Table 6: SAP Netweaver 7.2 Supported Specifications ......................................................................... 80




2.5 Glossary of Terms

access control

The process of restricting access to resources to privileged entities. Access control policies determines who can view access what resources, under which conditions, what they can do with it, and the type of device which may be used.

access management

The management of policies, rules, processes and information to control access to certain resources. In particular, the collection of systems and/or services associated with specific on-line resources and/or services that together derive the decision (privileges) about whether to allow a given entity to gain access to those resources or make use of those services.

address

An address is the identifier for a specific termination point and is used for routing to this termination point.

agent

An entity (e.g., computer system, device, person) that has been delegated (authority, responsibility, a function, etc.) by and acts for a Party (in exercising the authority, carrying out the responsibility, performing the function, etc.).

alliance

An agreement between two or more independent entities that defines how they will relate to each other and how they jointly conduct activities.

application (A)

An application is a software component run by a service provider that implements an actual service offering. Applications are typically accessible via HTTP through a web server. A service provider can run one to several applications; they typically run in some application server, container, or framework, as for examples servlets in a J2EE servlet container.

application integration service (AIS)

The Application Integration Service (AIS) is the interface of the service provider to connect to the FutureID infrastructure. It provides authentication to the application and can interface to existing authorization components. A legacy AIS is an off-the-shelf relying party implementation of a given federation dialect (SAML, WS-*, OAuth, OpenID).




The FutureID AIS is a custom implementation that provides more functionality and better privacy. An AIS consists of one access filter (AF) and one to several credential verifiers (CV).

assertion

An assertion is a digital representation of a claim. An entity may assert an attribute, authentication or authorization, and present a credential as proof, to enable authentication, to validate a user's identity, or to identify what the user is authorized to do.

asset

Anything that has value to the organization, its business, its operations and its continuity.

assurance

A measure of certainty that a statement or a claim is true.

attribute

An attribute is a physical or abstract named property belonging to an entity. An attribute typically has a value.

authentication

Authentication is the process of corroborating a claimed set of attributes or facts with a specified, or understood, level of confidence.

authentication protocol

An authentication protocol is a protocol used to authenticate data or entities. When relating to entities, it usually consists of the presenting of an identifier (e.g. a 'user-ID') and verifying the proof of something (e.g., the knowledge of a secret).

availability

Availability can be described as the property of being accessible and useable upon demand by an authorized entity.

In the context of service level agreements, availability generally refers to the degree to which a system may suffer degradation or interruption in its service to the customer as a consequence of failures of one or more of its parts.

binding




An explicit established association, bonding, or tie.

biometrics

A general term used alternatively to describe a characteristic or a process.

As a characteristic: A measurable biological (anatomical and physiological) and behavioral characteristic that can be used for automated recognition.

As a process: Automated methods of recognizing an individual based on measurable biological (anatomical and physiological) and behavioral characteristics.

broker

A broker is an organization that acts as intermediate in the authentication process and typically runs multiple FutureID software components, most prominently a broker service. In some contexts, it can also refer to the set of components operated by the organization. The overall infrastructure typically incorporates a large number of brokers and both, users and service providers, have at least a broker with whom they have a trust and possibly commercial relationship. Service providers can also act as brokers, running broker components themselves; in the most privacy-friendly setting, also users run broker components on their platform.

broker service (BS)

A broker service (BS) is the key component operated by a broker. It implements intelligent intermediation between the requirements of both, service provider and user, available user credentials, and available infrastructure resources such as existing identity providers and FutureID brokers. In dispatcher mode, it procures session credentials (such as assertions) issued by third parties; in claims transformer mode, it issues session credentials itself. The broker service is also capable to generate all possible authentication solutions from requirements and available resources, and provide a browser-based user interface for users who lack a FutureID client.

capacity

A capacity is the capability, legal competency or fitness to perform or produce something.

certificate

A certificate is an affidavit whereby a certification body attests to the truth of certain stated facts. In identity management, the term is often used to refer to a public-key digital certificate. X.509 Digital Certificates are a prominent example thereof.

certification authority (CA)




A Certification Authority is an entity that certifies public keys. Specifically, it guarantees the relationship between the identified entity and the public verification key. This association is achieved in a digital certificate that binds the public key to a partial identity of an entity.

It is generally a trusted party or trusted third party that accepts the responsibility of managing the certificate process by issuing, distributing and verifying certificates.

characteristic

A characteristic is an attribute other than an attribute determining an entity's identity, e.g., a capacity, a function, a professional qualification, etc. An entity can have several identifiers and/or characteristics.

claim

A statement made by one entity about itself or another entity that a relying party considers to be in doubt until it passes Claims Approval.

consent

The general permission granted by an individual to a requesting entity to use the individual's personal information in some agreed manner. Consent can be expressed, implied, or provided through an authorized representative.

context

A context can be described as a particular setting of an entity's environment. It can, for example, be a sphere of activity, a geographic region, a communication platform, a logical, or physical (security) domain.

In identity management the term 'context' is typically used to refer to a (1) communicational context or (2) a (security) domain:

(1) A communicational context is defined by roles and behavioral schemes assumed by the participants in the communication. In organizational systems communicational contexts in most cases map with sectors defined by the organization;

(2) A security domain is an environment that is defined by security models and a security architecture, incorporating a set of resources and set of system entities that are authorized to access some or all of the resources. The traits defining a given security domain typically evolve over time.

credential




i. An identifiable object that can be used to authenticate the claimant is what it claims to be and authorize the claimant's access rights.

ii. Data that is transferred to establish the claimed identity of an entity.

iii. The private part of a paired Identity assertion (user-id is usually the public part). The thing(s) that an Entity relies upon in an Assertion at any particular time, usually to authenticate a claimed Identity. Credentials can change over time and may be revoked. Examples include: a signature, a password, a drivers licence number (not the card itself), an ATM card number (not the card itself), data stored on a smart-card (not the card itself), a digital certificate, a biometric template.

credential verifier (CV)

A credential verifier (CV) is an abstract concept for a component that verifies a credential in input and issues a new credential in output. An example for a credential verifier is an identity provider that remotely verifies a user credential and issues a session credential (like a SAML assertion). Another example is the component in an application integration service that validates a SAML Assertion and issues a session cookie that is associated to identity attributes that are accessible to the application. Also brokers can optionally operate CVs, such as the universal authentication service, in order to authenticate user credential without the help of external identity providers.

data

Data is a carrier of information. This information is encoded in a specific physical representation, usually a sequence of symbols that have meaning and can be processed or produced by a computer.

database

A database is a data repository, in which a collection of information organized in such a way that a computer program can quickly select desired pieces of data. Traditional databases are organized by fields, records, and files.

digital signature

A digital signature is data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the origin and integrity of the data unit.

See also electronic signature.

directory

A directory is an organizational unit, or container, used to organize folders and files into a hierarchical structure.




In a network environment, a directory is a collection of autonomous elements, each of which consists out of computers, software, human operators etc. which cooperate to provide directory services.

discovery

i. The act of locating a machine-processable description of a network-related resource that may have been previously unknown and that meets certain functional criteria. It involves matching a set of functional and other criteria with a set of resource descriptions. The goal is to find an appropriate Web service-related resource.

ii. The process by which IdM resources can be found or located.

electronic identity

An electronic identity is a collection of identity attributes in an electronic form (eq. digital identity)

electronic signature

Data in electronic form which is attached to or logically associated to other electronic data and serves as a method of authentication.

From a legal perspective, an electronic signature is not necessarily considered equivalent to a handwritten signature. When it meets a number of conditions, it can be put on par with a handwritten one.

encryption

Encryption is a means of transforming data from a readable form (known as plain text or clear text) to one that is unintelligible (referred to as cipher text).

enterprise application integration (EAI)

Enterprise application integration is the use of software and computer systems architectural principles to integrate a set of enterprise computer applications.

entity

An entity is an item of interest, inside or outside a system, such as an automated process, a subsystem, a device, a person or group of persons that incorporates a specific set of attributes.




entity authentication

Entity authentication is a process that provides assurance of the claimed identity of an entity, as it corroborates the (claimed) partial identity of an entity and a set of its observed attributes.

federated identity

A federated identity is a partial identity which is the result of federation, and which usually implies that the entity to which this identity corresponds is recognized by several service providers or applications that are part of the federation.

See also federation. federation; circle of trust.

federation

Federation is the process of establishing a relationship between two or more entities or an association of entities compromising any number of service providers, identity providers or other entities.

As a noun, a federation refers to a group of entities have an agreement to create and process federated identities.

federation service (FS)

Federation Services (FS) interface the FutureID infrastructure to legacy service provider that operate only existing relying party implementations for a given federation dialect (e.g., SAML, OpenID, WS-Trust, OAuth). It receives a legacy authentication request and issues a FutureID authentication request. A FutureID broker typically runs several Federation Services in order to cater to different types of Service Providers. Technically, an FS receives an authentication request from the Application Integration Service. I.e., for authentication requests, the FS behaves like an Identity Provider towards the SP.

FutureID client (FC)

The FutureID Client (FC) is a software component installed on the user platform that is a rich client supporting user-centric authentication. While users without FC can participate in the FutureID infrastructure, only the use of a FC achieves full functionality and privacy. The FC can take full control of the authentication flow, provides the user interface for user decisions on disclosure, trust and policy, supports digital signature, and interfaces to various tokens (such as smart cards).

identification

i. Identification in terms of registration: identification as the process of using claimed, observed or assigned attributes of an entity to establish a partial identity of that entity.




ii. Identification as entity authentication: identification as the verification of the link between an entity and the asserted (partial) identity.

iii. Identification in terms of identifiability: identification as the process of "individualizing" a particular entity within a set of subjects.

identifier

An identifier can be defined as a non-empty set of attributes of an entity which uniquely identifies the entity within one or more specific contexts or sectors.

identity

The identity of an entity is the dynamic collection of all of the entity's attributes.

An entity has only one identity. As such, the identity of an entity this is more a fluid and evolving ("philosophical") concept, rather than a practical one.

An entity has only one identity, but it is neither possible nor desirable for an information system to gather all the attributes of a specific entity. Information systems focus on a specific subset of relevant attributes, commonly referred to as 'partial identities'.

identity data

Identity data or identity attributes are identifiers and/or attributes specific to the entities' physical, physiological, mental, economic, cultural or social identity.

identity information

All the information identifying a user, including trusted (network generated) and/or untrusted (user generated) addresses. Identity information shall take the form of either a SIP URI (see RFC 2396) or a "tel" URI (see RFC 3966).

identity management (IdM)

The definition, designation and administration of identity attributes and the management of access to and the usage of applications, services and resources.

identity provider (IdP)

An identity provider is a service provider that creates, maintains, and manages identity information for principals and who may provide entity authentication services to other service providers within an identity management architecture (e.g. within a federation).




integrity

Quality which implies that the items of interest (facts, data, attributes etc.) have not been subject to manipulation by unauthorized entities.

interoperability

The ability of independent systems to exchange meaningful information and initiate actions from each other, in order to operate together to mutual benefit. In particular, it envisages the ability for loosely-coupled independent systems to be able to collaborate and communicate; the possibility of use in services outside the direct control of the issuing assigner.

legal person

A legal person is a legal construct which the law treats for some purposes as if it were a person, distinct from the natural persons of which it is directly or indirectly composed.

metadata

Metadata is data about data. Metadata may describe how, when and by whom a particular set of data was collected, and how the data is formatted.

monitoring

Monitoring means to watch, keep track of, or check, usually for a special purpose.

name

A name is the identifier of an entity (e.g., subscriber, network element) that may be resolved/translated into an address.

object

An object is a non-acting entity that contains or receives data or information, to which access is controlled. An object is for example a file, a program, a document, an area of main storage (such as a database).

party

A natural person or a legal entity.




performance

Performance is the speed measured and perceived by individual users of the system (latency), or the speed perceived by the total infrastructure, from the point of view of the server (throughput,number of accepted transactions per second).

permission

A permission describes a set of defined actions, which correspond to a subset or the entirety of all possible uses of the controlled or protected resources, which an entity is entitled to perform (typically 'read', 'modify','create' and/or 'delete' resources).

person

A person can be a natural person (a human being) or a legal person.

policy

A policy is one or more definite goals, courses or methods of action to guide and determine present and future decisions.

Policies are implemented or executed within a particular context (such as policies defined within an organization or business unit) or across contexts (e.g., in the case of an identity federation).

Common examples of such policies are security policies, privacy policies, access control policies, registration policies etc.

principal

A principal is an entity whose (partial) identity can be authenticated.

privacy enhancing technology (PET)

A technology that enhances privacy. In particular a privacy-enhancing technology may increase the ability of a natural person to actively influence the availability of information about and exposure of itself.

privacy policy

A privacy policy is a policy which is based mainly data protection and privacy considerations.

It may specify, for example, what personal data is being collected, for what purpose the collected personal data is being used, how long the data is being retained, how a person may access and correct data relating to him/her, how and whether a person can opt-put;




and what security measures are being taken by the entities that process and/or control the data.

privilege

Right to perform a defined action or to use a defined service/resource. Privileges normally relate either to the ability to access data (e.g., update a payroll record) or the ability to use some feature (e.g., surf the Internet).

profile

A profile of an entity or a group of entities is an organized set of attributes that characterizes the specific properties of that entity or entities within a given context for a specific purpose.

protocol

A protocol may be described as a set of rules (i.e., formats and procedures) to implement and control some type of association (e.g., communication) between systems (e.g. an internet protocol).

In more general terms, a protocol can be qualified a series of ordered steps involving computing and communication that are performed by two or more system entities to achieve a joint objective.

provisioning

Provisioning can be defined as the automation of all the steps required to manage (setup, amend and revoke) user or system access entitlements.

pseudonym

A pseudonym is an identifier of identifiable entity, that is (1) either self-chosen by this entity or (2) or assigned by a provider, to identify this entity to a relying party for a period of time.

public key infrastructure (PKI)

System of certification authorities (CAs) (and, optionally, registration authorities and other supporting servers and agents) that perform some set of certificate management, archive management, key management, and token management functions for a community of users in an application of asymmetric cryptography.




registration

Registration is the process of collecting and corroborating a specific set of attributes of an entity, which typically relate to the partial identity (e.g., the age), a characteristic or a mandate of that entity, with sufficient certainty, before putting at the disposal means by which the entity can be authenticated, or the characteristic or mandate can be verified.

reliability

The term reliability is used to denote any system that consistently produces the same results, preferably meeting or exceeding its specifications.

relying party (RP)

A relying party is used to refer to an entity which trusts the results of an authentication protocol to establish the identity or an attribute of an entity; e.g. for the purpose of enabling subsequent transactions.

resource

The term resource is a generic term which is generally used to refer to entities with some value, systems and services.

Computing systems and services are for example disk space on a file server, electronic mailboxes, the system software, applications, services, data repositories, data objects, ... .

Non-computing systems and services may be anything from natural persons (e.g., employees) to physical assets (e.g., desk, telephone, mobile phone, laptop).

risk

Likelihood that an unwanted incident will occur and the impact that could result from the incident.

role

A role is a set of one or more authorisations related to a specific application or service.

scalability

Scalability is a metric indicating how well a solution to some problem will work (both from a functional and a performance point of view) when the size of the problem increases by several orders of magnitude.




sector

A sociological, economic, or political subdivision of society.

security domain

A set of elements, a security policy, a security authority and a set of security-relevant activities in which the elements are managed in accordance with the security policy. The policy will be administered by the security authority. A given security domain may span multiple security zones.

security policy

A security policy is a set of rules and practices that specify (or determine) how a system or organization should protect (or protects) data exchange, data storage, sensitive and/or critical system resources, and the use and provision of security services and facilities.

service

A digital entity comprising software, hardware and / or communications channels that interacts with subjects.

service provider (SP)

Entity that provides services to other entities.

third party

A third party is an entity other than the two or more entities initially communicating.

token

A token is any hardware or software component that containsbcredentials related to attributes. They may take any form, rangingbfrom a digital data set to smart cards or mobile phones. They canbbe used for both data/entity authentication and authorization purposes.

transport

The functional process of transferring information between different locations.

trust

A measure of reliance on the character, ability, strength, or truth of someone or something.




trust infrastructure

The technical infrastructure used by system entities in order to trust each other. Trust infrastructures may be built on Public Key Infrastructure, Kerberos, etc.

trust service (TS)

A FutureID Trust Service manages trust related knowledge in the FutureID infrastructure. In particular, it manages which issuers of user credentials (e.g. X.509 certificates) and session credentials (e.g. SAML Assertions, or WS-* claims) are trusted and at which trust level.

trusted certificates

Digital certificates of Certification Authorities (CA) that can be used to validate user or other entity certificates. In most PKI topologies a trusted certificates is the root CA certificate.

user agent (UA)

A user agent in FutureID is typically a plain vanilla web browser.

validation

Confirming that information given is correct, often by seeking independent corroboration or assurance.

verification

The process or an instance of establishing the truth or validity of something.




2.6 Table of Acronyms

A2A Application to Application

AIS Application Integration Service

A Application

B2Bi Business-to-Business integration

BS Broker Service

CA Certification Authority

CORBA Common Object Request Broker Architecture

CRM Customer Relationship Management

CV Credential Verifier

EAI Enterprise Application Integration

EDI Electronic Data Interchange

EII Enterprise Information Integration

EJB Enterprise JavaBeans

eID Electronic Identity

ESB Enterprise Service Bus

FC FutureID Client

FIdM Federated Identity Management

FTP File transfer protocol

FS Federation Services

HMAC Hash-based Message Authentication Code

HTTP Hyper Text Transfer Protocol

IaaS Infrastructures as a Service




IdM Identity Management

IdP Identity Provider

JAAS Java Authentication and Authorization Service

JDBC Java DataBase Connectivity

JSON JavaScript Object Notation

LDAP Lightweight Directory Access Protocol

LTPA Lightweight Third Party Authentication

MOM Message-oriented middleware

ODBC Open DataBase Connectivity

OLE DB Object Linking and Embedding for Databases

OP OpenID Provider

PaaS Platforms as a Service

PET Privacy Enhancing Technology

PKI Public Key Infrastructure

RP Relying Party

RPC Remote Procedure Call

SaaS Software as a Service

SAML Security Assertion Markup Language

SCA Service Component Architecture

SDO Service Data Object

SHA1 Secure Hash Algorithm 1

SMTP Simple Mail Transfer Protocol

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

SP Service Provider




SPML Service Provisioning Markup Language

TS Trust Service

UA User Agent

UDDI Universal Description, Discovery and Integration

UML Unified Modelling Language

WCF Windows Communication Foundation

WS Web Services

WS-BPEL Web Services Business Process Execution Language

WS-CAF WS-Composite Application Framework

WS-I Web Services-Interoperability organization

WSDL Web Services Description Language

XMI XML Metadata Interchange format

XRDS eXtensible Resource Descriptor Sequence

XPDL XML Process Definition Language




2.7 Referenced Documents

[KIS-EAI] Kishore Paramkusham. Overview of all EAI tools in the market. April

27.04.2009. http://kishoresblog.wordpress.com/2009/04/27/overview-of-all-

eai-tools-in-the-market/, 2009

[GAR-MC1] Jess Thompson, Yefim V. Natis, Massimo Pezzini, Daniel Sholler, Ross

Altman and Kimihiko Iijima.Magic Quadrant for Application Infrastructure

for Systematic Application Integration Projects. GARTNER, 20.06.2012

[FLO-EAI] Florence Lin. Enterprise Application Integration (EAI) Techniques.

03.2005.

[HAR-EAI] Haruo Makimoto. Expansion of EAI Technology. 02.2004.

http://www.fujitsu.com/downloads/MAG/vol40-1/paper03.pdf.

[ESB-EAI] Introducción a Integración con ESBs.

http://www.tcpsi.com/vermas/integracion_esb.htm

[COS-EAI] Alex da Costa, Principles and Guides EAI. http://www.eai-

ideas.com/architecture-ideas/principlesandguideseai

[ENT-EAI] Enterprise Application Integration (EAI).

http://engineering.indiabizclub.com/info/enterprise_application_integration

[SAG-STA] webMethods. Standards Support.

http://www.softwareag.com/corporate/products/wm/XML/default.asp

[SAG-CAP] webMethods Integration Server. Capabilities.

http://www.softwareag.com/corporate/products/wm/application_integration/

integration_server/capabilities/default.asp

[WM-IS] webMethods Integration Server.

http://www.softwareag.com/corporate/products/wm/application_integration/

integration_server/overview/default.asp

[WM-PS] Understanding webMethods Product suite.

http://documentation.softwareag.com/webmethods/wmsuites/wmsuite8-

2_ga/wM_Suite_Concepts/8-2-

SP1_Understanding_webMethods_Product_Suite.pdf

[WM-WF] webMethods Workflow. Concepts.

http://documentation.softwareag.com/webmethods/wmsuites/wMdoc/_web

M_suite_65/Workflow/Workflow%206.5.1/webMethods%20Workflow%20C

oncepts%20Guide%206.5.1.pdf

http://kishoresblog.wordpress.com/author/kishoresblog/

http://kishoresblog.wordpress.com/2009/04/27/overview-of-all-eai-tools-in-the-market/

http://kishoresblog.wordpress.com/2009/04/27/overview-of-all-eai-tools-in-the-market/

http://www.fujitsu.com/downloads/MAG/vol40-1/paper03.pdf

http://www.tcpsi.com/vermas/integracion_esb.htm

http://www.eai-ideas.com/architecture-ideas/principlesandguideseai

http://www.eai-ideas.com/architecture-ideas/principlesandguideseai

http://engineering.indiabizclub.com/info/enterprise_application_integration

http://www.softwareag.com/corporate/products/wm/XML/default.asp

http://www.softwareag.com/corporate/products/wm/application_integration/integration_server/capabilities/default.asp

http://www.softwareag.com/corporate/products/wm/application_integration/integration_server/capabilities/default.asp

http://www.softwareag.com/corporate/products/wm/application_integration/integration_server/overview/default.asp


http://documentation.softwareag.com/webmethods/wmsuites/wmsuite8-2_ga/wM_Suite_Concepts/8-2-SP1_Understanding_webMethods_Product_Suite.pdf



http://documentation.softwareag.com/webmethods/wmsuites/wMdoc/_webM_suite_65/Workflow/Workflow%206.5.1/webMethods%20Workflow%20Concepts%20Guide%206.5.1.pdf






[WM-MWS] Administering My webMethods Server. Version 8.0. December 2009.

http://documentation.softwareag.com/webmethods/wmsuites/wmsuite8_ga

/My_webMethods_and_Task_Engine/8-0-

SP1_Administering_My_webMethods_Server.pdf

[WM-ISA] webMethods Integration Server. Administrator’s Guide. Version 6.5.

http://documentation.softwareag.com/webmethods/wmsuites/wMdoc/_web

M_suite_65/Integration%20Server%20and%20Process%20Run%20Time/I

ntegration%20Server%206.5%20and%20Process%20Run%20Time%206.

5.1/webMethods%20Integration%20Server%20Administrator%27s%20Gui

de%206.5.pdf

[TIB-ACT] TIBCO Activematrix Businessworks.

http://www.tibco.com/products/automation/application-

integration/activematrix-businessworks/default.jsp

[TIB-ADP] TIBCO Adapters. http://www.tibco.com/products/automation/application-

integration/adapters/default.jsp

[TIB-CON] TIBCO ActiveMatrix BusinessWorks™ Concepts. Software Release 5.9.2.

May 2011

[TIB-WS] TIBCO’s support for Web services.

http://www.tibco.com/services/standards-support/web-services/default.jsp

[TIB-STA] TIBCO's Leadership in Standards Overview.

http://www.tibco.com/services/standards-support/default.jsp#mainframe

[TIB-POL] TIBCO ActiveMatrix Policy Manager. http://www.tibco.es/multimedia/ds-

activematrix-policy-manager_tcm55-717.pdf

[IBM-01] IBM WebSphere v7.0: Specifications API documentation:

http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ib

m.websphere.express.doc%2Finfo%2Fexp%2Fae%2Frovr_specs.html

[IBM-02] W3C Canonical XML Version 1.0. http://www.w3.org/TR/xml-c14n

[IBM-03] W3C Decryption Transform for XML Signature.

http://www.w3.org/TR/xmlenc-decrypt

[IBM-04] Web Services Security: SOAP Message Security 1.0 (WS-Security 2004).

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-

message-security-1.0.pdf

http://documentation.softwareag.com/webmethods/wmsuites/wmsuite8_ga/My_webMethods_and_Task_Engine/8-0-SP1_Administering_My_webMethods_Server.pdf



http://documentation.softwareag.com/webmethods/wmsuites/wMdoc/_webM_suite_65/Integration%20Server%20and%20Process%20Run%20Time/Integration%20Server%206.5%20and%20Process%20Run%20Time%206.5.1/webMethods%20Integration%20Server%20Administrator%27s%20Guide%206.5.pdf





http://www.tibco.com/products/automation/application-integration/activematrix-businessworks/default.jsp

http://www.tibco.com/products/automation/application-integration/activematrix-businessworks/default.jsp

http://www.tibco.com/products/automation/application-integration/adapters/default.jsp

http://www.tibco.com/products/automation/application-integration/adapters/default.jsp

http://www.tibco.com/services/standards-support/web-services/default.jsp

http://www.tibco.com/services/standards-support/default.jsp#mainframe

http://www.tibco.es/multimedia/ds-activematrix-policy-manager_tcm55-717.pdf

http://www.tibco.es/multimedia/ds-activematrix-policy-manager_tcm55-717.pdf

http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Frovr_specs.html


http://www.w3.org/TR/xml-c14n

http://www.w3.org/TR/xmlenc-decrypt

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf




[IBM-05] Web Services Security: SOAP Message Security 1.1 (WS-Security 2004).

https://www.oasis-open.org/committees/download.php/16790/wss-v1.1-

spec-os-SOAPMessageSecurity.pdf

[IBM-06] OASIS Web Services Security: Kerberos Token Profile.https://www.oasis-

open.org/committees/download.php/16788/wss-v1.1-spec-os-

KerberosTokenProfile.pdf

[IBM-07] OASIS Web Services Security: SAML Token Profile 1.1.


spec-os-SAMLTokenProfile.pdf

[IBM-08] OASIS Web Services Security: Username Token Profile. http://docs.oasis-

open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf.


spec-os-UsernameTokenProfile.pdf

[IBM-09] OASIS Web Services Security: X.509 Token Profile.http://docs.oasis-

open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf.


spec-os-x509TokenProfile.pdf

[IBM-10] Web Services Interoperability Organization (WS-I) Basic Security Profile.

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html. http://www.ws-

i.org/Profiles/BasicSecurityProfile-1.1.html

[IBM-11] Web Services Interoperability Organization (WS-I) Reliable Secure Profile.

http://ws-i.org/deliverables/workinggroup.aspx?wg=reliablesecure

[IBM-12] Web Services Secure Conversation (WS-SecureConversation).

https://www.oasis-open.org/committees/download.php/15978/oasis-wssx-

ws-secureconversation-1.0.pdf . http://docs.oasis-open.org/ws-sx/ws-

secureconversation/200512/ws-secureconversation-1.3-os.html

[IBM-13] Web Services Trust. http://schemas.xmlsoap.org/ws/2005/02/trust/OASIS

WS-Trust 1.3 New

[IBM-14] XML Signature Syntax and Processing. http://www.w3.org/TR/xmldsig-

core/

[IBM-15] XML Encryption Syntax and Processing. http://www.w3.org/TR/xmlenc-

core/

https://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

https://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

https://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf



https://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf

https://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf

https://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf

https://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf

https://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf

https://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html



http://ws-i.org/deliverables/workinggroup.aspx?wg=reliablesecure

https://www.oasis-open.org/committees/download.php/15978/oasis-wssx-ws-secureconversation-1.0.pdf

https://www.oasis-open.org/committees/download.php/15978/oasis-wssx-ws-secureconversation-1.0.pdf

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.html

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.html

http://schemas.xmlsoap.org/ws/2005/02/trust/

http://schemas.xmlsoap.org/ws/2005/02/trust/

http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf

http://www.w3.org/TR/xmldsig-core/

http://www.w3.org/TR/xmldsig-core/

http://www.w3.org/TR/xmlenc-core/

http://www.w3.org/TR/xmlenc-core/




[IBM-SPE] IBM Specification and product documentation.

http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ib

m.websphere.express.doc%2Finfo%2Fexp%2Fae%2Frovr_specs.html

[ORACLE-01] Oracle Fusion Middleware 11g: documentation libary:

http://www.oracle.com/technetwork/middleware/id-

mgmt/documentation/index.html

[ORACLE-02] Introduction to Oracle Identity Federation

http://docs.oracle.com/cd/E37115_01/admin.1112/e27239/oif_1.htm#AIAA

G6501troduction

[ORACLE-03] Oracle Fusion Middleware Administrator's Guide for Oracle Identity

Federation 11g Release 1 (11.1.1)

http://docs.oracle.com/cd/E28280_01/admin.1111/e13400/toc.htm

[ORACLE-04] Oracle Fusion Middleware – Federation Profile Protocols

http://docs.oracle.com/cd/E28280_01/admin.1111/e13400/intro.htm#CHDJ

EEAF

[MS-01] WCF Line of Business Adapter SDK, Microsoft.

http://msdn.microsoft.com/en-gb/biztalk/bb905478.aspx

[MS-02] What is Windows Communications Foundation?, Microsoft.

http://msdn.microsoft.com/en-us/library/ms731082.aspx

[MS-03] Windows Communications Foundation Feature Details, Microsoft.


[MS-04] Interoperability and Integration, Microsoft. http://msdn.microsoft.com/en-

us/library/ms730017.aspx



http://docs.oracle.com/cd/E28280_01/admin.1111/e13400/intro.htm#CHDJEEAF


http://msdn.microsoft.com/en-gb/biztalk/bb905478.aspx








[MS-05] Implementing Contracts in WCF, Microsoft. http://msdn.microsoft.com/en-

us/library/aa702732.aspx

[MS-06] Metadata, Microsoft. http://msdn.microsoft.com/en-


[MS-07] Using Data Contracts, Microsoft. http://msdn.microsoft.com/en-


[MS-08] Windows Communications Foundation Security, Microsoft.


[MS-09] Transports in Windows Communications Foundation, Microsoft.


[MS-10] Queues & Reliable Sessions, Microsoft. http://msdn.microsoft.com/en-


[MS-11] Workflow Services, Microsoft. http://msdn.microsoft.com/en-

us/library/dd456788.aspx

[MS-12] System.Transactions NameSpace, Microsoft.

http://msdn.microsoft.com/en-us/library/system.transactions.aspx

[MS-13] Transactions, Microsoft. http://msdn.microsoft.com/en-


[MS-14] Extending WCF. http://msdn.microsoft.com/en-us/library/ms733848.aspx

[MS-15] Web Services Protocols Interoperability Guide, Microsoft.


[SAP-01] Commercial Introduction.

http://www.sap.com/platform/netweaver/components/index.epx

http://msdn.microsoft.com/en-us/library/aa702732.aspx

http://msdn.microsoft.com/en-us/library/aa702732.aspx









http://msdn.microsoft.com/en-us/library/dd456788.aspx


http://msdn.microsoft.com/en-us/library/system.transactions.aspx









[SAP-02] SAP Netweaver Gateway Architecture. http://scn.sap.com/docs/DOC-8180

[SAP-03] SAP Netweaver Identity Management.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/7037d98

2-40aa-2a10-e283-a76a9dfc93ab?overridelayout=true

[ARA-2010] Arinze, B., and M. Anandarajan. 2010. “Factors That Determine the

Adoption of Cloud Computing.” International Journal of Enterprise

Information Systems 6 (4): 55–68.

[OPENID-2009] Balfanz, D., B. de Medeiros, D. Recordon, J. Smarr, and A. Tom. 2009.

OpenID OAuth Extension.

[BOS-2013] Borges, Georg, and Jörg Schwenk. 2013. Daten- und Identitätsschutz in

Cloud Computing, E-Government und E-Commerce. Berlin: Springer

Berlin.

[BUC-2009] Buckley, Peter J. 2009. “Internalisation Thinking: From the Multinational

Enterprise to the Global Factory.” International Business Review 18 (3)

(June): 224–235. doi:10.1016/j.ibusrev.2009.01.006.

[OASIS-2005] Cantor, Scott, Frederick Hirsch, John Kemp, Rob Philpott, and Eve Maler.

2005. Bindings for the OASIS Security Assertion Markup Language

(SAML) V2.0.

[OASIS-2006] Cole, G. 2006. OASIS Service Provisioning Markup Language (SPML)

Version 2.

[FAK-2008] Fahn, M., and O. Köhler. 2008. “Praxisbericht: IT Steuerung Und IT-

Controlling Im Lufthansa Konzern.” In Multikonferenz

Wirtschaftsinformatik, 925–937. GITO mbH Verlag.

[OPENID-2010] Foundation, OpenID. 2010. Get an OpenID.

[GOP-2009] Gopalakrishnan, A. 2009. “Cloud Computing Identity Management”.

SETLabs Briefings Vol. 7, No. 7.

http://scn.sap.com/docs/DOC-8180

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/7037d982-40aa-2a10-e283-a76a9dfc93ab?overridelayout=true





[HEW-2010] Heidrich, Joerg, and Christoph Wegener. 2010. “Cloud Computing Und

Datenschutz.” MultiMedia Und Recht: 803.

[HUN-2011] Hühnlein, Detlef, Gerrit Hornung, Heiko Rossnagel, Johannes Schmölz,

Tobias Wich, and Jan Zibuschka. 2011. SkIDentity - Vertrauenswürdige

Identitäten Für Die Cloud.

[HUN-2010] Hühnlein, Detlef, Heiko Rossnagel, and Jan Zibuschka. 2010. Diffusion of

Federated Identity Management.

[IRA-2003] Irani, Z., M. Themistocleous, and P.E.D. Love. 2003. “The Impact of

Enterprise Application Integration on Information System Lifecycles.”

Information & Management (41): 177–187.

[KEL-2002] Keller, Wolfgang. 2002. Enterprise Application Integration: Erfahrungen

aus der Praxis. Heidelberg: Dpunkt Verlag.

[KOC-2013] Koch, M., H. Lasi, and H.-G. Kemper. 2013. “Bestimmung

Aufgabenträgerorientierter Informationsbedarfe in Industriellen

Unternehmen.” In Leipzig.

[MAD-2008] Maler, Eve, and Reed Drummond. 2008. “The Venn of Identity: Options

and Issues in Federated Identity Management.” IEEE Security & Privacy

Magazine 6 (2): 16–23.

[MICROSOFT-2013] Microsoft. 2013. “BizTalk Server.”

[NAK-2006] Nadalin, A., and Kaler, C. 2006. Web Services Federation Language (WS-

Federation)

[PIC-2003] Picot, A., R. Reichwald, and R. Wigand. 2003. Die Grenzenlose

Unternehmung: Information, Organisation und Management. 5th ed.

Wiesbaden

[TSO-2011] TSO. 2011. ITIL Service Operation 2011 Edition. The Stationery Office.

[PET-2003] Peterson, T. 2003. “SPML – Computerworld.” Computerworld. October.




http://www.computerworld.com/s/article/86225/SPML?taxonomyId=061

[ORACLE-01] Oracle Fusion Middleware 11g: documentation library.

http://www.oracle.com/technetwork/middleware/id-

mgmt/documentation/index.html

[ORACLE-02] Introduction to Oracle Identity Federation.

http://docs.oracle.com/cd/E37115_01/admin.1112/e27239/oif_1.htm#AIAA

G6501troduction

[ORACLE-03] Oracle Fusion Middleware Administrator's Guide for Oracle Identity

Federation 11g Release 1 (11.1.1).

http://docs.oracle.com/cd/E28280_01/admin.1111/e13400/toc.htm

[ORACLE-04] Oracle Fusion Middleware – Federation Profile Protocols.

http://docs.oracle.com/cd/E28280_01/admin.1111/e13400/intro.htm#CHDJ

EEAF

[SAP-01] Commercial Introduction.


[SAP-02] SAP Netweaver Gateway Architecture. http://scn.sap.com/docs/DOC-8180

[SAP-03] SAP Netweaver Identity Management.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/7037d98

2-40aa-2a10-e283-a76a9dfc93ab?overridelayout=true

[FutureID-D21.3] Heiko Roßnagel, Rachelle Sellung, Sebastian Kurowski, Jan Zibuscka,

Detlef Hünhlein, Moritz Müller, and Meiko Jensen. Vision of FutureID.

FutureID Deliverable, D21.3, Version V.08. https://dms-

prext.fraunhofer.de/livelink/livelink.exe?func=ll&objaction=overview&objid=

2872517, May 2013.

[FutureID-D22.3] Marit Hansen et al. Privacy Requirements Analysis. FutureID Deliverable,

D22.3, Version 0.2. https://dms-




http://scn.sap.com/docs/DOC-8180






prext.fraunhofer.de/livelink/livelink.exe?func=ll&objaction=overview&objid=

2983263, April 2013.

[FutureID-D42.3] Sebastian Mödersheim et al. Specification of APS-language. FutureID

Deliverable, D42.3, Upcoming Draft Version. https://dms-

prext.fraunhofer.de/livelink/livelink.exe?func=ll&objId=2820457&objAction=

browse&viewType=1, May 2013.

[SAML-HoK] Nate Klingenstein, Tom Scavo et al. SAML V2.0 Holder-of-Key Web

Browser SSO Profile Version 1.0. OASIS Committee Specification 02.

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-holder-of-key-

browser-sso.html, August 2010.




3. Table of Contents

1. Executive Summary 1

2. Document Information 2 2.1 Contributors ................................................................................................................... 2 2.2 History ........................................................................................................................... 2 2.3 Table of Figures ............................................................................................................. 3 2.4 Table of Tables .............................................................................................................. 3 2.5 Glossary of Terms ......................................................................................................... 4 2.6 Table of Acronyms ....................................................................................................... 18 2.7 Referenced Documents ............................................................................................... 21

3. Table of Contents 30

4. Project Description 33

5. Introduction 34

6. EAI Enterprise Application Integration 35 6.1 EAI - FutureID .............................................................................................................. 41

7. Current industrial EAI infrastructures 43 And these are EAI Open-source solutions: ............................................................................. 43

7.1 IBM Websphere ........................................................................................................... 45 7.1.1 Solution overview ........................................................................................................ 45

7.1.2 Solution Architecture ................................................................................................... 46

7.1.3 Relevant solution products .......................................................................................... 47

7.1.4 Existing identity or Federated Identity Functionality ..................................................... 47

7.1.5 Solution protocols ........................................................................................................ 48

7.2 Oracle Fusion Middleware ........................................................................................... 49 7.2.1 Solution overview ........................................................................................................ 49





7.3 Software AG ................................................................................................................ 56 7.3.1 Solution overview ........................................................................................................ 56








7.4 Tibco Software ............................................................................................................. 62 7.4.1 Solution overview. ....................................................................................................... 62

7.4.2 Solution architecture. ................................................................................................... 64


7.4.4 Existing Identity or Federated Identity Functionality. .................................................... 67

7.4.5 Solution Protocols. ...................................................................................................... 68

7.5 Microsoft ...................................................................................................................... 71 7.5.1 Solution overview ........................................................................................................ 71





7.6 SAP ............................................................................................................................. 77 7.6.1 Solution overview ........................................................................................................ 77





8. Federated Identity management for EAI infrastructures 81 8.1 EAI and B2B integration ............................................................................................... 81 8.2 Standards for inter-organisational EAI ......................................................................... 82 8.3 Identity Management for intra-organisational EAI ......................................................... 83 8.4 Federated Identity Management in inter-organisational EAI ......................................... 86 8.5 An Abstract Model for Federated Identity Management and IdM .................................. 92

9. Abstract architecture for composing a set of enterprise services across a distributed landscape 94 9.1 Pre-existing Components of the FutureID Application Integration Services Architecture94 9.1.1 Applications (A) ........................................................................................................... 95

9.1.2 EAI Integration Services (EAI) ..................................................................................... 96

9.1.3 Application Client (AC) ................................................................................................ 96

9.1.4 Identity Broker (IdB) .................................................................................................... 97




9.2 The FutureID Application Integration Services Architecture ......................................... 97 9.2.1 EAI Identity and Authentication Connector (EAI-IdAC) ................................................ 98

9.2.2 Application Data Connector (A-DaC) ........................................................................... 99

9.2.3 AC Connector (AC-C) ................................................................................................ 100

9.2.4 Identity Broker Connector (IdB-C).............................................................................. 101

9.2.5 Claims Interpreter (CI) ............................................................................................... 102

9.2.6 Claims Transformer (CT) ........................................................................................... 103

9.2.7 Claims Transaction Database (CTDB) ....................................................................... 103

10. Conclusions ............................................................................................................... 105




4. Project Description

The FutureID project builds a comprehensive, flexible, privacy-aware and ubiquitously usable

identity management infrastructure for Europe, which integrates existing eID technology and

trust infrastructures, emerging federated identity management services and modern credential

technologies to provide a user-centric system for the trustworthy and accountable management

of identity claims.

The FutureID infrastructure will provide great benefits to all stakeholders involved in the eID

value chain. Users will benefit from the availability of a ubiquitously usable open source eID

client that is capable of running on arbitrary desktop PCs, tablets and modern smart phones.

FutureID will allow application and service providers to easily integrate their existing services

with the FutureID infrastructure, providing them with the benefits from the strong security offered

by eIDs without requiring them to make substantial investments.

This will enable service providers to offer this technology to users as an alternative to

username/password based systems, providing them with a choice for a more trustworthy, usable

and innovative technology. For existing and emerging trust service providers and card issuers

FutureID will provide an integrative framework, which eases using their authentication and

signature related products across Europe and beyond.

To demonstrate the applicability of the developed technologies and the feasibility of the overall

approach FutureID will develop two pilot applications and is open for additional applications who

want to use the innovative FutureID technology

Future ID is a three-year duration project funded by the European Commission Seventh

Framework Programme (FP7/2007-2013) under grant agreement no. 318424




5. Introduction

The current document provides a description of Enterprise Application Integration (EAI) and their

possibilities for integrating an EAI with the systems, components databases, application or

services of an organization or the possibilities to perform integration between different

organizations. The document shows the definition of EAI and the most important issues to know

regarding EAIs and also analyzes how to connect an EAI with FutureID.

Chapter 6 is an introduction of EAI Enterprise Application Integration, which gives an approach

of general issues for EAIs and the inclusion in FutureID. An overview of current Enterprise

Application Integration is presented showing the goals, purposes and advantages of including an

EAI in an organization or in a project. In this chapter are also presented the review of

technologies that supports an EAI, a roadmap for implementing an EAI solution, the patterns and

the architectures of an EAI solution. Presented at the end of this chapter is the integration and

role of EAI for FutureID and the added value that an EAI could provide with its inclusion.

Chapter 7 Current industrial EAI infrastructures, presents the current EAI commercial and

open-source solutions. The Gartner report Magic Quadrant for Application Infrastructure for

Systematic Application Integration Projects [GAR-MC1] has been considered as a reference

study for selecting the EAI leaders and looks more in detail into these solutions (IBM, Oracle,

Software AG, Tibco Software, Microsoft and SAP). For every selected solution, the solution

overview, architecture, products, the existing Identity or Federated Identity Functionality and the

solution Protocols have been studied. This study is focused to extract the common issues for all

the solutions as a starting point for obtaining an approach for federated identity management

and architecture for chapter 8 and 9 respectively of this document.

Chapter 8 Federated Identity management for EAI infrastructures, presents the standards for

inter-organizational EAI and the Identity Management for intra organizational EAI, and outlines

an Abstract model for Federated Identity Management and IdM

Starting from the findings of chapter 7 and 8, the chapter 9 Abstract architecture for

composing a set of enterprise services across a distributed landscape has been

developed. In this chapter, the main infrastructure components of the FutureID Architecture are

analyzed, studying how these components are involved in the general operations. Finally an

abstract architecture for FutureID is designed including Application Integration Services and the

integration with EAI systems.




6. EAI Enterprise Application Integration

Enterprise Application Integration is a framework that forms a middleware which enables the

integration of systems or data sources and applications within an enterprise.The framework

encompases a set of technologies that enable business processes and data to speak with

applications and services.

The organizations that integrates their systems and applications can achieve a more effective

utilization of company data and services improving the efficiency of their busineses processes.

Enterprise Application integration is the process of linking applications that cannot communicate

to one another and need to share data. This leads to inefficiencies due to having identical stored

data in multiple systems and/or the inability to automate processes. Some examples of

applications within an enterprise could be applications for managing data for health care, human

resources or internal communications.

EAI goals and approaches

With a well designed and implemented EAI architecture, an enterprise can focus on creating

new business in their field of action and avoid focusing on coordination of operative functions.

This rewards the organization with time, cost and resources saving. EAI connects existing and

new systems and applications to enable collaborative operation within the business processes

inside an organization.

A successfully implemented EAI increases the speed of business reaction time due to the

smarter information processing and the straight through transaction processing [KIS-EAI].

The following items are the main goals and approaches of EAI:

Linking different sorts of Systems.

Within an enterprise, can be found several systems that need to be linked together.

Those systems often reside on assorted operating systems, use different computer

languages or use different database types.

Avoiding the development of “stove-pipe systems”.

These systems were usually developed to make a specific solution for solving a specific

problem and consist of components that were constructed in such a way that makes their

modification very difficult. They have a limited functionality and manage data that are

difficult to share with other systems. With an EAI approach, the solutions can be

implemented in a different way, avoiding these types of systems.

Improving connectivity.




If integration is performed in a company without adopting a structured EAI approach,

point-to-point connections will grow across the company and a very difficult to maintain

and complex structure will result.

The number of connections needed to have fully connected n applications with point-to-

point connections is {n(n-1)}/2. Therefor for connecting 10 applications a total of 45 point-

to point connections are needed.

Sharing data and business process.

Implementing a solution using EAI means that analysts can look at the system as a

whole. EAI approaches involve distributed and heterogeneous systems and inter

disciplinary problems at high level.

Business oriented approach.

EAI solution should be implemented following a business- oriented analysis such as

Business process management, business architecture or Enterprise architecture. EAI

solutions shouldn’t focus on development oriented technical strategies.

EAI Purposes

Data integration.

EAI performs enterprise information integration (EII), ensuring the consistence of

information in multiple systems.

Vendor independence.

The EAI implements the rules and business processes for the applications. If an end

system or an application that is included in a business process is replaced with other

systems from different vendors, the business process need not be re-implemented.

Common access to several applications.

An EAI provides a single and unified access interface for several applications avoiding

the users having to learn use of several software packages from different vendors.

A review of the technologies that support it

Several operating applications and packages provide diversified integration approaches [HAR-

EAI][ESB-EAI]:

Communication protocols such as Web, Simple Mail Transfer Protocol (SMTP), File

transfer protocol (FTP)

Database-oriented middleware and standards, including ODBC, JDBC, and OLE DB.

Java middleware standards *Message brokers *New process automation and workflow

technology




Middleware to link systems such as Message-oriented middleware (MOM), remote

procedure calls (RPCs), Common Object Request Broker Architecture (CORBA).

Business package products for example ERP and Customer Relationship Management

(CRM).

Several trading protocols for example Electronic Data Interchange (EDI) and Business to

Business (B2B).

Web services, for example Simple Object Access Protocol (SOAP), Web Services

Description Language (WSDL) and Universal Description, Discovery and Integration

(UDDI).

Application servers, including the use of Enterprise JavaBeans (EJB) and ActiveX.

Roadmap for the implementation of an EAI solution

Defining the goals that are desired to reach for the application or the enterprise as a whole using EAI.

Deciding at what level integration will be done. The integration can integrate the data and/or the process. The detail of the types of integration are described in the next section

Depending on the level of integration (data or process), if the integration is at data level, the identification of the sources of data must be performed and also an enterprise metadata model, and in case of process integration this must also be carried out making the desired changes in business processes.

Agreeing on which systems/applications should be allowed to take part in the integration, sharing their data.

Identifying system/application interfaces and mapping data across the systems, achieving the information movement, in this way the data can be automatically shared across the systems or applications integrated in the EAI.

Selecting and performing the integration in a technology. Testing and maintenance.

Common types of EAI

When performing the implementation of an EAI solution, a decision must be taken regarding the

method or type of integration. Enterprises consider both, business processes and data and

select which of them require integration. In EAI there are four major common types of integration

[FLO-EAI] :

Data-level integration

The backend data stores are integrated enabling the movement of data between them.

Basically, the operation would be as follows: the information would be extracted from one

database, processed and updated in another database. For a real EAI implementation




this would mean extracting data from hundreds of databases and thousands of tables. So

keeping the integrated application’s data intact is a problem, because a table can have

dependencies to other table, and the integrated application would be the unique method

that could perform these dependencies.

Data-level integration can be classified into push-based or pull-based integration. For

Push-based integration, a requesting application makes SQL queries on another

application's database and receives data that are inserted into the requesting

application's database. For pull-based integration, an application needs the notification of

changes within another application’s data.

Cost of data-level integration is low because the application (the code) isn’t changed,

saving the costs of changing the code, testing it and deploying it. This type of integration

should be used when the application to integrate lacks an API or client interface.

Application-level integration

The interfaces contained within the packaged applications (e.g. SAP) are used to

perform the integration, they are shared to provide access to business processes and

information. This approach is the best way to integrate applications, it preserves the data

integrity. It lets bundling of applications sharing the business process and information.

This approach is one of the most preferred options.

Method-level integration.

This is a more complex form of application-level integration and less usual. The basis of

this type of integration is that common set of operations on multiple applications are

aggregated into a single front application, this avoids rewriting each method within the

application. The integrated applications must support RPC (Remote Procedure Call) or

distributed component technology to communicate with the front application, this is the

way the applications interact with integrated applications.

The disadvantage for this type of integration is that if the integrated application API

changes, then the front application will change (including components and applications

involved). A best option is to use application–level integration using middleware.

User interface-level integration.

Applications are integrated and their user interfaces are used as the common point of

integration. This type of integration is also known as proxy-based user-interface level

integration.

Use interface-level integration should be used when a developer can’t easily access to

the database or if the business process is embedded in the user interface.




EAI Architecture

The components of EAI architecture are varied, therefore, there are different options regarding

what is the best infrastructure, the standards and the component model [COS-EAI].

These are the key components for Enterprise Application Integration architecture:

1. Centralized Broker. The broker can be addressed using integration servers or software

like ESB (Enterprise Service Bus) that would play the role of a SOAP-oriented services

manager. This broker handles the access, communication and security. A Service Bus is

used by the applications to communicate with the Business Process.

2. Canonical data model. This is a design pattern based on a standard data structure used

to communicate between different data formats. XML has become the facto standard.

3. Adapter for every application. Each vendor, application or interface will build a single

component that will communicate natively to the adapter, and the adapter will

communicate with the centralized broker.

4. System model. This will establish the data flow, the APIs and the rules for integrating in

the system in such a way that the components can be built to interface with the system in

a standardized way.

The Figure 1 shows a common schema of EAI architecture:




Figure 1: Common Schema of EAI architecture

EAI Patterns

The Integration Patterns that the EAI systems can implement are the following [ENT-EAI]:

Mediation. Here, the EAI system acts as the go-between or broker between multiple

applications. When an event happens in an application, the integration module in the EAI

system is notified. After this, the integration module propagates the changes to other

involved applications.

Federation. In the case of federation, the EAI system would act as the global front-end

across all the integrated applications. All the accesses to any of the applications are

received and processed by the EAI system. The EAI system then interacts with the

underlying applications processing the request.

Frequently, both mediation and federation are used concurrently. The same EAI system could

keep multiple applications in sync using the mediation pattern, but the requests from users could

be dealt using a federation pattern.




6.1 EAI - FutureID

In this section the integration and role of EAI for FutureID is shown and the added value that the

EAI could provide with its inclusion.

The Figure 2 shows the way that the EAI is included in FutureID architecture within the Service

Provider.

Figure 2: FutureID Architecture including EAI.

The AIS (Application integration Services) would be the component that “translates”

between SAML (FutureID) and the protocol that EAI understands.

The EAI and the Applications are components of the Services provider. In FutureID,

Applications from two services providers, CS (Citizen Services) from EPSOS (SP5.1)

and BW (Business web) from Atos (SP5.2) will coexist.

A summary of steps:




The user wishes the access to a certain application. In the user screen there is a button

to select authentication with FutureID.

In case that the user selects authentication with FutureID, EAI receives the request and

carry it to AIS, which connects with FutureID Server components and performs the

authentication establishing a communication with FutureID Client (asking for

user/pass…).

Now the user is authenticated and can access to every Application that the service

provider offers.




7. Current industrial EAI infrastructures

In this section is described several current EAI solutions. [KIS-EAI].

The following EAI are commercial solutions:

Adeptia ESB Suite

BlueWay ESB & BPM Suite

Dell Boomi

Informatica Cloud Data Integration

Mule Enterprise

IBM WebSphere Message Broker and IBM Websphere Suite

Axway Process Manager

IBM WebSphere Transformation Extender

Generix Group GCI TradeXpress

Intersystems Ensemble

Viaduct CSC

SAP NetWeaver Process Integration (PI)

Neuron Enterprise Service Bus

Microsoft BizTalk Server

Tibco ActiveMatrix/Business Works and ESB

Magic xpi Integration Platform

GXS Direct integration

Oracle SOA Suite and Oracle Service Bus

Oracle Java Composite Application Suite (JCAPS)

Information Builders iWay ISM

BEA Weblogic Integration(WLI)

SnapLogic

Software AG webMethods Suite

And these are EAI Open-source solutions:

AdroitLogic UltraESB

Apache ActiveMQ

Mule ESB

Apache Camel

Guaraná DSL

Apache ServiceMix

Apache Synapse

Clover

Fuse ESB (enterprise ServiceMix)

Fuse Mediation Router (enterprise Camel)

Fuse Message Broker (enterprise ActiveMQ)




Jitterbit Integration Server

MuleSoft

Niklas Integration Platform

Openadaptor

OpenESB

Petals ESB

Spring Integration

Talend

Virtuoso Universal Server

jBoss

In this section the Gartner report Magic Quadrant for Application Infrastructure for Systematic

Application Integration Projects [GAR-MC1] has been considered as the reference study of EAI

solutions. From this report, several solutions have been selected as leaders in EAI.

This selection has been made from the evaluation of 17 vendors (other vendors not considered

here could be suitable for projects with specific characteristics or in a specific country) and

selecting several of them emphasizing the product capabilities for the projects for:

Integration of applications deployed inside the enterprise (that is, with the trading

partners) or outside the enterprise, this could be in the cloud, as software as a service

(SaaS).

Creation of business services using existing assets.

The integration styles considered in the study are data consistency, multistep process (business

processes activities orchestration) and composite application integration. These integration

styles are applied for application to application (A2A) integration (this includes integration with

cloud based applications), business to business (B2B) integration and integration platform as a

service (iPaaS). Actually the enterprises tend to have the best both for A2A and B2B integration

because these two approaches have much in common with middleware.

The evaluation has been made taking into account if the vendor has tried to achieve as many as

possible technical capabilities.

The result in the GARTNER report is the selection of the following EAI solutions as leaders:

IBM

Oracle

Software AG

Tibco Software

Microsoft

SAP




This section studies the selected solutions, and for every EAI solution, the following items have

been considered relevant for FutureID:

Solution overview.

Solution architecture. For every commercial solution, a schema of an EAI architecture

has been studied. These sections will be used to get a common schema for chapter 9

(Abstract Architecture for composing a set of enterprise services across a distributed

landscape) in which an abstract architecture will be proposed.

Relevant solution products. In this section the most relevant products for the provider are

described.

Existing Identity or Federated Identity Functionality. The section studies if the solution

has a federated identity management solution. Chapter 8 (Federated Identity

management for EAI infrastructures) will use this section as a starting point. The idea is

know how to integrate federated identity functionality in FutureID.

Solution Protocols. The protocols used by the EAI solution to communicate with our

architecture are included here.

7.1 IBM Websphere

7.1.1 Solution overview

WebSphere® Application Server provides the framework to enable robust and proscribed

integration between client applications and multiple data resources, and legacy applications. It

utilizes a standard 3-tier architecture comprising:

Client Tier

Business Logic Tier

Data Resource Tier

This architecture provides a separation between components required for connecting to clients

including web services and 3rd party applications, and the data resources, assets and

applications which are costly and expensive to modify. The middle tier provides business logic

and process to moderate between the two tiers enabling the application of policies and business

rules. This tier also enables the creation of meta-data, combining information from various

sources to match specific requirements.

By separating these tiers, clients and assets can be switched and reconfigured without end-to-

end re-engineering, so simplifying migration and the incorporation of new technologies.

Multiple sessions and connections can be established and the solution is easily scalable

The WebSphere product family includes numerous tools, including client and data asset

adapters, as well as enhanced business logic tools for monitoring and tuning. [IBM-01]




7.1.2 Solution Architecture

Because of the richness of the capabilities of WebSphere many of the more basic functionalities

for federation can be drawn from within the product itself.

However there will be functionality that may be specific to FutureID and as such a mix of internal

functionality and specific functionality from the FutureID Integration Service could be used. This

‘hybrid’ integration (Error! Reference source not found.) may be more difficult to implement

and could, in the future, make it difficult to integrate upgrades and enhancements to federation

standards as well as FutureID infrastructure features.

This leads to a second integration option where all Federation functionality is managed by the

FutureID Integration Service with a common communication channel between the EAI client tier

and the federated user via the FutureID Integration Service component. (Error! Reference

source not found.)

Figure 3: WebSphere hybrid integration model with FutureID




Figure 4: WebSphere common integration model with FutureID

7.1.3 Relevant solution products

The following products may be relevant to EAI deployments interfacing with FutureID:

IBM Websphere Application Server Express (IBMi) Version 7.0

IBM Websphere Feature Pack for SCA Version 1.01 (All Operating Systems)

IBM Websphere Feature Pack for Web 2.0 (All Operating Systems)

IBM Websphere Feature Pack for Web 2.0 and Mobile v1.1.0 (All Operating

Systems)

IBM Websphere Feature Pack for XML (All Operating Systems)

IBM Websphere Feature Pack for XML (All Operating Systems)

IBM HTTP Server for Application Server Express Version 7.0

A full product list can be found at [IBM-SPE].

7.1.4 Existing identity or Federated Identity Functionality




Authentication functionality is implemented using a Java Authentication and Authorization

Service (JAAS) login module. The web authenticator and the EJB authenticator pass the

authentication data to the login module, which (from WebSpherev7.0) can use the following

mechanisms to authenticate the data:

Kerberos

LTPA

RSA token

The authentication module uses the registry that is configured on the system to perform the

authentication. Four types of registries are supported:

Federated repositories

Local operating system

Standalone Lightweight Directory Access Protocol (LDAP) registry

Stand-alone custom registry

7.1.5 Solution protocols

These are the supported specifications and APIs for Web services security. The product

supports the specifications and APIs in this table.

Specification or API WebSphere Version 7.0

Canonical XML Canonical XML 1.0 applies to these versions.[IBM-02]

Decryption Transform for XML Signature Decryption Transformation for XML Signature applies to these versions.[IBM-03]

Exclusive XML Canonicalization Exclusive XML Canonicalization 1.0 applies to these versions. [IBM-04]

OASIS Web Services Security: SOAP Message Security (WS-Security) WS-Security 1.0[IBM-05] WS-Security 1.1

OASIS Web Services Security: Kerberos Token Profile Kerberos Token Profile 1.1 New [IBM-06]

OASIS Web Services Security: SAML Token Profile 1.1 SAML Version 1.1 and 2.0 assertions [IBM-07]

OASIS Web Services Security: Username Token Profile Username Token Profile 1.0[IBM-08] Username Token Profile 1.1 [IBM-08]

OASIS Web Services Security: X.509 Token Profile X.509 Token Profile 1.0 [IBM-09] X.509 Token Profile 1.1 [IBM-09]

Web Services Interoperability Organization (WS-I) Basic Security Profile

WS-I Basic Security Profile 1.0[IBM-

10] IBM-10]

WS-I Basic Security Profile 1.1 New [IBM-10]

Web Services Interoperability Organization (WS-I) Reliable Secure Profile

WS-I Reliable Secure Profile 1.0 (draft) [IBM-11]




Specification or API WebSphere Version 7.0

Web Services Secure Conversation (WS-SecureConversation)

OASIS WS-SecureConversation 1.0 (submission draft) [IBM-12] [IBM-12] OASIS WS-SecureConversation 1.3 New [IBM-12]

Web Services Trust OASIS WS-Trust 1.1 OASIS WS-Trust 1.3 New [IBM-13]

XML Signature Syntax and Processing XML Signature Syntax. [IBM-14]

XML Encryption Syntax and Processing XML Encryption Syntax.[IBM-15]

Table 1: Supported specifications and APIs for Web services security for IBM Websphere

7.2 Oracle Fusion Middleware


The Oracle 11g framework is promoted by Oracle to provide a flexible end-to-end infrastructure

for e-business. [ORACLE-01]

Oracle Fusion Middleware 11g is seen as the middleware ‘glue’ between the various

components. Additionally external components within the Fusion Middleware 11g product can

provide extra functionality.

The primary benefits of Oracle Fusion Middleware 11g include:

Certified integrations with Oracle Fusion Middleware, Oracle Database, and Oracle

Applications

Interoperability with existing infrastructure and applications

External functionality is provided by

Improved performance: Oracle WebLogic Suite 11g

Portal framework: Oracle WebCenter Suite 11g

Agility and Flexibility: Oracle SOA Suite 11g

Security and Compliance: Oracle Identity Management 11g

Unified design and development: Oracle JDeveloper 11g




Figure 5: Oracle Fusion Middleware


The Oracle Fusion Middleware 11g solution relies on multi-tier architecture to deliver a highly

modular EAI between the other components in the overall solution. Oracle Identity Management

11g is pre-packaged with Oracle E-Business Suite and is therefore likely to be the Identity

Management of choice for many Service Providers that are using Oracle Business Suite based

applications. Because of the modular nature of Oracle 11g, this document will concentrate on

certain functionality within the Oracle Identity Management 11g.

Oracle Identity Management 11g automates user provisioning and de-provisioning and provides

single sign-on capabilities. Oracle Identity Management 11g is a fully integrated suite that

provides the foundation for Oracle’s Service-Oriented Security strategy, and supports integration

with the Oracle Identity Federation.

The main interfaces between FutureID and Oracle Identity Management 11g is Oracle

Webserver and WebGate, (See Error! Reference source not found.) as well as Oracle Identity

Federation.




Figure 6: Oracle solution architecture for FutureID


The following products may be relevant to EAI deployments interfacing with FutureID:

Oracle Fusion Middleware 11g - Oracle Identity Federation R1 (v11.1.1)

Oracle Fusion Middleware 11g - Oracle Identity Federation R2

Oracle Fusion Middleware 11g –Webgate




Oracle Fusion Middleware 11g –Access Manager


Oracle Identity federation [ORACLE-03] is available in two architectures:

As a federation engine, Oracle Access Management Identity Federation is built into

Oracle Access Management (11g Release 2 (11.1.2).

As a standalone, self-contained federation server, known as Oracle Identity Federation,

that enables single sign-on and authentication in a multiple-domain identity network (11g

Release 1 (11.1.1).

The Service Provider integration Engine included with Oracle Identity Federation consists of a

servlet that processes requests from the server to create a user authenticated session at the

Identity and Access Management (IAM) server. The engine includes several internal plug-ins

that allow it to interact with different IAM servers, including Access Manager. [ORACLE-02]

Identity providers and service providers exchange assertions using profiles and services defined

in a federation protocol such as SAML, WS-Federation, or OpenID. Assertion functions include:

establishing secure connections

conveying authentication data across those connections

receiving and interpreting assertions from other domains

Profiles describe the types of exchanges required to transfer assertions between Identity

Providers and Service Provider. Assertion profiles available in Oracle Identity Federation:

Browser POST Profile

Browser Artifact Profile

SOAP Binding

Browser HTTP Redirect Profile

Name Identifier Management Profiles

SAML Attribute Sharing Profile

WS-Federation Passive Requester Profile

Federation Termination Profile

Global Logout Profile

OpenID Profiles and Extensions





Protocols supported by Oracle Fusion Middleware Identity Federation can be found at

[ORACLE-04]

7.2.5.1 SAML 2.0 Protocol

Table 2: Oracle Identity Federation Profiles and Bindings for SAML 2.0Table 2 shows the SAML

2.0 protocol profiles and security transport binding combinations that Oracle Identity Federation

supports.

Function

Profiles/

Bindings SAML 2.0

Single Sign-On Artifact X

Single Sign-On HTTP Post X

Logout HTTP Redirect X

Logout HTTP Post X

Name ID Registration HTTP Redirect X

Name ID Registration HTTP Post X

Name ID Registration SOAP X

Federation Termination HTTP Redirect X

Federation Termination HTTP Post X

Federation Termination SOAP X

Attribute Retrieval SOAP X

Table 2: Oracle Identity Federation Profiles and Bindings for SAML 2.0

7.2.5.2 SAML 1.x and WS-Federation Protocol

Table 3 shows the SAML 1.x and WS-Federation (WS-Fed) protocol profiles and security transport binding combinations that Oracle Identity Federation supports.




Function Profiles/ Bindings

SAML 1.0/1.1 WS-Federation

Single Sign-On Artifact x

Single Sign-On HTTP Post x x

Logout HTTP Redirect

x

Table 3: Oracle Identity Federation Profiles and Bindings for SAML 1.x and WS-Federation

7.2.5.3 OpenID 2.0 Protocol

Oracle Identity Federation supports OpenID version 2.0.

7.2.5.4 Authentication

Oracle Identity Federation supports basic OpenID authentication request functionality.

7.2.5.5 Associations

Oracle Identity Federation supports provider federations using an HMAC shared secret for

message signing and verification, including:

HMAC-SHA1

HMAC-SHA256

Oracle Identity Federation supports these session association types:

No encryption

Diffie-Hellman SHA1

Diffie-Hellman SHA256

7.2.5.6 Discovery

Oracle Identity Federation supports:

metadata publishing for OpenID Provider (OP) and Relying Party (RP)

XRDS discovery of OPs by the RP




RP endpoint validation is implemented to defend against URL redirectors spoofing RPs to

capture OpenID assertions. The RP endpoint validation by the OP is implemented by:

XRDS discovery of the RP, checking that the endpoint is listed in the XRDS documented

hosted at the realm URL

Verification using the Realm as described by the OpenID specifications. The realm can

either be a URI or a matching domain (*.foo.com for example). At verification, the server

extracts the domain from the realm and attempts to match it to the RP endpoint. A valid

domain used for verification needs to contain at least two elements (.foo.com is

acceptable while .com is not). Additionally, the server provides a way to specify which

domain should be discarded (for example *.co.uk).

7.2.5.7 Account Linking

Oracle Identity Federation supports persistent account linking between OpenID claimed ID and

local user account by using a federation data store.

7.2.5.8 Assertions

Oracle Identity Federation supports assertion-to-user record mapping on the SP side.

7.2.5.9 Pseudonyms

Oracle Identity Federation uses opaque, persistent name identifiers in OpenID assertions. This

means that:

a federation data store is required on the IdP side

a federation data store is optional on the SP side: if the SP is configured to use

Federated Identity to map the assertion to a user, then the federation data store is

required.

7.2.5.10 Profiles and Extensions

Table 4 shows the protocol profiles and extensions that Oracle Identity Federation supports.

Profile/Extension Notes

Attribute Exchange (AX) extension

v. 1.0 supported




Profile/Extension Notes

Provider Authentication Policy Extension (PAPE)

v. 1.0 supported

ICAM profile Support for No Personal Identification Information, ·Private Personal Identifier, ·GSA Profile for OpenID, and ·NIST authentication levels

Table 4: Oracle Identity Federation Profiles and Extensions for OpenID 2.0

7.3 Software AG


webMethods Integration Server offers the quick connection of any system or application and

enables them as services in order to create new rapid business processes.

The following items describe the most relevant webMethods integration products.

webMethods Integration Services

webMethods Integration Server, integrates systems faster and connects the existing apps with

the ESB (Enterprise Service Bus). The ESB is a complete enterprise application integration

solution. It is standards-based letting the integration of any technology, for example ERP

systems, databases, SaaS platforms, Web services, JMS messaging systems and packaged

applications. [WM-IS]

webMethods Integration Server can integrate applications and data with cloud-based services.

webMethods enables the use of existing IT assets in new ways for achieving faster and cost

effectiveness for the business.

webMethods Integration Server is at the core of the webMethods suite and it can be built on by

adding SOA and BPM governance tools designed to work together.

The capabilities offered by webMethods Integration Server are the following:

Service-Oriented Platform.

The webMethods Integration Server offers a reliable and robust platform for developing a

SOA. With this platform, the services can be created faster and integrated with other

systems creating new business processes.

http://www.softwareag.com/corporate/products/wm/soagovernance/default.asp




The existing applications, resources, databases and more can be enabled as services,

and re-used in new business processes and services. Integration Server can connect the

system using open-standards or native APIs. The services to integrate can be

implemented in any language or technology (Java,C++, J2EE, .NET, BPEL, XSLT or

built-in language).

The webMethods Integration Server is a standards-based solution. It supports all kinds of

standards, allowing the integration of a great variety of application and systems.

Service orchestration.

The integrated systems are logic and functional unlocked and business services can be

created. webMethods provides an easy-to-use design tool and can transform the

information from one system for another by mapping. webMethods supports any

integration pattern, that is, webMethods Integration Server can be called from

HTTP(S),FTP(S), SOAP, JMS, Scheduler, SMTP, BPM Event, Java Client C/C++ Client,

.NET Client, Adapter or Flow.

Enterprise-Class Platform

webMethods lets count on high performance as the business is growing. webMethods

IntegrationServer can be scaled vertically to maximize the performance of the software

on individual servers. It can process a message of any size. It can also be horizontally

scaled deploying additional platform nodes and configuring by load balancing. Load-

balancing mechanisms are part of the Software AG clustering architecture.

webMethods has developed from enterprise-class technology and gives a high

performance, application scalability, security and support for key industry standards.

webMethods supports several security standards such as SSL/TLS for securing the

HTTP and JMS transports, and WS-Security for securing messages and also supports

other standards for enhancing the integration with other systems including JDBC for

database integration and LDAP/LDAPS for authentication against directory services. The

ESB supports methods to encrypt and sign messages and authentication tokens.

webMethods Broker

webMethods Broker is a backbone for sending messages that meet high performance

requirements and get integrity, security and reliability for the data. webMethods Broker supports

JMS (Java Message Service) standard and manages message routing between applications. Its

functions are also the queuing, storage and filtering necessary for application integration and

event processing.

The webMethods Broker can connect several Integration Servers and route the process data

across the Integration Servers. These process data can come from distributed process steps

across these multiple Integration Servers. [WM-PS]





To improve performance and reliability, you can distribute process steps across multiple

Integration Servers. In this case the Integration Servers must connect to a webMethods Broker

that routes the process data across Integration Servers.

webMethods Optimize for Infrastructure

This product is a Business Activity Monitoring (BAM) solution that shows the real-time

performance of Adabas, Natural, webMethods ApplinX, webMethods EntireX, webMethods

Integration Server and Broker.

webMethods Adapters

webMethods Adapters are software that let the connection of existing applications into the

webMethods ESB, Integration Server. They can use SAP, Oracle, J2EE®, .NET or others. The

adapters are used for delivering new business solutions faster by connecting packaged

applications, databases etc.

webMethods Adapters offer a standard Adapter Framework that will quickly integrate the existing

applications. The framework will provide a fast startup, a management of the connections and

transactions and the possibility of enabling the resources as a service.

webMethods for SAP

webMethods for SAP is a Software solution for application and B2B integration for enterprises

that look to integrate non-SAP applications with their SAP environment. It is an extension of

SAP’s original solution for integration, the SAP Business Connector. It’s considered the

strongest solution for SAP integration for heterogeneous environments. webMethods for SAP is

based on the webMethods Integration Server and Trading Networks.


webMethods products enables Event-driven archtitecture. The Event-driven architecture would

have a pattern that supports the production and detection of events, and the consumption and

reaction to events.

The products that would be used for this architecture would be webMethods Broker, Designer,

and Integration Server.

By means of webMethods Broker, the event data are distributed. The event producers

issues the data publishing JMS messages in the form of events to webMethods Broker.




The data are consumed by the event consumers using JMS subscriptions. Each event

type is associated to a JMS topic.

The Integration Server subscribes and publishes events on the JMS topics and offers

built-in services.

The applications that aren‘t included in webMethods product suite environments can

communicate with webMethods Broker using standard JMS clients.

webMethods Designer is used for graphical development

Architecture for FutureID

The Figure 7 shows the architecture of an integration solution:

Figure 7: webMethods solution architecture for FutureID

The business processes are executed in Integration Server and webMethods Broker

The application and the adapter are included in the webMethods Integration Server which will

send and receive messages with FutureID components by means of webMethods Broker.

The component User Agent from FutureID will communicate with service provider by means of

webMethods Broker using an Adapter. The FutureID Application Integration Services (AIS) will

include an adapter which transforms the SAML assertions and sends them to webMethods

Broker.





The relevant products provided by Software AG for Application integration are included by the

webMethods Suite family of products:

webMethods Integration Server, supporting ESB and orchestration requirements;

webMethods Message Broker and my-Channels Nirvana for MOM;

webMethods BPMS, providing process orchestration capabilities (along with other BPMS

features);

webMethods Trading Networks for B2B integration;

webMethods Adapters;

webMethods EntireX and ApplnX for mainframe integration;

CentraSite for metadata management;

webMethods Designer for modeling and development.

Other Software AG products relevant to application integration projects:

Aris Platform for enterprise modeling, process performance monitoring and dash board

design;

Terracotta Enterprise Ehcache and Big Memory in-memory data grid technology;

Business Events for CEP.


The authentication process is performed inside the Integration Server.

The webMethods Integration Server processes requests from the clients that request a

communication. Authentication determinates who a client is. [WM-ISA]

When the Integration Server performs authentication, it works with access control. First, the

server determines the user name, and after that, verifies whether the client has access to the

requested resource. The client’s group membership is used by the server to perform the

resources access control.

The server authenticates when a client request a service and controls the access to it checking

if the client is a member of a group.

The server will authenticate using client certificates if the incoming request is HTTPS or FTPS.

The server can use basic authentication (user name and password), customize authentication

(for example using external directory such as LDAP or NIS to store and manage users)





The webMethods Integration Server supports these key standards [SAG-STA][SAG-CAP]:

HTTP. Hyper Text Transfer Protocol

XML

SOAP Simple Object Access Protocol

WDSL Web services Description Language (W3C).

UDDI Universal Description, Discovery and Integration

WS-BPEL Web Services Business Process Execution Language.

BPEL4People

XPDL XML Process Definition Language

WS-Policy & WS-PolicyAttachment Specifications.

WS-RMPolicy. Part of the WS-RX TC in OASIS

SCA (Service Component Architecture) and SDO (Service Data Object)

WS-I Web Services-Interoperability organization.

WS-MeX WS-MetadataExchange

WS-Addressing. WS-Notification, WS-ReliableMessaging, WS-RF, and WS-Eventing

depend on WS-Addressing

WS-Notification, an OASIS specification

WS-Discovery. Web services Dynamic Discovery.

WS-Eventing.

WS-RX. Web services Reliable Exchange

WS-ReliableMessaging

WS-Transaction

WS-Secure Exchange

WS-Federation. Defines mechanisms to allow different security realms to federate by

allowing and brokering trust of identities, attributes, authentication between participating

Web services. Co-sponsored formation of WS-Federation TC in OASIS

WS-Choreography

Web Services Choreography (W3C).

SOAP with Attachments (SwA)

SOAP MTOM/XOP

WSDM Web services Distributed Management.

WS-RF. Web Services Resource Framework

WS-RP. Web Services for Remote Portlet (OASIS)

WS-Security.An OASIS Specification.

Web Services Activity

WS-Management

BPEL4WS. Business Process Execution Language for Web services (Private). L

WS-CAF. WS-Composite Application Framework.




SOAP Routing and Reliable Messaging Extensions

WS-Routing. Web Services Routing Protocol

XMI. XML Metadata Interchange format.

XML Schema

XML Core (XML Language, DTD, DOM, XML Name Space)

XQL. XML Query Language

XSLT. XSL Transformations (W3C).

CMDB Federation. A specification to federate CMDBs.

JBI 2.0 Java Business Integrator

JAXM, JAXR, JAX-RPC, JAXB. JSR for messaging, registry access, SOAP RPC

messaging and data binding developed in JCP

7.4 Tibco Software

7.4.1 Solution overview.

TIBCO's application integration platform makes possible the real-time connectivity so that

availability and access of information is allowed from anywhere and anytime. The platform lets

data from applications reach other applications that need it. The distributed framework that

TIBCO provides lets the easy and rapid creation of flexible business applications and the

resulting easy management of components across the system.

The TIBCO solutions are standards-based and allow working with existing IT investments

achieving a seamless interoperability.

TIBCO application integration allows the simplification of the complexity of the infrastructure and

dynamic and flexible configuration and deployment

The most important benefits of TIBCO application integration include:

Accelerate Time-to-Value: The model-driven environment that TIBCO provides, makes

the integration easy and accelerates the time-to-market of business applications and

services.

Reduce Complexity & Costs: TIBCO application integration connects, integrates and

orchestrates components in a centralized platform eliminating hard interfaces and

complex connections.

Integrate Across Channels: The consistent architecture of TIBCO application integration

and the common backend of services lets the integration across the business channels.




Enhance Legacy Assets: Achieve the increase of the performance from the existing IT

investment reusing the data and the functions.

Support Better Outcomes: Real-time information is accessible and available from

anywhere at any time and this information can be used by the system that need it.

TIBCO ActiveMatrix BusinessWorks™

“TIBCO ActiveMatrix BusinessWorks™ is a robust and highly scalable platform that can be used

to develop new services, automate business processes, and integrate applications.” [TIB-ACT]

TIBCO ActiveMatrix BusinessWorks™has a unified and model-driven design environment (IDE)

that allows the creation, orchestration and integration of services in an easy and rapid way. This

allows the high productivity and the faster results that can be achieved.

The platform allows starting a small service-oriented architecture (SOA) and then adding more

functionalities as new requirements are needed. TIBCO ActiveMatrix BusinessWorks will run

with other ActiveMatrix products and several adapters and plug-ins can be used to increase the

speed and performance.

ActiveMatrix BusinessWorks is currently used by thousands of companies worldwide – mostly

serving as the basis for several service-oriented business applications.

BusinessWorks™ ProcessMonitor adds the value of monitoring data from BusinessWorks

across domains allowing providing a real-time view of the integration process.

Regarding the performance, it has been proven to support more than to 1 billion messages per

day (over 25,000 per second). The uptime is 99.999% or greater. This allows the organizations

to increase their productivity.

The benefits of TIBCO ActiveMatrix BusinessWorks are:

Accelerate Time-to-Results: This is due to the small (sometimes nothing) coding that the

administrators or developers have to do for building and changing processes and

applications.

Enhance Efficiency: The deployment and management of applications is more efficient

because the applications are exposed as reusable services. So an assembly and

orchestration of the services must be done to create composite applications.

Expand Connectivity: Adapters accelerates the integration of applications and technology

achieving greater performance.

Optimize Automation Levels: the performance of the business processes is improved

because of the faster processed transactions due to the seamless transfer of data within

the organization.




Increase Reliability: The Services are deployed on a scalable horizontal distributed

enterprise service bus (ESB). This minimizes the risk of failure

Accelerate Recovery: The ability to automate self-recovery is provided. A support flow

control and dependency tracking accelerates the process.

TIBCO Adapters

TIBCO Adapters enable packaged applications, networking technologies and databases to take

part in the enterprise information flow. Frequently, an organization has several custom

applications and uses different technologies and need the access to databases. Those

resources are reused and coordinated producing services and achieving the time-to-market and

the IT costs. For accomplishing this, the adapters enable the IT assets to communicate inside

the information flow.

TIBCO ActiveMatrix Adaptors for Enterprise Integration allows connectivity for a broad range of

technologies including [TIB-ADP]:

Packaged applications: SAP R/3, Siebel, PeopleSoft, Oracle E-Business Suite,

Salesforce.com, Lotus Notes, SWIFT, Kenan/BP, Portal Infranet, Clarify, and others

Databases: Oracle, SQL Server, Sybase, Teradata, DB2 UDB for Unix, DB2 for z/OS,

and DB2 for i5/OS

Mainframe and i5/OS technologies: CICS, IMS, DB2, VSAM, dataset files for z/OS and

RPG program objects, Data Queues, and SPOOL files for i5/OS

Other standards and technologies: EJB, Files, LDAP, MQSeries, Tuxedo, COM, and

CORBA

Custom integration: Java and C++

7.4.2 Solution architecture.

TIBCO ActiveMatrix BusinessWorks is an integration platform that allows the design and

developing of business process of the integration projects. The business process should receive

and send data in a transparent way. For the definition of business processes it uses the TIBCO

Designer graphical user interface (GUI). TIBCO ActiveMatrix BusinessWorks process engine is

used for the execution of the business process [TIB-CON].

TIBCO Administrator is a web GUI for monitoring and managing run-time components of the

integration platform.

TIBCO ActiveMatrix BusinessWorks is able to connect to applications of different types, such as

databases, CORBA, EJB, trading partners, .NET, ERP, custom applications, J2EE and




exchanges, etc. This lets using TIBCO ActiveMatrix BusinessWorks to integrate all aspects of a

system that are wanted to be integrated.

An important aspect for the architecture is the TIBCO administration domain. Administration

domain is a “collection of users, machines and TIBCO ActiveMatrix BusinessWorks components

that a TIBCO Administration Server monitors and manages” [TIB-ACT]. The administration

domain is the administrative boundary or an integration system and the components inside an

administration domain can communicate with other systems that aren’t inside it.

TIBCO administration domain offers a run-time monitoring and management and the security

implementation.

Architecture for FutureID

The following components for the FutureID integration must be considered.

At the center it would be the business process, which would interact with the Applications

within the Service Provider and with the components of FutureID that participates in the

Authentication process.

The User Agent (UA) connects with the business process by means of UA Adapter

The FutureID Application Integration Services (AIS) will include an adapter which

transforms the SAML assertions and sends them to the business process.

The Figure 8 shows the integration architecture using TIBCO. There is two parts, the part

corresponding Service provider, which contains the TIBCO components and the Applications

and the remainder components of FutureID.




Figure 8: TIBCO architecture integration for FutureID components.


The core solution product is TIBCO ActiveMatrix BusinessWorks™ which was described in

solution overview section as “a robust and highly scalable platform that can be used to develop

new services, automate business processes, and integrate applications.” [TIB-ACT]

TIBCO ActiveMatrix BusinessWorks contains the following components [TIB-CON]:

The TIBCO ActiveMatrix BusinessWorks engine which performs the running of the

business processes at run-time (and also in test mode)

TIBCO ActiveMatrix BusinessWorks Service Container which performs the

simultaneous hosting of multiple applications. The number of applications that can run

depends on processes running on each process engine and the deployment

configuration.

The resources to TIBCO Designer for creating business processes are provided by

TIBCO ActiveMatrix BusinessWorks design-time plug-in. The design of TIBCO

ActiveMatrix BusinessWorks was made using a plug-in architecture.

Special plug-ins can be installed separately, for example TIBCO BusinessWorks EJB

Plug-in that allows working with Enterprise Java Beans (EJBs).

The following products are prerequisites of TIBCO ActiveMatrix BusinessWorks:




TIBCO Runtime Agent (TRA) provides libraries (both at design-time and runtime) used

by TIBCO ActiveMatrix BusinessWorks and other TIBCOproducts. This includes software

such as TIBCORendezvous.

TIBCO Designer is a graphical user interface (GUI) installed as part of TRA. TIBCO

Designer provides a design-time environment that lets the process design, adapter

configuration and testing.

TIBCO Administrator supports deployment, security administration, and monitoring and

management of processes and machines. TIBCO Administrator consists of the web

application based TIBCO Administrator GUI and the TIBCO Administration Server.

TIBCO ActiveMatrix Policy Manager lets the definition of security, auditing, logging and

service level agreements polices in a centralized way. This allows organizations to apply policies

uniformly across all services apart of the location or underlying technology such as Java or .NET

or in custom and packaged applications.

7.4.4 Existing Identity or Federated Identity Functionality.

The TIBCO administration domain will address the security implementation. TIBCO

administration domain was introduced in Solution architecture section. TIBCO administration

domain also administrates the domain monitoring and management [TIB-CON].

The TIBCO Administrator Server monitors and manages a TIBCO administration domain. There

is one TIBCO Administration Server for every TIBCO administration domain.

Regarding security issues, the TIBCO Administration Server offers centralized authorization and

authentication. The authorization is the permission for viewing or executing, and the

authentication is the verification of the identity of a person or process. So the Federated identity

functionality should be performed by the TIBCO Administration Server.

The users with full administrative privileges define the users that can have access rights to the

functionality of the product needed and the type of access rights. The TIBCO Administration

Server controls the accesses for the users. The TIBCO Administration Server manages the

authentication and authorization of data stores and components (adapters and business

process) in the administration domain for TIBCO ActiveMatrix BusinessWorks, for example the

authorized users are the only one that can stop process or adapters.

TIBCO ActiveMatrix Policy Manager offers a uniform policy management for different

technologies and architectures. TIBCO’s proxy-based agents can manage any service including

external services that are hosted on application servers. TIBCO ActiveMatrix™ Administrator

console can use several policy templates included in ActiveMatrix Policy Manager to configure

policies including authentication, authorization, encryption, digital signatures, credential




mapping. The policy provisioning into the endpoints is made automatically identifying the needed

policies to be deployed to every distributed node.[TIB-POL]

7.4.5 Solution Protocols.

TIBCO ActiveMatrix BusinessWorks is based on messaging standards and supports standard

protocols such as SOAP and WSDL for Web services and HTTP, HTTPS, TIBCO Rendezvous

and JMS.

ActiveMatrix Policy Manager supports important third-party LDAP and identity management

systems and security standards and protocols such as WS-Security, XML Signature, XML

Encryption, and SAML. [TIB-POL]

TIBCO provides Web services integration and a platform for the management of this integration.

TIBCO lets the creation of Web services for the systems to integrate and real-time access to

Web services-based information and interfaces.

TIBCO participates in leading standards bodies, for example OASIS, W3C and WS-I.

Area Specification TIBCO Leadership

Alerts/

Notifications WS-Notifications

Co-author and member of technical committee

TIBCO driving consolidation of WS-Eventing and WS-BaseNotification

BPM

WS-BPEL (formerly known

as BPEL4WS)

Member of OASIS technical committee and key contributor

WS-Choreography Supporter

Description

WSDL 2.0

Co-editors Pushing for the inclusion of

sophisticated message exchange patterns

WSDL 1.1 Supporter

WS-MetadataExchange Member of working group

UDDI Supporter

WS-Policy Supporter





WS-RF Supporter

Events WS-Eventing Co-author

(w/ Microsoft BEA, IBM, Sun)

Interoperability WS-Interoperability Member of committee

Java

Business

Integration

JBI (JSR 208) Member of working group

Management/

Monitoring

WSDM (Distributed

Management)

Member of OASIS technical committee.

Based on WSMF, co-authored by HP and TIBCO

Messaging WS-ReliableMessaging

Co-author (w/ Microsoft, IBM, and BEA)

WS-Addressing Supporter

Presentation WSRP (Remote Portlet) Member of technical committee

Security WS-Security Charter and voting member of OASIS

technical committee

Service Invocation

SOAP 1.2 Key participant of working group Have obtained 100% interoperability

SOAP 1.1 Supporter

SOAP with Attachments

(SwA) Supporter

Transaction WS-CAF Supporter

WS-Transaction Supporter

Transport HTTP Supporter

JMS Supporter





XML

XML Schema Supporter

XML Core Supporter

XSLT Supporter

Table 5: Standards bodies in which TIBCO participates, taken from [TIB-WS]

Regarding the standards for Business Process Management, TIBCO participates to define

standards and interfaces for workflow, also TIBCO is a founding member of the Workflow

Management Coalition (WfMC). The process definitions that are created by TIBCO Business

Studio™ use the XML Process Definition Language (XPDL) [TIB-STA].

TIBCO Business Studio uses BPMN (Business Process Modeling Notation) for defining business

processes in its BPM solutions. BPMN is a popular notation for defining business processes.

WS-BPEL 2.0 is supported by TIBCO ActiveMatrix BusinessWorks™ BPEL Extension is a

release from OASIS WS-BPEL technical committee, which was more suited to SOA that

involved human interaction. BPEL specification is evolving to the solutions WS-BPEL4People

and WS-Human in order to support application in a fuller BPM solution and TIBCO is

participating.

TIBCO Business Studio provides a UML (Unified Modeling Language) class diagram editor that

may be used to define the data that participate in business processes.

For B2B integration, TIBCO offers solutions for connecting enterprises using a wide collection of

business protocols such as RosettaNet, UCCNET, EDI-INT and ebXML. TIBCO offers

interoperability for AS2 EDI/XML messaging over the internet, and can process and integrate

any EDI or XML message formats such as ANSIX.12, EDIFACT, SWIFT, HIPAA, etc. TIBCO

also provides support for EDIINT, AS1, AS2, and others standards sponsored by industry

consortiums. Using value added networks (VANs), TIBCO can provide indirect connectivity to

enterprises. The major VANs are GEIS, IBM, Tradanet and Sterling.

For the enterprise servers area, the integration of these systems is important as 70% of the

corporate data is residing on them. The standards supported by TIBCO include IMS, CICS,

OS/390, AS/400, DB2, COM, CORBA, and MQSeries, providing messaging software and

adapters.




7.5 Microsoft


BizTalk is the EAI solution of Microsoft. It follows a “Publish & Subscribe” methodology, where

information is placed onto, and removed from, a Service Bus which acts as a common conduit

for messages. BizTalk Server receives messages from this bus and then processes them before

republishing them for consumption. (See Figure 9)

Figure 9: Microsoft BizTalk Solution

BizTalk has a number of adapters which enables communication with the Service Bus.




While specific adapters can be built for BizTalk using a toolkit communications is more simply

handled by the Windows Communications Foundation (WCF). WCF can manage a number of

different communications through its own adapters.

Microsoft BizTalk Server R2 utilizes WCF as a communication technology. BizTalk is designed

to receive and transform data from one standardized format to another. Messages must be

delivered to its central message box where the message can be transformed using either a strict

mapping or by using one of the BizTalk features such as its workflow engine. BizTalk can use

the WCF Line of Business (LOB) adapter [MS-01] to deliver messages to the message box

protocols including those related to Identity Federation.

FutureID should communicate with the Windows Communications Foundation.


7.5.2.1 BizTalk Process

XML Files come from the Service Bus via the Receive Ports and are passed to the "Message

Box" through a "Receive Pipeline". They are then picked up by "BizTalk Orchestrations" and are

processed. Custom rules may be loaded and executed at this point. The processed messages

are then sent out using the Receive Pipeline, through the "Send Port" to the Service Bus.

7.5.2.2 Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) is a framework for building service-oriented

applications. Using WCF, you can send data as asynchronous messages from one service

endpoint to another. A service endpoint can be part of a continuously available service hosted by

IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that

requests data from a service endpoint. The messages can be as simple as a single character or

word sent as XML, or as complex as a stream of binary data. [MS-02]

WCF combines the earlier disparate programming models into a single service-oriented

programming model. Before WCF, software developers had to pick from numerous technology

choices in order to create and expose services that could be consumed in a distributed

environment. While developers chose web services for interoperability and Microsoft Message

Queuing (MSMQ) for reliable messaging, they used Enterprise Services for transaction

management, .NET Remoting for high performance systems and Web Service Enhancements

(WSE) for secure messaging, resulting in the same logic being duplicated when the component

had to be exposed over multiple channels.

At a high level, every WCF service consists of the following three parts:

1. The Service Contract that defines 'what' the service does and a service class that

contains the implementation for the service.




2. Configuration files consisting of bindings (the 'how' part) and endpoints (the 'where' part)

that define the way clients access the WCF service. These configuration files are

independent of implementation. The binding specifies how a client communicates with

the service in terms of transport and other attributes. The endpoint specifies the address

at which this service is exposed to clients.

3. A process that hosts the service implementation so that it can be invoked from client

applications.

WCF includes the following set of features. For more information, see [MS-03]

Service Orientation

One consequence of using WS standards is that WCF enables you to create service

oriented applications. Service-oriented architecture (SOA) is the reliance on Web

services to send and receive data. The services have the general advantage of being

loosely-coupled instead of hard-coded from one application to another. A loosely-coupled

relationship implies that any client created on any platform can connect to any service as

long as the essential contracts are met.

Interoperability

WCF implements modern industry standards for Web service interoperability. [MS-04]

Multiple Message Patterns

Messages are exchanged in one of several patterns. The most common pattern is the

request/reply pattern, where one endpoint requests data from a second endpoint. The

second endpoint replies. There are other patterns such as a one-way message in which

a single endpoint sends a message without any expectation of a reply. A more complex

pattern is the duplex exchange pattern where two endpoints establish a connection and

send data back and forth, similar to an instant messaging program. For more information

about how to implement different message exchange patterns using WCF see Contracts

in [MS-05].

Service Metadata

WCF supports publishing service metadata using formats specified in industry standards

such as WSDL, XML Schema and WS-Policy. This metadata can be used to

automatically generate and configure clients for accessing WCF services. Metadata can

be published over HTTP and HTTPS or using the Web Service Metadata Exchange

standard. For more information, see Metadata [MS-06]

Data Contracts

Because WCF is built using the .NET Framework, it also includes code-friendly methods

of supplying the contracts you want to enforce. One of the universal types of contracts is

the data contract. In essence, as you code your service using Visual C# or Visual Basic,

the easiest way to handle data is by creating classes that represent a data entity with

properties that belong to the data entity. WCF includes a comprehensive system for

working with data in this easy manner. Once you have created the classes that represent

data, your service automatically generates the metadata that allows clients to comply




with the data types you have designed. For more information, see Using Data Contracts

[MS-07].

Security

Messages can be encrypted to protect privacy and you can require users to authenticate

themselves before being allowed to receive messages. Security can be implemented

using well-known standards such as SSL or WS-SecureConversation. For more

information, see Windows Communication Foundation Security. [MS-08]

Multiple Transports and Encodings

Messages can be sent on any of several built-in transport protocols and encodings. The

most common protocol and encoding is to send text encoded SOAP messages using is

the HyperText Transfer Protocol (HTTP) for use on the World Wide Web. Alternatively,

WCF allows you to send messages over TCP, named pipes, or MSMQ. These messages

can be encoded as text or using an optimized binary format. Binary data can be sent

efficiently using the MTOM standard. If none of the provided transports or encodings suit

your needs you can create your own custom transport or encoding. For more information

about transports and encodings supported by WCF see Transports in Windows

Communication Foundation. [MS-09]

Reliable and Queued Messages

WCF supports reliable message exchange using reliable sessions implemented over

WS-Reliable Messaging and using MSMQ. For more information about reliable and

queued messaging support in WCF see Queues and Reliable Sessions. [MS-10]

Durable Messages

A durable message is one that is never lost due to a disruption in the communication.

The messages in a durable message pattern are always saved to a database. If a

disruption occurs, the database allows you to resume the message exchange when the

connection is restored. You can also create a durable message using the Windows

Workflow Foundation (WF). For more information, see Workflow Services.[MS-11]

Transactions

WCF also supports transactions using one of three transaction models: WS-

AtomicTtransactions, the APIs in the System.Transactions [MS-12] namespace, and

Microsoft Distributed Transaction Coordinator. For more information about transaction

support in WCF see Transactions.[MS-13]

AJAX and REST Support

REST is an example of an evolving Web 2.0 technology. WCF can be configured to

process "plain" XML data that is not wrapped in a SOAP envelope. WCF can also be

extended to support specific XML formats, such as ATOM (a popular RSS standard), and

even non-XML formats, such as JavaScript Object Notation (JSON).

Extensibility

The WCF architecture has a number of extensibility points. If extra capability is required,

there are a number of entry points that allow you to customize the behavior of a service.

For more information about available extensibility points see Extending WCF. [MS-14]








The use of WCF and BizTalk is illustrated in Figure 10

Figure 10: Microsoft EAI solution for FutureID


Microsoft Biztalk R2

Microsoft Windows Communication Foundation

Microsoft Windows Communication Foundation Line of Business Adapter SDK


WCF provides support for Web services (WS) infrastructure protocols through channels and

Web services application protocols through the contracts feature. Interoperability for application




protocols is accomplished through XML Schema description language 1.0 (XSD) and Web

Services Description Language (WSDL) 1.1.

Infrastructure protocols interoperability is provided by the WS-* specifications. WCF channels

provide support for a number of WS-* infrastructure protocols. WCF channels are configured

using binding elements. The following subsection contains the full list of the WS-* infrastructure

protocols implemented by various WCF binding elements.


Windows Communications Foundation supports the following specifications:

HTTP 1.1

SOAP 1.1 HTTP Binding

SOAP 1.2 HTTP Binding

XML

SOAP 1.1

SOAP 1.2 Core

WS-Addressing 2004/08

W3C Web Services Addressing 1.0 – Core

W3C Web Services Addressing 1.0 - SOAP Binding

W3C Web Services Addressing 1.0 - WSDL Binding

W3C Web Services Addressing 1.0 Metadata

WSDL SOAP1.1 Binding

WSDL SOAP1.2 Binding

XOP

MTOM + SOAP1.2 Binding

MTOM SOAP 1.1 Binding

MTOM WS-PolicyAssertions

WSS: SOAP Message Security 1.0

WSS: Username Token Profile 1.0

WSS: X.509 Token Profile 1.0

WSS: SAML 1.1 Token Profile 1.0

WSS: SOAP Message Security 1.1

WSS Username Token Profile 1.1

WSS: X509 Token Profile 1.1

WSS: Kerberos Token Profile 1.1

WSS: SAML 1.1 Token Profile 1.1

WS-Secure Conversation

WS-Trust 1.4




WS-SecurityPolicy 2005/07

WS-ReliableMessaging 1.1

WS-Coordination

WS-AtomicTransaction

Further details and links can be found at [MS-15]

7.6 SAP


There is very little detailed information about Netweaver that is easily available. In general,

technical information is distributed in the SAP Community Network and among Value Added

Resellers. There is the briefest of non-technical overviews on the SAP main portal. [SAP-01]

SAP Netweaver is intended to integrate the SAP Business Suite and external services and users

rather than a middleware tool that can deliver EAI in a more general environment.

The overall architecture for Netweaver reflects this focus (see Figure 11). Identity issues are

addressed in the ‘People Integration’ modules




Figure 11: Overall architecture for Netweaver

There are two relevant ’People Integration’ modules that Netweaver might use for connecting to

FutureID:

Netweaver Gateway.

The Netweaver Gateway directly connects users and provides secure access to SAP

systems via a number of types of channels such as social or collaboration platforms,

mobile devices, and Web applications. It provides its own mobile device client software

when needed.

Netweaver Identity Management v7.2 [SAP-02]

Netweaver Identity Management provides a number of services such:

Role Management and Workflows

Business-Driven Identity Management

Compliance, Reporting, and Auditing

Password Management

Identity Virtualization

Connectivity and Services

Identity Federation and Web-Based Single Sign-On

Database support





Figure 12: Solution architecture using SAP


SAP Netweaver 7.2

SAP Netweaver Identity Management

SAP Netweaver Gateway


Federation in SAP NetWeaver Identity Management 7.2 [SAP-03]

SAP Netweaver Identity Management federation enables SSO for web browser based

access (user-centric) and web services (system centric) across domains.




SAP’s solution relies on standards for interoperability between SAP and non-SAP

systems

For Web browser-based access, identity federation uses an identity provider that

supports: SAML 2.0.

For Web services, identity federation uses a security token service (STS) that supports:

WS-Trust 1.3, supporting X.509, SAML 1.1, and SAML 2.0 tokens.


Table 6 shows the supported specifications and APIs for this product.

SAP Netweaver 7.2 Supported Specifications

SPML

LDAP

ODBC / JDBC / OLE-DB

RFC

LDIF files

XML files

CSV files

SAML 1.1 and SAML 2.0

X.509

WS-Trust 1.3.

Table 6: SAP Netweaver 7.2 Supported Specifications




8. Federated Identity management for EAI infrastructures

8.1 EAI and B2B integration

Enterprise Application Integration (EAI) is often confused with Business-to-Business integration

(B2Bi). Therefore we want to separate those approaches to get a better view on the subject.

Following the discussion in [IRA-2003] EAI projects can generally be put into one of three

categories:

1. Intra-organisational EAI

2. Hybrid EAI

3. Inter-organisational EAI

This taxonomy, allows for the application of the EAI concept, beyond organisational lines. Intra-

organisational EAI, hereby incorporates the classic view on EAI, such as the integration of

packaged systems (e.g. ERP systems), and legacy applications. The Hybrid EAI, provides B2C

capabilities, such as e-services and e-stores, while the inter-organisational EAI, integrates

loosely coupled inter-organisational information systems along the value chain (extended

enterprises), and tightly coupled inter-organisational information systems (virtual enterprises).

Therefore an EAI project can for instance combine the customer accounts system with order

management system of a company, or integrate systems or enterprise application infrastructures

of other companies along the value chain. Figure 13 provides an example of an intra-

organisational EAI project. The figure shows, that multiple business units can use information

systems of other business units, through data and application integration in a centralized

integration infrastructure. Details of EAI systems can found in the introductory parts of this

document.




Figure 13: An example EAI project (MACom) [IRA-2003]

In the literature, inter-organisational EAI, is often compared with Business-to-Business

integration (B2Bi). E.g. [KEL-2002] argues, that EAI must be distinguished from B2Bi, since EAI

mainly focuses on the integration of applications inside a company, while B2Bi mainly focuses

on supporting transactions between organisations. However, [KEL-2002] admits that even EAI

tools, such as the Microsoft BizTalk Server [MICROSOFT-2013] do not completely follow this

approach, since they also provide capabilities for inter-organisational integration. This may be

due to the fact, that outsourcing strategies, such as the “extended workbench” [BUC-2009],

create new advantages, between classical value chain approaches, requiring EAI tools to

provide capabilities beyond organisational borders. Since the application integration service,

shall support a wide range of possible applications, and thus also inter-organisational

integration, we will in the following stay with the taxonomy as provided in [IRA-2003].

8.2 Standards for inter-organisational EAI

Both, B2B according to [KEL-2002] and inter-organisational EAI [IRA-2003] offer advantages,

when handling transactions between organisations, enabling inter-organisational collaboration,

by reducing transaction costs, and making market oriented organisation possible according to

the move-to-market hypothesis [PIC-2003].

In order to reduce the costs of the required transactions in inter-organisational collaboration,

Electronic data interchange (EDI) provides a standardized communication protocol. EDI has its

origins in the sixties when companies defined message formats for specific communications.




Later standards were introduced. The oldest and probably well-known is the SWIFT standard.

SWIFT stands for Society for Worldwide Interbank Financial Telecommunication and is the

name of a company in Belgium. This standard is widely applied in the finance sector, where it

connects than 10000 banks with different hard- and software. Currently there are 15 million

messages sent around per day. SWIFT defines messages for wire transfers, letter of advice,

credit and security transactions.

Another standard for integration came into life in 1988. UN/EDIFACT is an international

standard for EDI. During the years EDIFACT has grown into a complex set of rules and was later

broken into section specific pieces. Right now there are subsets for high-tech industry

(EDIFICE), for telecommunication (EDIS), automotive industry (ODETTE) as well as others. The

transfer of EDIFACT messages is independent of the underlying channel. While in the nineties it

was common to use floppy disks or magnetic tapes, nowadays the messages are sent using E-

Mail, FTP or X.400.

8.3 Identity Management for intra-organisational EAI

Identity management (IdM) cares about information about specific users of IT systems. This is

information about the identity of that user, authorizations and also information about the user

itself.

IdM is currently not in the scope of EAI systems. From a historic perspective software was

developed in a standalone manner. This means that components for IdM have completely

different realisations. Usually the data model is designed independent from one software to

another. So we have different names in attributes also syntax and semantics. Those differences

are one main obstacle for usage in an EAI environment.

We saw some approaches for standardisation in the past. The IETF issued two RFCs which

defined object classes posixAccount and inetOrgPerson for a central LDAP environment. Liberty

Alliance works on personal and employee profiles. They try to establish models for information,

function and communication. At the moment it is not clear if those profiles can be applied to

other environments.

Since EAI aims at data and / or application integration the supporting IdM must be capable of

handling quite a complex superset of data formats, and provisioning techniques. Figure 14

provides an abstracted example of the application integration as shown in Figure 13. Here,

enterprise resource planning (ERP), computer aided design (CAD), and a customer relationship

management (CRM) systems are integrated along intranet applications, each yielding identities

from its’ own identity provider (IdP). If we assume, that the ERP, CAD, and CRM system each

uses their own IdP, the identity management in the enterprise must be capable of handling and

mediating between the different identities. Additionally the identities might be provided in

different formats, e.g. the ERP, CAD, and CRM system might use simple credentials, such as




username / password, while the intranet application might use a smart card with an underlying

public key infrastructure (PKI). This adds to the complexity of IdM in intra-organisational EAI.

Figure 14: IdP issue when integrating applications from different business units (Abstraction from Figure 13)

Section 7 provides an analysis of different EAI systems, in which we learned, that only some EAI

systems provide IdM capabilities (e.g. Oracle Fusion Middleware, IBM Websphere), which are

able of aggregating the identities of the packaged and legacy systems. In the case of the Oracle

Fusion Middleware, these capabilities even include federation capabilities, able of supporting the

different IdPs, and enabling Single Sign On (SSO) in the Enterprise Bus. IBM WebSphere in

connection with IBM Tivoli Federated Identity Manager also offers a wide range of federation

capabilites. Like Oracle Fusion it supports different IdP, offers federated SSO and Where are

you from?. Yet other systems, like TIBCO's ActiveMatrix, may not include such solutions for IdM.

Therefore we can conclude for the case of intra-organisational identity management, that a fIdM

system must include the following cases.

Case 1 – Integration

If the Enterprise Bus / EAI system already includes an IdM system, this system can provide

authentication using two different strategies. Either by federating between the Identity Providers

of the packaged and legacy applications, or by centralizing the identity provisioning and offering

the authentication, not on application, but on Enterprise Bus / EAI system level. In both cases, it

may be reasonable to connect to the already existing IdM systems, e.g. in order to support

further enhancement of the EAI towards inter-organisational integration. If the IdM is being

provided through federation, this case might not yield strong relevance for application in intra-

organisational EAI. Yet, if the IdM capabilities are provided by central provisioning of the

identities through the Enterprise Bus / EAI system, the next case offers potential for applying

federated identity management (fIdM) in EAI.

Case 2 – Federation

The Enterprise Bus / EAI system might already include IdM capabilities. In the first case, we

briefly introduced a scenario, where the EAI system / Enterprise Bus, enables authentication on

Enterprise Bus / EAI system level, by using one centralized IdP of the EAI system / Enterprise




Bus. Yet, this approach might yield some issues. Figure 15 shows an abstracted version of

Figure 13, where the Business Unit administering some of the applications, has been substituted

by a central IT department. This figure includes 5 packaged applications, an ERP, CAD, CRM,

and BI system, as well as a random Intranet application. Above we already discussed the issue

of identities of different origins. However, in this case we may argue, that this issue is being

confronted by implementing one central identity provider at the enterprise bus (e.g. as in IBM

Websphere, Oracle Middleware without fIdM). This would ease the authentication and the

provisioning by including one single workflow for the authentication and provisioning. This would

also enable personnel to be assigned to these specific tasks. Yet, the authentication could not

take place on application level, but only on the level of the Enterprise Bus, requiring a central

business unit to take care of e.g. Access Management.

Figure 15: Intra-organizational EAI and possible authentication workflows, without fIdM

While this approach is reasonable, and widely implemented, e.g. in Best Practices for Service

Management, such as ITIL [TSO-2011] which foresees one centralized institution for access

management, it takes away agility from the business unit. This might make sense, for very static

systems, e.g. enterprise resource planning systems (ERP), where resource access usually

orients on a departmental focus. Yet, in the case of e.g. Business Intelligence (BI) systems, this

might yield problems, since such systems require very context specific information access. For

example, [KOC-2013] argued, that the majority of employees responsible for operative tasks, do

not receive sufficient information required for executing their tasks. Best agility and dynamics in

the identity provisioning, would in this case be achieved by mandating the corresponding




Business Unit(s), which is / are using the system, with the mandate for identity provisioning,

taking away parts of the authentication from the Enterprise Bus / EAI system, and requiring

mediation between multiple identity providers.

Without federated identity management, such a situation would lead to multiple provisioning and

authentication workflows, as shown in Figure 15. In order to face this complexity, introducing

federated identity management may aid by mediating between the identity providers of the

packaged systems.

These cases show so far some potential cases for federated identity management in the case of

intra-organisational EAI. Yet, outsourcing strategies, such as the “extended workbench”, have

led to a change in enterprise structures. Value chains are organised partly (or in the case of the

automotive sector, mostly) in so-called virtual companies and company networks, creating a

circle of trust, of stakeholders in a certain endeavour. These groupings of legally independent

organisations usually collaborate for a limited time. In such an ecosystem, identity management

systems have to face new issues, since authentication is required beyond organizational

borders, in order to enable secure collaboration. Additionally inter-organisational EAI, yields the

capabilities for creating these virtual enterprises, and extended workbenches, since they are

able to decrease transaction costs [PIC-2003], making such organisation forms viable.

8.4 Federated Identity Management in inter-organisational EAI

In order to provide a clear view on the capabilities provided by federated identity management

(fIdM) for Enterprise Application Integration infrastructures, a broader view on the business

perspective is required. As the main goal of EAI is the integration of application in order to

provide a homogeneous view on the integrated information systems from the business

perspective, the business using these information systems plays a key role for successful EAI.

Therefore, in order to illuminate the role of fIdM for EAI current business trends, such as

Outsourcing must be considered.

Outsourcing strategies, such as the “extended workbench”, provide distinct advantages for the

brand owner, by making use of economies of scale, specialization, access to new markets, and

mitigation of currency changes [BUC-2009]. This often results in an organizationally fragmented

value creating chain, or value creating network, in which multiple stakeholders are operating as

a virtual enterprise. However, these cooperation forms challenges to authentication and

authorization of users.




Case 1: Enterprise Application Integration in Corporate Groups

Corporate Groups mostly comprise out of different business segments. The created structures

allow for different organizational methods, regarding the usage of IT resources and, thus the

responsibility and administration of applications. In the case of the Lufthansa Group, a federated

structure was being implemented, introducing a centralized IT division at the Lufthansa Group,

as well as local IT divisions [FAK-2008] (see Figure 16). This structure results in centralized and

decentralized IT services. This means, that some applications, may be used, administered and

provided locally in the division, while some centralized applications are provided for the

divisions, by the headquarter.

Figure 16: Organizational Structure of the Lufthansa Group. Created from [FAK-2008]

When applying an EAI infrastructure to this organizational structure, this allows for two potential

strategies:

1. Distribution

Establishing an Enterprise Application Infrastructure locally at the divisions and

integrating centralized services provided by the headquarters as external

applications

2. Federation

Establishing a centralized Enterprise Application Infrastructure at the headquarter

and integrating the applications provided by the divisions as external applications.

Regarding the Identity Provisioning, there are also two different strategies possible:

1. Centralization of the IdP

Providing the Identity from a centralized IdP for all divisions

2. Distribution of the IdP

Each division holds an own IdP




The distribution of the IdP hereby eases the organizational complexity required for provisioning,

since identity data can be provided and administered locally. Additionally this approach reduces

required transactions during identity provision and access control, with the headquarters.

However, when coming to the handling of the Enterprise Application Infrastructure, both the

Distribution of the infrastructure, as well as the federation infrastructure, require access, and

thus access control to applications apart from those found at the headquarters / the divisions.

Regardless of the strategy used in placing the IdP in this structure, both cases will increase

transaction costs, if access has to be granted using various IdP, or various Service Providers

(SP), which in this case are given by the applications. A federation of the access management,

however reduces these transaction costs [HUN-2010].

Case 2: Federation in a Circle of Trust

The automotive industry forms such a value creating network. In [HUN-2010] federated identity

management was regarded in the case of a circle-of-trust, meaning virtual enterprises as

described above. In such enterprises federation becomes a key component of a successful

identity management, since it supports the Identity Providers of each organization, and treats

each organization as a service provider (in the case of EAI, providing the information systems)

[HUN-2010]. Figure 17 shows such a scenario, in which multiple organizations collaborate

forming a virtual enterprise. Each enterprise hereby acts as an identity provider (IdP), for its own

resources, holding a dedicated identity and access management (IAM). The information systems

are distributed over the various organizations, and bundled using an enterprise application

integration (EAI) layer for the virtual enterprise. The business processes, which depict an

abstract value creating chain, use this EAI layer, and its integrated e.g. harmonization features in

order to access and use the resources (in this case the information systems).




Figure 17: Scenario of fIdM in organizationally fragmented value chains. (Processes are pictured above, information systems at the bottom. The EAI layer is in the middle)

In order to enable authentication in this scenario, two possibilities can be used. The first one,

would be by providing a single sign on system, along with a centralized identity provider.

However, this would require all included organizations to outsource information on their

employees’ identities, such as credentials, creating a potential security threat for each company.

The other possibility is to integrate an additional federation layer, which hands over the

authentication to the identity provider of the organization. This enables a standardized

authentication method throughout the virtual enterprise, while maintaining organizational

security.

Case 3: Federation for Cloud Service Integration

Cloud Services may provide additional applications to be included in EAI. When regarding the

concept of an Enterprise Service Bus, along with Workflow support, e.g. by execution languages

such as the Business Process Execution Language (BPEL), Integration of Cloud Applications is

technically possible. Additionally, concepts such as pay-per-use, accompanied by such services

may provide costs benefits. However, security and legal issues have to be considered when

using such services [BOS-2013] [HEW-2010] [HUN-2011]. Access Management, and thus

federated identity management may provide a key for solving such issues. By controlling the

resource usage, control of data transmitted is possible. Additionally legal liability issues can be

solved, due to the traceability of the access. However, access management with external

services, such as Software (provided) as a Service (SaaS), Infrastructures (provided) as a

Service (IaaS), and Platforms (provided) as a Service (PaaS), can be complex due to the




amount of connections and services to be considered. Additionally the different accounts,

involved in using various external services might result in security issues, by password-reuse

and handling [MAD-2008]. Additionally the requirements to IdM are changing when coming to

cloud applications. In order to use the advantages of cloud applications, such as dynamic

deployment / undeployment, and pay-per-use, new challenges to the Identity Lifecycle rise

[GOP-2009]. The following list provides an overview to the of the identity lifecycle regarding

cloud computing:

- Provisioning / Deprovisioning

In order to be able to benefit from the dynamics provided by cloud services [ARA-2010]

provisioning must be provided “on- demand” or “just-in-time” [GOP-2009]. The

deprovisioning on the other hand, must be provided “just-in-time” in order to revoke

access, once the service is no longer foreseen as application [GOP-2009]. A possible

solution for this requirement could be the integration of the service provisioning markup

language (SPML) [OASIS-2006], which allows automation, and thus meeting of the “on-

demand” or “just-in-time” requirements [GOP-2009].

- Proliferation of On-demand User Ids

A possible security issue occurring regarding user identities at cloud services, is the

scenario of one user having multiple identities associated with the same service provider.

[GOP-2009] propose for this specific scenario the usage of a concept, such as OpenID

[OPENID-2010]. However, as [GOP-2009] note, the trust propagation, as well as the

development of a trusted relationship to an external identity provider can be problematic.

Federation of the identity management can solve this problem by intermediating between

external IdPs and internal credential data. Hereby the federation layer could provide mediation

between the IdP accompanied with the EAI, and the Service Providers, which in this case are

the cloud providers. Figure 18 provides such an example of fIdM for cloud service integration. In

this scenario the external applications are accessed using a federation layer (in this case the

FutureID architecture), which mediates between the IdP in the organization and the cloud

services.




Figure 18: Federation Scenario for Cloud Service Integration

As mentioned above, the proliferation of identities can be problematic with cloud providers. The

in [GOP-2009] suggested usage of external identity providers, such as OpenID [OPENID-2010]

yet might not be a solution for enterprise application integration, since this the required trust

propagation and buildup of a trust relationship level, would create additional security and legal

issues, since the identities are accompanied by person based data [HEW-2010] [BOS-2013].

However, the central IdP in an organization offers similar functionality, reducing this issue to the

issue of provisioning. Here we can distinguish between federated and centralized provisioning.

Centralized provisioning is unproblematic, since the follow-up access management is completely

handled by the fIdM. The process of provisioning and meeting the demands of “on-demand” or

even “just-in-time” provisioning in this case may be subject to the implemented organizational

processes surrounding the internal provisioning, and thus out of the scope of FutureID.

However, in the case of federated provisioning, non-automatic synchronization of the

Provisioning, might not be able to meet these demands. In such a case, using SPML [OASIS-

2006] for automatic provisioning and deprovisioning might solve this issue, by automating the

process over multiple parties. [PET-2003] provides an example of such automatic provisioning /

deprovisioning. In this example, an access request, would lead to internal provisioning of access

rights to applications, databases, and directories. Additionally it would trigger a SPML request to

a Cloud Provider, triggering the provisioning of access rights.




Figure 19: Example of automated provisioning using SPML. Modified for Cloud Computing from [PET-2003]

8.5 An Abstract Model for Federated Identity Management and IdM

In the previous section we have illuminated different abstract scenarios for fIdM in EAI. During

this chapter we could identify different characteristics of fIdM, when coming to Enterprise

Application Integration, the Data Integration, Vendor independence, and the common access to

several applications, create distinct characteristics, when coming to multi company corporations,

corporate groups, and the integration of external applications such as cloud applications. These

characteristics are:

- Integration of Application and EAI IdPs

As far as possible, identity providers from both, packaged applications and EAI systems

should be included. However, this may only be possible within the boundaries of known

standards, such as SAML [OASIS-2005], and by communicating with the client.

- Federation of Provisioning

Support / Enabling the Triggering of Provisioning Processes

- Support of Industrial Trust Services

Industrial Service may serve as Identity Providers, similar to OpenID [OPENID-2010],

solving the issue of dissemination of identities for cloud applications. Also, such industrial

trust services ease the issue of trust propagation for organizations.

- Integration of industrial IdPs

Companies should be able to connect their IdP to the FutureID Broker Service, in order

to be able to use the FutureID infrastructure, if required.

This requires support of Industrial Trust Services, Industrial IdPs and Cloud Provider IdPs, by

the Broker Service (see Figure 19). The Enterprise Application Integration Service, should be

able to mediate between application and Enterprise Application Infrastructures, and the




corresponding IdPs through the Broker Service (BS). The federation of the provisioning is not in

the scope of the FutureID architecture. However, supporting this federation could be beneficial

for the enterprise users, since it would allow an easy integration of cloud identity management

into the local identity management. Therefore enabling an easy integration e.g. for SPML

[OASIS-2006] could be a benefit for the FutureID architecture, e.g. by foreseeing optional

interfaces in the interface and component specification of IdB and AIS.

Throughout Section7, we analyzed different EAI systems, regarding their IdM capabilities.

Additionally, we identified in the course of this chapter, that the federated identity management

for EAI, should include the capability to connect to the IdM capabilities of the EAI systems, as far

as possible. The following list provides an overview on the required authentication and

federation protocols for this integration:

- SAML [OASIS-2005]

- WS-Federation [NAK-2006]

- OpenID [OPENID-2009]

- Liberty Identify Framework (ID-FF)

- WS-Trust

- WS-Security

It seems that SAML support is indeed the main common factor. EAI solutions which enable IdM

make use of that protocol. As SAML is a well-established standard it seems safe to assume that

also other solutions will support it. Apart from that there is no common ground. IBM WebSphere

as introduced in Section 7.1 can be connected to the Tivoli Federated Identity Manager. This

solution provides a broad range of IdM protocols starting from SAML to later developments like

Liberty Identity Federation from the Liberty Alliance or others. Oracle Identity Management

provides also a full-service IdM solution. TIBCO ActiveMatrix seems to only support SAML. At

the moment it is unclear, if the standard is fully supported or if TIBCO only uses a subset.

According to these findings SAML support is a must for an easy integration of FutureID into a

EAI architecture. Protocols like WS-Federated are either supported or can easily be integrated.

So it is also appropriate to support this protocol.

Furthermore a wide range of EAI solutions use Kerberos. The Kerberos Network Authentication

Service also provides an IdM within the protocol (MIT Kerberos Consortium 2007). The Kerberos

Authentication Server acts as IdB. LDAP on the other hand is also widely supported. However

the EAI solutions use LDAP only as backend, not as an IdM solution per se. When it comes to

IdM usually LDAP and Kerberos are combined.

So from a technical perspective support for standards the above mentioned SAML and WS-

Federated is a minimum requirement. Furthermore Kerberos support makes it easier to integrate

solutions with no current IdM support.




9. Abstract architecture for composing a set of enterprise services

across a distributed landscape

Analysing the set of EAI solutions in section 7, it turns out that EAI integration of identity

management components mostly consists in preliminary support of common identity

management protocols and techniques (e.g. SAML, OAuth, OpenID, etc.). The analysis

furthermore clearly shows that the intersection set of technologies supported by all EAI systems

investigated is rather limited. Moreover, the claim of “support of SAML protocols”, for instance, is

a rather weak statement, given the complexity of details in SAML implementations and

interoperability. Thus, we consider it to be unfeasible to completely rely on one of these

protocols solely for realizing the FutureID Application Integration Services.

In the following, we thus elaborate on relevant characteristics and requirements for realizing an

explicit FutureID-AIS component that allows for integration of the FutureID architecture in most

of the existing EAI solutions. We therefore propose an abstract architecture that provides the

modules and interfaces required for integrating the FutureID architecture into arbitrary

Applications, as long as these rely on at least one of the protocols implemented into the

FutureID-AIS component.

9.1 Pre-existing Components of the FutureID Application Integration Services

Architecture

In this section we briefly iterate over the components on which the FutureID Application

Integration Services will rely upon. More precisely, we discuss the Applications, the EAI

middleware, the Application Clients, and the central FutureID components involved in the

FutureID AIS operations (i.e. the Identity Broker and its subsidiaries).




9.1.1 Applications (A)

Figure 20: FutureID Environments for Application Integration Services

As shown in Figure 20, the FutureID-EAI relies on the existence of a certain set of services a

priori. First and most important, the Applications implement the functionality intended to be

performed by the service side. Depending on the domain of use, this may range from traffic data

conversion services to medical services in hospital environments to automation services for

robots in a corporation of automotive production.

For FutureID, we do not assume any particular type of Applications, but consider those to

require authenticated information regarding their user’s identity or attributes. Moreover, typically,

Applications also require a certain set of input data from their users, e.g. a patient’s medical

record that is to be analysed, or a set of commands to be executed by a production robot. Most

of these input data are not required to be secured by themselves; the fact that they stem from an

authenticated, authorized, and all-in-all trustworthy source is sufficient for performing the

particular service operations on them.

However, we already foresee the potential need for some of these input data to be verified

externally. For example, production robots require the identity of a command issuer to be

authorized, and may internally keep track of which operator issued which commands. In this

case, the input data regarding identity has to be verified. Equivalently, patient’s data given as

input to a medical service may be trusted, but only if the data source is able to trustworthily claim

to be a doctor.




In each of these cases, the Applications require verified data as input. The first challenge of the

FutureID-EAI hence is to guarantee that this verification is performed prior to invocation of the

Applications.

9.1.2 EAI Integration Services (EAI)

Besides the Applications, we assume some existing EAI middleware to be present at the service

providers. Given that the use of eID solutions mostly happens in the context of large-scale

Applications, e.g. in distributed corporations or among government bodies, we consider this

assumption to be reasonable. It might though be possible to consider a service provider that

solely consists of one or more Applications, hence omitting an EAI middleware completely.

However, in this case, we assume it to be feasible to instantiate a “dummy” EAI middleware that

solely forwards all requests directly to the Applications. Thus, for the general architecture, we

assume the existence of an EAI middleware, which e.g. is based on one of the EAI solutions

investigated in Section 7.

The purpose of these EAI middleware systems consists in integration of several heterogeneous

services into a single workflow, bridging technological borders that may result from using

different platforms, operating systems, data formats etc. Moreover, and more important in terms

of integration of the FutureID architecture, the EAI middleware commonly is also responsible for

including authentication and authorization services into this workflow. Hence, with respect to the

FutureID architecture, the main use of the EAI middleware is the interface to these authorization

services.

9.1.3 Application Client (AC)

Not to be confused with the FutureID Client, the purpose of the Application Client is to provide

access capabilities for the Applications to the user. Depending on the type of service

implemented at the Applications, potential Application Clients include e.g. a user’s web browser

(as a standardized way to access arbitrary website-based services), SSH clients, or highly

specialized and potentially very complex client applications, e.g. for realizing tax calculations.

In any of these cases, if there is need for verifiable information on a user’s identity or attributes,

the Application Client is accompanied with the FutureID Client to provide appropriate

functionality to the user.




9.1.4 Identity Broker (IdB)

Being a core component of the FutureID architecture, the Identity Broker is responsible for

handling all sorts of requests for identification, authentication, or attribute attestation performed

via the FutureID services.

As discussed in [FutureID-D21.3], the Identity Broker component can be deployed in one of

several ways, e.g. within the domain of a service provider, as a dedicated central entity of its

own, as a federated network, or within the FutureID client’s environment as part of the user

domain. It interconnects the FutureID Client, the FutureID AIS component, and the multitude of

eID architectures supported by FutureID. Furthermore, depending on the scenario, its federation

with other instances of FutureID Identity Brokers, or even external identity management

frameworks like STORK-PEPS, is anticipated.

In the context of this document, hence from the point of view of the FutureID Application

Integration Services, we generalize the different concepts of federation of the Identity Broker.

Thus, in the following, when using the term “Identity Broker”, we refer to an organization that

runs several components (a BS, several FSs, a TS and optional CVs) and interacts directly with

the FutureID AIS component.

9.2 The FutureID Application Integration Services Architecture

Throughout Section 8, we established the use of fIdM, in both intra- and inter-organisational EAI.

The model distilled in Section 8.5, shows that in order to support both intra- and inter-

organisational EAI, support of industrial IdPs, application IdPs, and EAI middleware IdPs is

required. Features of the AIS, must thus provide capabilities to allow for the authentication on

application level (both for workflow initiation, and during the workflow), and on EAI middleware

level. The following architecture takes this into account, by providing services for the EAI

middleware, and application client, and the applications.

As discussed in the previous section, the core component of the FutureID AIS is connected to

the Applications, to the EAI middleware, to the Application Clients, and to the FutureID Identity

Broker. Hence, each of these interfaces has to be investigated for the FutureID AIS architecture.

As is shown in Figure 21, each of these interfaces is assigned to a certain module in the

FutureID AIS architecture, which is responsible for its operation. Moreover, there are several

other modules within the FutureID AIS component, all of which are to be outlined below.




Figure 21: Modules and Interfaces of the FutureID Application Integration Services Component

9.2.1 EAI Identity and Authentication Connector (EAI-IdAC)

The EAI-IdAC interfaces the FutureID AIS component towards the EAI middleware and its

subsequent services. The EAI-IdAC is responsible for all interactions between the FutureID AIS

component and the EAI middleware. Most importantly, this covers all interactions between the

FutureID AIS and all authentication and authorization services in place. For example, if the use

of a certain Application requires a valid authentication from an authorized user, the EAI

middleware is responsible for invoking appropriate authentication services present within the

service provider’s architecture. Those authentication services are intended to perform the task of

verifying a service requester’s identity. Hence, obviously, those services then need to interact

with the FutureID architecture for triggering an appropriate authentication process. This is

performed via the EAI middleware, which therefore invokes appropriate services provided by the

EAI-IdAC module.

In terms of technical realization, given that most EAI middleware systems rely on an Enterprise

Service Bus architecture (cf. Section 7), and almost all of them support dedicated service

invocation protocols like SOAP/Web Services and the WS-* specifications, it is considered

reasonable to realize the EAI-IdAC interface accordingly – as a Web Service provided by the

FutureID AIS component towards the EAI middleware.




As a result, for each service invocation request arriving at the EAI middleware from the

Application Client’s side, the EAI middleware invokes its service-specific authentication service,

which then reroutes the EAI workflow towards the EAI-IdAC service interface. Therein, the

FutureID process of identification and authentication is performed, and the result is delivered via

the EAI middleware back to the authentication services. At this stage, hence, the authentication

services hold a verified identity claim, which they can use to subsequently invoke appropriate

authorization services (directly or via the EAI middleware again).1 Subsequently, the request is

either forwarded to the Applications or replied with an error message, again according to the

decisions made within the authentication and authorization services and the workflow of the EAI

middleware.

9.2.2 Application Data Connector (A-DaC)

Assume that a service requester’s request passed the authentication and authorization services

successfully. Hence, the request and all of its internal service input data is considered

trustworthy by the service provider, and is taken as input for the Applications. Sticking to the

example given above, the set of commands given in the request is deployed to the production

robot, or the patient’s medical data is filed in the corresponding Application.

However, in many cases, the Application may need additional verification of certain information

contained within the service request. For instance, if the particular Application must be tailored to

a specific user identity, it becomes necessary to deliver that information from a trustworthy

source towards the Application implementation. To make this point clear, assume a request that

successfully verifies authenticity of user Alice, but in its service input data (which is different from

the username used for authentication) it tries to update data about Bob. Here, it must be verified

that the identity used for authentication is identical to the identity processed within the

Application. Thus, it becomes necessary to provide such verified input data towards the

Applications in a convenient way.

Here, the A-DaC comes into play. Its purpose within the FutureID AIS component is to handle all

communications with the Applications themselves. For the example given above, the task of the

A-DaC would be to provide the identity of the authenticated user (i.e. “Alice”) to the Application,

in such a way that the Applications can compare it to the claim made in the service input data

(i.e. “Bob”). As the data format used for dealing with identities may differ among different

Applications (e.g. some may use email addresses, some may provide user-ID numbers), the A-

DaC has to adapt its information to match the format required by the A.

1 Note that the realization of the authorization services is out of scope of the FutureID architecture.




Despite transforming identity information, the purpose of the A-DaC module also involves

handling of other types of information that require trustworthiness within the Applications. For

instance, verified age information may be required within the Application. The A-DaC then would

be responsible for converting the verified information (verification is performed in the Claim

Interpreter module, see below) into the format required by the Application.

In terms of architecture, the realization of the A-DaC can be performed in one of two ways.

Either, the A-DaC directly provides a service interface towards the Applications, which can be

invoked e.g. with a context identifier token to obtain the verified information.

Or the A-DaC is embedded into the EAI middleware workflow, allowing it to modify the service

request prior to its delivery to the Applications. In this case, the verification of the service input

data fields of relevance is performed within the A-DaC itself, triggering a service request error if

the information cannot be verified, and allowing the service request to proceed (with verified

service input data) otherwise.

Technically, both concepts can be realized by means of service invocation protocols based on

SOAP/Web Services. The key difference would be whether the invocation of the A-DaC services

is performed from within the Applications directly or whether this is part of an EAI middleware

workflow.

The A-DaC should hereby be provided to both the EAI middleware and the Applications. This

allows for the integration of the A-DaC functionalities into EAI workflows, as well as, for the

integration into applications.

9.2.3 AC Connector (AC-C)

The third interface of potential relevance for the FutureID AIS component is that towards the

service requester. It is important to note that this is not the interface to the FutureID client, as

such interaction is always to be performed via the Identity Broker. The task of the AC-C is to

handle all interactions that may become necessary between the FutureID AIS component and

the Applications` client implementation. For instance, in case of a remotely configurable

Application Client interface, the FutureID AIS component might need to configure the Application

Client in such a way that certain types of information are contained within all service requests

(e.g. session identifiers etc.). This might become relevant if the FutureID AIS component has to

authenticate users for more than one subsequent request, and is to be realized by means of

authenticated sessions. In each of such cases, the AC-C is responsible for all interactions

between FutureID AIS component and the Application Client, such as placing an appropriate

session cookie, deriving a shared secret for the SAML-Holder-of-Key profiles (cf. [SAML-HoK])

from a TLS channel, or similar.




9.2.4 Identity Broker Connector (IdB-C)

Being a critical part of the overall FutureID architecture, the interface between the Identity Broker

and the FutureID AIS component is a highly relevant one. On the side of the FutureID AIS

component, it is to be handled via the IdB-C.

Whenever a service request is placed at the EAI middleware and forwarded to any of the

FutureID AIS component modules, these may require interacting with the Identity Broker in order

to verify a claim found in a service request, or to let the IdB choose an authentication scheme to

be used for identity verification. In both of these cases, a certain set of information taken from

the service request must be exchanged with the IdB, in order to allow that component to make

its decisions. This communication is realized via the IdB-C services.

Vice versa, once the IdB has chosen a certain eID protocol and authentication scheme, this

decision has to be communicated back to the EAI middleware, and maybe even back to the

Application Client, in order to configure the provisioning of information required for the particular

authentication scheme. Both these communication channels are established by means of

appropriate services provided by the IdB-C.

A third necessity for communication between the FutureID AIS component and the Identity

Broker is based on the Applications’ need to communicate the type of data it requires to be

verified of its users. If the Application for instance requires verified age information, the Identity

Broker has to incorporate this circumstance in its choice on an appropriate authentication

scheme and eID infrastructure to use. In contrast to the previous two types of communication,

this third channel is not necessarily a runtime communication channel, but merely a

configuration channel. It might e.g. be realized by “registering” an Application and its needs at

the Identity Broker, which keeps an internal repository of these entries. Nevertheless, this

communication has to be automated in some way, and hence is part of the IdB-C.

Technically, for most of the existing authentication and authorization protocols found in EAI

solutions (cf. Section 7), IdB interaction will consist of transmitting a credential token (e.g. a

SAML assertion, a username/password token, a digital signature) that originates from the

Application Client’s side towards the Identity Broker. Such a “request” to the Identity Broker is

then answered with some sort of response, which may fall into one of several categories:

A “request for further input” is issued if the IdB requires additional information for making

its decision on the best-suited eID scheme.

A “protocol selection” message is issued to communicate the eID infrastructure to be

used subsequently.

An “authentication claim response” is sent in answer to a credential token, and may

contain information resulting from the verification task performed on the credential.

An “IdB error” message communicates errors that occurred within the processing of a

request.




Again, as the services provided by the IdB commonly are invoked from within the FutureID AIS

component, the use of XML-based communication protocols like SOAP/Web Services is

recommended.

9.2.5 Claims Interpreter (CI)

In case the FutureID AIS component receives an “authentication claim response” from the

Identity Broker, such a response may contain several different types of information. Depending

on the type of authentication protocol used for the claim and for the response, different additional

tasks at the FutureID AIS component have to be performed. For instance, if the response

contains a SAML assertion statement, a SAML-specific interpretation service has to be invoked

in order to verify its correctness and communicate the result to the EAI middleware or

authentication services of the service provider. For a response to a username/password token

verification request, the result received from the Identity Broker may be different, e.g. just

containing an acknowledgement of the token’s correctness.

In the Claims Interpreter module of the FutureID AIS component, this differentiation and internal

brokerage is performed. Depending on the configuration of the Identity Broker, two different

modes of operation may influence the decisions made within the CI. In “dispatcher mode” of the

Identity Broker, the CI may simply forward the response to the correct eID handling

implementation (maybe using the APS language developed for the FutureID US, cf. [FutureID-

D42.3]).

In “claims transformer mode”, however, additional functionality is needed within the FutureID AIS

component in order to verify the transformed claim and deliver the result appropriately to the EAI

middleware and the authentication services. The workflow of this is part of the Claims

Transformer, see next section.

Technically, the realization of the CI can be performed in several different ways. Depending on

the complexity of protocols supported, it might be possible to implement the CI as a common

language module that dispatches and forwards the claim tokens in a hard-coded fashion.

However, a more recommended architecture would involve the use of service-orientation, e.g. as

a workflow run within an EAI middleware. As listed in Section 7, many of the existing EAI

solutions already provide technologies for such a realization, e.g. by means of the WS-BPEL

language. In that case, it might be reasonable to put the CI into the EAI middleware completely,

with a workflow that invokes required services of the other FutureID AIS modules.

Depending on the maturity of implementations and complexity of operations, a third technical

realization could be based on an APS runtime, as developed in [FutureID-D42.3].




9.2.6 Claims Transformer (CT)

If the Identity Broker operates in “claims transformer mode”, it is possible that the response the

FutureID AIS component receives from the Identity Broker is not directly compatible with the

authentication scheme required by the AS or its authentication services. Taking a naïve

example, consider an AS that operates based on username/password, but relies on the FutureID

architecture to gain this information from a SAML assertion token issued by a certain eID

infrastructure compatible to the FutureID architecture. In that case, the “authentication claim

response” received from the IdB will contain a full SAML assertion statement, including metadata

and a digital signature (issued by either the eID provider or the FutureID US). In this case, the

FutureID AIS component has to verify the correctness of the SAML assertion token and its

signature prior to forwarding the contained username and password to the Applications’

authentication services. Hence, there is a transformation of claims to be performed, converting a

SAML assertion to a verified username and password.

Within the FutureID AIS component, such claim transformation is the task of the Claims

Transformer module. Depending on its input and output (i.e. the token received from the IdB and

the token issued to the authentication services of the Applications), the CT decides on the tasks

to be performed (again, potentially using the APS language developed for the FutureID US, cf.

[FutureID-D42.3]), and invokes the appropriate services.

As with the CI, the technical realization of the CT can be performed as a hard-coded module, as

a workflow within an EAI middleware, or by means of an APS runtime.

9.2.7 Claims Transaction Database (CTDB)

Depending on the nature of the particular Applications and its service provider’s organizational

type, it might become necessary to store information on certain FutureID transactions at the

service provider’s side. For instance, if a claims transformation within the FutureID AIS

component is required, such transformation should be logged, in order to allow for subsequent

investigation in case of an authentication or authorization issue. Taking the example from the

previous section, the CT most likely would dismiss the whole SAML assertion token after

verification, keeping and forwarding only the username and password to the Applications’

authentication services. This approach, however, would not allow subsequent investigation on

whether the username and password issued in the SAML assertion might have differed from

those that were finally used at the Applications. Hence, in such cases it might be reasonable to

keep a copy of the full SAML assertion gathered from the Identity Broker persistently, allowing

for such additional investigations. The architectural module for such sort of information is the

CTDB.




Technically, the CTDB consists of an appropriate of-the-shelf database management system like

Oracle, MySQL, MS-SQL, or similar. The database schema then depends on the details of EAI

integration, the capabilities of the authentication services, and the needs of the service provider.

From a privacy perspective the design and use of the CTDB must be performed in conformance

to the requirements discussed in [FutureID-D22.3].




10. Conclusions

The EAI study performed in section 6 had provided a vision of the EAIs, the uses and when is

useful to use this solution, the technologies and protocols that can be supported by an EAI and

the types of EAI. The most important goal of section 6 is the understanding of how EAI fits within

FutureID. It has been presented also in this section a roadmap for implementing an EAI solution

useful as starting point for section 9 (architecture)

The proposed architecture builds upon the analysis of current EAI solutions throughout Section

7, and the analysis of different application scenarios of federated identity management in EAI

(Chapter 8).

Chapter 7 shows that the integration of identity management systems in EAI infrastructures is a

highly complex, heterogeneous environment, with lots of dependencies to the capabilities to the

particular EAI solutions. Hence, a full integration of the FutureID AIS component into each of the

existing EAI solutions is not feasible.

Chapter 8, shows that in order to sufficiently support the goals and motives behind EAI, fIdM

must be capable of supporting industrial IDPs, applications, and EAI middleware authentication

services. This allows for application of fIdM in EAI in intra-organisational and inter-organisational

scenarios. The analysis concluded that support of protocols, such as SAML, WS-Federation,

OpenID, ID-FF, WS-Trust, and WS-Security can be beneficial for integrating federated identity

management into EAI application scenarios.

The architecture of the application integration service builds upon these findings and relies on a

dedicated FutureID AIS component which is then integrated into existing EAI solutions via

appropriate connectors or EAI workflows. The proposed architecture is highly flexible, while

supporting almost all scenarios of FutureID involvement in applications and application

integration.