A synchronous, open, user-centric, federated Identity and ... - CiteSeerX

A synchronous, open, user-centric, federated Identity and Access Management System (OpenIdAM) Athanasios Karantjias1, Teta Stamati2, Nineta Polemi1, Drakoulis Martakos2 1

2

University of Pireaus, Informatics Department 80 Karaoli & Dimitriou Str, 185 34 Pireaus, Greece {karant, dpolemi}@unipi.gr

National and Kapodistrian University of Athens, Dept of Informatics and Telecommunications Panepistimiopolis, Ilissia Athens 15784, Greece {teta, martakos}@di.uoa.gr

Abstract: It is acknowledged that the latest stable XML technologies, standards and specifications may build real interoperable and secure enterprise privacy-aware implementations. However, existing implementations do not address the users’ need to easily handle their identifiers and credentials while providing pluggable modules for interconnecting their pre-existing business applications and platforms. This article proposes a constructive, targeted, user-centric, standards-based, open federated Identity and Access Management (IAM) system, the OpenIdAM, with which trust relationship among the involved entities is established in a secure and interoperable way, enabling end-users to easily e/m-access advanced business services, and Service Providers (SPs) to effectively enhance their infrastructures by easily plug-in existing modules, to secure and manage their enterprise systems without having to implement complex and multiple IAM mechanisms for each one of them. Keywords: Federated IAM Systems, Security, Privacy, Enterprise Solutions, SOA.

Biographical notes: Dr. A. Karantjias has obtained the Degree of Electrical and Computer Engineering from University of Patras (Greece) in 2000 and a PhD in Computer Science from National Technical University of Athens (Greece) in 2005. He is currently Assistant Professor at the Department of Computer Science of University of Piraeus (Greece). His current research interests include identification, design and evaluation of synchronous security and interoperability issues on enterprise architectures and advanced wireless information systems. Ms T. Stamati has obtained a Degree in Computer Science from National and Kapodistrian University of Athens (Greece) in 1998. She also holds an MPhil Degree in Enterprise Modeling Techniques from University of Manchester Institute of Science and Technology (UMIST) (UK) and an MBA Degree from Lancaster University Business School (UK). She has extensive experience in top management positions in leading IT companies of the Greek private sector. She is currently Research Fellow at the Department of Informatics and Telecommunications of National and Kapodistrian University of Athens. Her current research interests include IS migration, identification, design and evaluation of methodological approaches for e/m-services evolution and IT security. Dr. N. Polemi has obtained the Degree in Applied Mathematics from Portland State University (USA) in 1984, PhD in Applied Mathematics (Coding Theory) from University of New York (Graduate Centre) in 1991. She held teaching positions in Queens College and Baruch College of City University of New York and was assistant professor in State University of New York at Farmingdale in the

department of Mathematics. She is now professor in the University of Piraeus R&D department. Her current research interests are in the fields of security. Prof. Drakoulis Martakos is an Associate Professor at the Department of Informatics and Telecommunications at the National and Kapodistrian University of Athens. He received his B.Sc. in Physics, MSc in Electronics and Radio Communications, and Ph.D. in Real-Time Computing from the same university. Professor Martakos is a consultant to public and private organizations and a project leader in numerous national and international projects. He is author or co-author of more than 100 scientific publications and a number of technical reports and studies.

1. Introduction The latest incarnation of a distributed computing framework is the Services Oriented Architectures (SOAs) that are most often implemented with Web Services, using open XML standards and focusing on reuse and loosely coupled integration [1]. However, these objectives are often completely lost when advanced security integration is added. Until now, most SOA developments [2][2] have relied on application or system level authentication and authorization for establishing simple trusted user identity features, causing the following obstacles:  Service Providers (SPs) have to implement multiple, different and separate authentication and authorization mechanisms for their applications and systems. This is rather expensive and difficult for an SP to manage and administer, while is inefficient for the end-users who have to manage multiple identities.  Every attempt to interconnect separate applications in order to add value and build more advanced e/m-services, often means linking separate user e/m-access security processes. This is rather complex and difficult to achieve from the technical point of view. The usual solution is to lower the level of security and privacy to these systems and applications, while the end-users are not able to easily handle their identifiers and credentials. The increasing regulatory compliance and audit requirements [4] are additional burdens for the SPs forcing them to consider a higher assurance level for user identity in e/mprovision of services, which impose the implementation of proprietary Identity and Access Management (IAM) mechanisms with questionable levels of usability, manageability, and scalability. Worldwide accepted and mature standards, specifications, and protocols lay the foundation for solutions and new security models that allow trusted user identity to be digitally and effectively managed across multiple and different security domains and enterprise systems [5][6][7][8][9]. However, SOA implementations and architectures based on these do not actually gain the benefits of a truly parametrisable e/m-environment in which existing modules can be easily merged. The uplift of the above mentioned obstacles requires more than basic web service communications protocols. What is needed is an efficient and practical way to use these standards and integrate a synchronous architecture, which will be able to introduce automation and system support of the identity management equally at the user and the SP sides. Based on it, enterprises should be able to easily build end-to-end identity infrastructures, supporting interoperable Web Services applications. This article proposes a targeted, user-centric, open, and federated IAM system, called OpenIdAM, enhancing the trust relationship among the involved entities and enabling:  End-users to be able to administrate and control their identities on their own, and easily e/m-access advanced business services



SPs harmonise their authentication/authorisation procedures, enhance the majority of their infrastructures by easily plug-in them to core IAM system and to effectively secure and manage their enterprise. The proposed system OpenIdAM has been implemented in the e/m-Government platform SWEB [11] developed under an IST European programme. In this paper we will concentrate on the OpenIdAM system itself where implementation aspects may be found in our previous work [12][13][14]. The rest of the paper is organized as follows: Section 2 assesses traditional IAM models, current practices and prior work on privacy–aware architectures; Section 3 presents the fundamental design principles of the proposed OpenIdAM; Section 4 analyses its novel architecture. Section 5 contains acknowledgements and finally Section 6 draws conclusions.

2. IAM Models, Standards and Implementations In order to better understand the merit of the OpenIdAM, this section assess the three traditional IAM models (isolated, centralized, federated) and current implementations and practices.

2.1. Isolated IAM Systems Until recently, a common practice is for SPs to act as both credential provider and identifier provider to their users, controlling the name space for specific service domains and allocating users’ identifiers [15][16]. Isolated IAM systems force users to get separate unique identifiers from each service/identifier provider they transact with, and use separate credentials with each of their identifiers. This approach surely provides a simple identity management for SPs, but is rapidly becoming unmanageable for users who are overloaded with identifiers and credentials that they need to remember, periodically change, and effectively manage. In addition such IAM models constrict systems to interoperate on behalf of a user in order to provide more advanced e/m services, which is today a core requirement for both the public and the private sectors in order to add value on current services and provide more advanced ones.

2.2. Centralized IAM Systems In centralized user identity models, a single authority, used by many SPs or in addition to other identifiers and credential providers, undertakes the management of the namespaces, the issuance of the required authorization tokens, and the authentication of all users during each e/m service access [16][17]. Current implementations which adopt this model are well suited for closed networks where multiple SPs are managed by the same organization such as governments and large companies, providing effective usability through Single Sing On (SSO) mechanisms. The main difficulty for centralized IAM systems to operate in open environments is caused mainly from the various SPs, which are not governed by a common policy and authority. In addition to this, current implementations do not clearly provide pluggable modules in order to connect with the majority of the applications and platforms on the SP.

2.3. Federated IAM Systems Federated IAM systems are based on groups of SPs that enter into mutual security and authentication agreements in order to allow users SSO to their services. These agreements include policy and technology standards and result a single virtual identity domain for the end-user, providing SSO in open environments. The federated model is compatible with and can easily be retrofitted to the traditional isolated IAM model [18][19][20].

However it creates legal and technological complexity since difficult strategies must be adopted in order for SPs to be able to distinguish between a security assertion that reflects a genuine user service request and one that represents an SP that acts on behalf of a user. Moreover, when dealing with multiple centralized identity domains, scalability problems for users cannot be avoided, since multiple federated IAM systems will exist in different domains.

2.4. Existing Implementations and Standards Several solutions based on the above mentioned traditional IAM models, for managing and controlling end-user’s access, permissions, and allowed actions to electronic resources, have been already proposed by various projects and research initiatives. According to their results, three main types of IAM-solutions were proposed. The first refers to account management and implements an Authentication, Authorization, and Accounting (AAA) infrastructure. Representative designs of this type are the Liberty Alliance (LA) [6] and the WS-Federation [21]. LA creates a set of specifications (ID-FF, ID-WSF, and ID-SIS) for identity federation in network environments, ensuring interoperability, supporting advanced privacy, and promoting the adoption of its guidelines and best practices. On the other hand, WS-Federation specification defines mechanisms for enabling different security domains to federate by allowing and brokering trust of identities, attributes, and authentication between all implemented Web services. The second type refers to user data profiling process, such as the detailed log files or data warehouses, which support personalised services and analyse user’s behaviour. Finally, the third type is based on solutions for user-controlled, context-dependent role and pseudonym management. Several other projects and research initiatives [20][22] proposed and implemented system architectures that reconcile privacy and accountability of users’ electronic interactions, distinguishing mainly two IAM-solutions:  The enterprise IAM-solutions, in which data-control is exercised by the enterprise instead of the individual user.  The user-centric IAM-solutions, in which the administration and control of identity information is placed directly into the hands of individuals, allowing users themselves to have full control of their personal information and preferences. All these attempts aim to cover all possible cases, and therefore remain in a generic level. The facts that privacy and identity management, at the time that many of these solutions were deployed, were very innovative assets when building advanced e/m-enterprise systems, and the primitive status of core Web Services standards, led to ineffective and rather closed IAM solutions [23]. Very few of these solutions take into consideration the need for users to be able to easily handle their identifiers and credentials. These solutions provide automated systems to SPs for managing identities, authentication and authorization, whereas do not adopt the user perspective, who needs to simplify his entrance in a large scale enterprise framework. On the other hand, even if these SOA and Web Services based solutions are properly designed and implemented in a way to satisfy the needs of the end user, they are unable to interconnect with existing, self sufficient applications and platforms, which do not necessarily conform to the assumptions of SOA’s distributed application model. Therefore most of the time an organization is obliged to change or exclude its legacy systems even if they work fine in order to adopt such unified IAM systems. Last but not least, the fact that the mobile aspect is partially covered imposes the replacement of these solutions with more synchronous ones.

3. Fundamental Design Principles of OpenIdAM The design of our proposed system (OpenIdAM) provides the fundamental benefit of a synchronous e/m IAM system; Consistent usage of a standards-based architecture, practical integration, easily modified and expanded functionality, and re-engineering privacy-aware services. The following paragraphs introduce the design and implementation core principles of the OpenIdAM, which also ensure that:  Each user/organization perceives high quality of the privacy-aware services provided.  End-users are allowed to manage their identities personally, without the involvement of the various SPs  SPs are able to utilize the majority of their systems in an open and scalable privacy-aware IAM framework.  SPs are able to interoperate with each other, build more advanced services, and act on behalf of the user, harmonizing only the actual business processes and not the management of identities.

3.1. Interoperability & Extensibility E/m enterprise solutions due to their increased usage in everyday life need to be simple, open and reconfigurable, providing easily reengineered privacy-aware services and taking into account that the large number of users has to be served with acceptable quality of service levels [24]. Therefore, OpenIdAM demands the creation of a dependency between business, security and privacy-aware technologies in order for SPs to be able to efficiently adopt them and support their business activities. The adoption of world-wide known XML-based open standards increases the achievement of interoperability and extensibility in such distributed and heterogeneous environments. Thus SPs are able to easily promote the concept of atomic, self-contained, added-value services, which are accessible and available to a multitude of applications, integrating their applications in a seamless fashion. However, the main difficulty is to provide a universal way to interoperate with existing systems, applications and platforms that reside and operate in a SP. The main goal is to find and standardize the communication of a federated IAM with different kinds of enterprise systems, which usually adopt:  Proprietary interfaces: The advanced integration logic in the mean of transformation rules, workflow services etc. cannot be ported between different solutions that most organizations host and operate.  Limited communication protocols: Although the use of SOAP/HTTP protocol provides a wide-bridge between different solutions, it tackles the rudimentary issue of the sessionless RPC. It actually overlooks the other fundamental architecture services such as guaranteed delivery and limiting interoperability between different solutions that operate in the same organization.  Lack of scalability: Deporting all or part of a central enterprise integration logic to Web Services connectors is something very complex to deploy and administer. Besides, for each installation of an e/m federated IAM system there is the need to customize the communication with the several existing systems building new Web Services connectors, re-configuring many core components in the core architecture. This solution is very inefficient and non scalable. Thus, the interoperation of OpenIdAM with existing systems and applications as well as with every external to the core IAM needs a specific middleware tier which will be responsible to integrate a light weight messaging framework that will use disparate technologies, transports and protocols.

The adoption of Enterprise Service Bus (ESB) technologies could effectively manage all interactions between the various components of different systems transparently, stipulating that multiple applications communicate through a common messaging bus, and decoupling all point-to-point connections from the various interfaces [25][12].

3.2. Security and Trust During the OpenIdAM design we acknowledged the fact that security and trust are key enablers of future digital enterprise environments, based on many interacting objects, devices and systems. Although Web Services and SOAs permit enterprises to create interoperable services-based applications and systems, their original definition did not include a strong built-in security model. The use of the Secure Socket Layer (SSL) (RFC 2246) protocol to protect communications among service endpoints does not provide the granularity and flexibility, required for more advanced Web Services scenarios, where the endpoints might not have a direct channel to each other. Second generation Public Key Infrastructures (PKIs) and advanced XML cryptography mechanisms support a large scale deployment of a number of security services, such as origin authentication, content integrity and confidentiality, and non-repudiation, establishing trust chains at local, national and international level [14][24]. Electronic signatures and related services that allow data authentication can, therefore, play an important role in this context by ensuring security and trust in every e/m transactions. We highly considered the European Directive 1999/93/EC [26] imposing the legal recognition of electronic signatures; the Directive provides the legal framework for esignatures and Certification Service Providers and defines two levels of security that organizations may apply to e-signatures depending on the sensitivity of the transaction:  Simple e-signatures, for a minimum level of security, integrating the W3C XML Digital Signature - XML-DSIG standard, which defines the appropriate way for rendering digital signatures in XML [24].  Advanced electronic signatures, XAdES signatures, for a higher level of security, implementing the ETSI standard [24][12]. In addition we considered the European Directivves in the processing of personal data and the protection of individuals and privacy in the telecomunication sector [27][28]. OASIS WS-S [5], WS-Trust [8], SAML 2.0 [7] define and standardize a core specification for securing SOAP messages, plus several extensions for integrating user or service identity information within these, based on XML cryptography.

4. OpenIdAM Architecture The following paragraphs introduce our novel approach, which consists of two different main entities:  The core centralized and federated infrastructure, which issues privacy-aware identity tokens and manages the identities of all end-users,  An advanced Integration Layer, which sits on top of the systems and applications on an SP, providing them advanced privacy-aware services in a unified manner.

4.1. Core centralized and federated infrastructure The core infrastructure of OpenIdAM integrates and ties service discovery, invocation, authentication and other necessary components, adding context and value to web services, required from every synchronous IAM system [29].

Figure 1 OpenIdAM architecture

As depicted in Figure 1, it consists of four different and district tiers, the Interaction Tier, the Main Enterprise Tier, the Secondary Enterprise Tier, and the Middleware one [14]. The Interaction Tier undertakes the establishment of communication with all external entities such as the e/m-users, the PKI, and the enterprise platforms of the organizations, which adopt it. This communication is based on Web Services, processed from the Web Service Manager. The quality of protection through message integrity, message confidentiality, and single message authentication, is provided through the use of WS-S mechanisms, the implementation and validation of which are undertaken from the Message Security Manager. The Main Enterprise Tier enclosures and implements the core authorization mechanisms in the OpenIdAM. The Service Handling component handles all service calls into the enterprise and assigns specific events to other internal handlers and components. The XACML-based Policy Enforcement [14][13] module specifies and enforces fine-grained, system-readable privacy policies, used to control access to Web Services, digital objects and services, enclosing users’ preferences and OpenIdAM’s requirements. Therefore, within this component an initial policy matching of the SPs’ requirements with the users’ preferences and capabilities and vice versa is achieved. The Security Manager module handles all security cryptographic credentials provided from a PKI, while it implements all the advanced security mechanisms on the OpenIdAM such as the creation/validation of XML digital signatures and XML encryption and decryption. In cases where the OpenIdAM is configured for the public sector, like in SWEB case, the Security Manager provides long term validity (XAdES) [24] e-signatures, since the authorization assertions for signed public documents may have to bear signatures lasting for a long time. The Token Issuer module issues XML-based security tokens, integrating the WS-Trust standard, providing authorization, and advanced auditing mechanisms. To maximize

interoperability with clients and systems from multiple vendors, the OpenIdAM supports the WS-Federation and SAML 2.0 protocols. Moreover, for higher administrative efficiency, it automates federation trust configuration and management, using the harmonized federation metadata format [21]. This automation enables the OpenIdAM and SPs to publish their federation metadata in a standard format, which can be exchanged between potential partners. Consequently, using a single specification that can support both passive web application and active web service requestors is a key advantage for effectively using this system in multiple and heterogeneous environments. The Secondary Enterprise Tier manages the choreography of the core platform services, implementing their business logic, defining and mixing human based actions and creating business rules based on workflow data. It is actually the tier that integrates all business services, using the core system services and modules provided from the main enterprise tier. The use of Business Process Management Notation (BPMN) systems for modeling all business processes in the OpenIdAM, organizes the embedded logic of an application into separate and easily changed “state machines” [30]. Specifically, the emergence of Business Process Execution Language (BPEL) and its embracing by major vendors and IDE tools provide a higher-level description language to specify the behavior of Web Services’ framework, orchestrating them into business privacy and identity-aware processes. It actually places a significant emphasis on all processes within the secondary enterprise tier of the system, both in terms of streamlining process logic to improve efficiency, and also to establish processes that are adaptable and extensible so that they can be augmented in response to business change. The primary goal was to establish a highly agile automation environment, fully capable of adapting to change, which is realized by abstracting the business process logic into its own tier. Thereby, a developer is able to alleviate other privacy-aware services from the need to repeatedly embed process logic, and support process optimization as a primary source of change for which services can be recomposed. The Middleware Tier integrates all required interoperable mechanisms through the use of the open source Mule Enterprise Service Bus - ESB framework [31]. This tier is actually a light weight messaging layer that uses disparate technologies, transports and protocols. Specifically this tier undertakes to communicate with a UDDI server or any other directory server, or even a single database server, which provides a set of services supporting the description and discovery of all businesses, organizations, and SPs, as well as the predefined policies, agreed between the OpenIdAM and each SP separately. An optimum federated IAM system must give the opportunity to adopt and manage data structures from multiple and heterogeneous environments while not changing the implemented services in the previously described three tiers. Therefore, the middleware tier operates as a transformation layer for every possible data that have to be inserted or exported from the core OpenIdAM.

4.1. OpenIdAM’s Integration Layer Even if SOA and Web Services are being proposed as the best solution for integrating privacy-aware applications and IAM systems, they are not enough on their own. A synchronous IAM system works best when it links up newly built, pluggable modules across a network to create distributed, composite applications. The enterprise integration problem is subtly different. It actually aims to connect together pre-existing, self sufficient applications and platforms, which do not necessarily conform to the assumptions of SOA’s distributed application model. A main difficulty is to find a universal way to interoperate and standardize the provision of access to the legacy systems of a SP. However, most of the time an organization is obliged to change or exclude its legacy systems even if they work fine in order to adopt a unified IAM system.

In addition even when an XML or SOAP document arrives at an application or a SOA platform, there may exists gaps between that document, the semantic and the process model of the application. The problem may be as simple as the format being wrong or as complex as the incoming document being passed through a complete process before the application can accept it such as validating the sender, gathering secondary information from other systems and then transforming it into the appropriate request, and others. In order to fill the gap we adopted four typed of activities:  Validation against business definition. Usually an invalid document has potentially disastrous consequences for any application.  Enrichment with additional information in order to ensure the completion of the data and involve other applications such as databases, and web services for example, as well as internal calculations such as aggregation, derivation, and analysis.  Transformation in the correct format before being mapped into main language domain. Usually there might be more information that must be filtered out or less information that must be augmented in some way, or even the information may be in a different format of order.  Exception handling, which must be managed intelligently. Consequently, validation, enrichment, transformation and exception handling are the first four attributes to be checked in any potential IAM solution. As web services moves into the area of application integration there is a need for an IAM system that will provide a new integration layer. OpenIdAM’s integration layer, the architecture of which is depicted in Figure 2, navigates the differences in technology and information model of the applications that adopts it, undertaking the following:  The communication and negotiation with the core infrastructure if OpenIdAM (through the IAM enabler Tier), for validating the received tokens, setting up the privacy policies, declaring electronically the provided services, the roles of the users who can access them, and the prerequisites for obtaining each one of these (roles) [32].  The communication with end-users who wish to gain access to the systems and applications of an SP (through the Middleware Tier).  The communication with all internal to the SP applications and systems (through the Middleware Tier).  The communication with every external to the SP enterprise system (through the Middleware Tier).

Figure 2 OpenIdAM’s integration layer architecture

This layer involves the creation of privacy and access-aware service interfaces to existing or new functions, either directly or through the use of adaptors, by routing and delivering all service requests to the correct application or system. Its main goal is the support of the substitution of one privacy and access-aware service implementation by another with no effect to the clients of that service. This requires not only the service interfaces to be specified according to SOA principles, but also for the core infrastructure to allow client code to invoke these services in a manner, which is independent of the service location and the communication protocol involved. In the IAM Enabler tier the Web Services Manager structures the requests sent to the core infrastructure of OpenIdAM, handling appropriately as well the responses from it. It uses the Security Manager to ensure the quality of protection through the message integrity, confidentiality and single message authentication. The XACML-based Policy Enforcement module specifies and enforces the privacy policies of the SP, used to control access to all business service. Although these policies are declared and enforced in the core OpenIdAM as well, this integration layer gives to SPs the ability to further validate and ensure their proper addressed when issuing the required SAML token. The Access Manager undertakes to validate the received SAML tokens. It actually validates the digital signature of the OpenIdAM, the lifetime of the token, and the role assigned to the requestor. The results of this validation process directly affect the behavior of the Middleware Tier. The Middleware Tier allows the standardization of the communication messages, which are mostly Web Services – based, with every external to the SP entity (the OpenIdAM, the end-users, and the external platforms). Consequently, when an SP wishes to adopt the

OpenIdAM, it has only to properly build the internal communication channels with the middleware tier and mainly with the ESB component. It offers the architecture the ability to be scalable and extensible, being able to connect to any kind of applications and systems, without changing the functionality, nor the Web Service messages with the core OpenIdAM. Otherwise, such a system would have been obliged to support independent communication messages with every single SP. These messages would also have to be parameterized in every internal architectural change, affecting the framework’s operation. In a large scale federated framework where multiple and different kinds of SPs participate, wishing to communicate with each other on behalf of the user and provide advanced business services, using an IAM system, this would have been very inefficient and therefore prohibitory. The existence of this layer offers the opportunity only to rebuild or re-configure the connectors with the internal applications and systems, while updating the flow of the processes in each involved component, included in this tier. The Enterprise Service Bus component supports the service routing and substitution, providing the integrated communication, messaging, and event infrastructure to enable this. It actually combines the major enterprise integration patterns in use today into a single SOA consistent component and undertakes to provide all the required privacy and access aware credentials in each internal to the SP application and system, in the appropriate digital structure. The Business Service & Service Routing Directory is used from the ESB module to route all privacy and access-aware service requests, providing also a service catalog in order to achieve reuse of services across the legacy systems of the SP. The use of an internal UDDI could fulfill the vision of Web Services, enabling the dynamic discovery and invocation of these secure services. Such a directory could easily be viewed as part of the ESB component; however, until such solutions become common, it is likely to be separate from it. The Business Service Choreographer composes business processes from several business services. It actually invokes all privacy and access – aware services through the ESB, and exposes the business process as other services available to the applications and systems of the SP. In this module a developer is able to build the choreography of the core services provided, implementing the way these are connected with each other, creating business rules based on workflow data and representing the core part of any SOA. The Gateway makes the privacy and access-aware services of two or more applications or enterprises available to each other in a controlled and secure manner. This component actually integrates all the additional capabilities that might be required, such as the specific management functions of the relationship between two district systems or even departments in the same SP that should not be part of the ESB component and not necessarily supported by its technologies. This component is usually needed when trying to provide SSO capabilities for the applications or systems of large scale organizations, such as Ministries that consist of many different and independent departments [12].

5. Conclusions Advanced SOAs are considered the most promising way to achieve complex communication among multiple e-business actors across organizational domain. However, the lack of strong security and privacy mechanisms and the adoption of inefficient, insecure, and expensive enterprise IAM systems, necessitates large-scale innovation, across organizational boundaries and between public and private institutions, in which privacy and identity management will not be treated as generic problems. Essentially, this paper intends to provide practical and comprehensive coverage of a synchronous, user-centric, federated IAM system, designed and implemented on a modular basis at the SWEB IST programme. It also introduces a novel integration layer,

which sits on top of every SP, allowing its effective adoption from different and heterogeneous applications, systems and enterprise environments. Both architectures encompass fundamental design principles such as interoperability, scalability & extensibility, privacy, security, and reusability, in order for large-scale frameworks to successfully solve problems arising from identity management, ensuring privacy awareness for each managed identity.

6. Acknowledgements The authors would like to thank the E.C. for its support in funding the SWEB project [11] and all the project partners.

7. References [1] Zhang, L. (2007), "SOA Solution Reference Architecture", IEEE International Conference on Web Services, ICWS 2007, Salt Lake City [2] Bertino, E., and Martino, L. (2007), "A Service-oriented Approach to Security - Concepts and Issues", Eighth International Symposium on Autonomous Decentralized Systems, ISADS '07, Sedona USA, pp.7-16. [3] Li, J., and Karp, A. (2005) “Access Control for the services oriented architecture”, “Proceedings of the 2007 workshop on Secure web Services, SWS’07, ACM, Fairfax Virginia USA, pp. 9-17 [4] Peyton, L., Doshi, Ch., and Seguin, P. (2007) “An audit trail service to enhance privacy compliance in federated identity management”, Proceedings of the 2007 conference of the center for advanced studies on Collaborative research, CASCON’07, ACM, Ontario Canada, pp.175-187 [5] OASIS Technical Committee, (2006), “Web Services-Security Core Specification 1.1”,OASIS standard, Available at http://www.oasis-open.org [6] Liberty Alliance, (2006), “Liberty ID-WSF Web Services Framework Overview - version 2.0”, Liberty Alliance specifications, Available at http://www.projectliberty.org [7] OASIS Technical Committee, (2007), “Security Assertion Markup Language v.2.0 – Technical Overview”, OASIS, Available at www.oasis-open.org [8] OASIS Technical Committee, (2007), “WS-Trust 1.3”, OASIS standard, Available at www.oasis-open.org [9] Sxip Identity Corporation, (2006), “SXIP 2.0 Overview”, Sxip Identity Corporation, Vancouver, BC [10] Fitzapatrick, B., and Recordon, D., (2006), “OpenID: an actually distributed identity system”, Available at http://www.openid.net [11] SWEB IST project, (2006), “Secure, interoperable, cross border m-services contributing towards a trustful European cooperation with the non-EU member Western Balkan countries”, Sixth Framework Programme, IST-2006-2.6.5, Available at www.sweb-project.org [12] Karantjias, A., and Polemi, N., (2009), “An Innovative Platform for complex Secure emGovernmental services”, International Journal of Electronic Security and Digital Forensics (IJESDF), Special Issue on Mobile Services Technological and Legal Issues, Vol. 2, No 4, pp. 338-354 [13] Papastergiou, S., Karantjias, A., and Polemi, D., (2007), “A Federated Privacy-Enhancing Identity Management System (FPE-IMS)”, Proceedings of the 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, PIMRC 07, Athens Greece [14] SWEB consortium, (2008), “SWEB platform development report”, Project Deliverable, European Commission, Belgium [15] Emayor IST Project, (2004), “Electronic and Secure Municipal Administration for European Citizens”, IST-2004-507217, Sixth Framework Programme [16] Ardagna, C., Cremonini, M., Damiani, E., Capitani, S., Frati, F., and Samarati, P., (2006), “Privacy-Enhanced Identity Management for e-Services”. Secure eGovernment Web Services, Idea Group INC.

[17] Koch, M., and Moslein, M., (2005), “Identity Management for E-commerce and Collaborative Applications”, International Journal of Electronic Commerce, Spring 2005, vol. 9, No.3 Sharpe Inc., pp.11-29 [18] Ahn, G., and Lam, J., (2005), “Managing privacy preferences for federated identity management”, Proceedings of the 2005 workshop on Digital identity management, DIM’05, ACM, Fairfax VA USA, pp. 28-36 [19] Internet2, (2007), “Shibboleth Architecture”, Internet2 Middleware Iniative, Available at http://shibboleth.internet2.edu [20] PRIME Project, (2005), “Privacy and Identity Management for Europe”, European RTD Integrated Project under the FP6/IST Programme, Available at http://www.primeproject.eu.org/ [21] OASIS WSFED Technical Committee, (2008), “Web Services Federation Language Version 1.2”, OASIS, Working Draft [22] FIDIS consortium, (2006), “Structured Overview on Prototypes and Concepts of Identity Management Systems”, European Commission, Available at http://www.fidis.net/ fileadmin/fidis/deliverables/fidis-wp3-del3.1.overview_on_ IMS.final.pdf [23] Rieger, S., and Neumair, B., (2007) “Towards usable and reasonable Identity Management in hererogeneous IT infrastructures”, 10th IFIP/IEEE International Symposium on Integrated Network Management – IM’07, Munich, pp. 560-574 [24] Kaliontzoglou, A., Sklavos, P., Karantjias, A., and Polemi, N., (2005), “A secure eGovernment platform architecture for small to medium sized public organizations”, Electronic Commerce Research & Applications, Elsevier, vol. 4 No. 2, pp. 174-186 [25] Khoshafian, S. (2006), ‘Service Oriented Enterprises’, Auerbach Publishing, 1st Edition [26] European Commission, (1999), Directive 99/93/EC of the European Parliament and of the Council on a Community framework for electronic signatures, Official Journal L 13,pp.12 – 20 [27] European Commission, (1997), Directive 97/66/EC of the European Parliament and of the Council concerning the processing of personal data and the protection of privacy in the telecommunications sector, Official Journal L L 024, pp.1 – 8 [28] European Commission, (2001), Directive 01/45/EC of the European Parliament and the Council of Ministers on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data, Official Journal L 008, pp.1 –22 [29] Dabrowski, M., and Pacyna, P., (2008), “Modular reference framework architecture for Identity Management”, 11th IEEE International Conference on Communication Systems, ICCS’08, Singapore, pp.743-749 [30] Pasley, J., (2005), ‘How BPEL and SOA Are Changing Web Services Development’, IEEE Internet Computing, vol. 9, No. 3, pp. 60-67 [31] Mule Technical Committee, (2008), “Mule 2.0”, Release Candidate 2, Available at http://mule.mulesource.org [32] Squicciarini, A., Trombetta, A., Bertino, E., and Braghin, S., (2008) “Identity-based Long running negotiations”, Proceedings of the 4th ACM workshop on Digital identity management, Virginia USA, pp. 97-106