Abstract of the Core Concepts of S.A.F.E.: Standards for Federated Identity Management

Transcription

1 Abstract of the Core Concepts of S.A.F.E.: Standards for Federated Identity Management Subject: Responsible: Secure Access to Federated E-Justice/E-Government Federal and State Authorities Commission for Data Processing and Rationalization in German Justice Version.Release: 1.1 Creation: Last Revision: State: in process / submitted / ready Number of Pages: 16 Authors: Filename: Abstract: Birger Streckel (Dataport) _SAFE_Abstact_V1-1.doc Short summary of the S.A.F.E. S.A.F.E. defines a technical framework for interoperable and safe usage of Digital Identities across administrative borders ( Trust-Domains ) and is set up from the Web Service Protocol Stack ( WS-* ) of OASIS and W3C. The selected standards are profiled for sake of interoperability. Contact: Working Group IT-Standards in Justice Jürgen Ehrmann Ministry of Justice of the state of Baden-Württemberg Telefon: ehrmann@jum.bwl.de Meinhard Wöhrmann Higher Regional Court in Düsseldorf Telefon: meinhard.woehrmann@olg-duesseldorf.nrw.de

2 Seite 2 von 16

3 Seite 3 von 16 1 STARTING POINT AND GOALS FUNCTIONAL REQUIREMENTS DESIGN GOALS IDENTITY MANAGEMENT IDENTITY MANAGEMENT IN E-GOVERNMENT/E-JUSTICE IDENTITY MANAGEMENT STANDARDS SAML 2.0, Liberty Alliance WS-Trust, WS-Federation Usage of standards in S.A.F.E THE S.A.F.E. CONCEPT ARCHITECTURAL OVERVIEW Attribute Service (AS) Provisioning Service (PS) Identity-Provider (IdP) CONCEPTUAL FEATURES LITERATURE...15

4 Seite 4 von 16 1 Starting point and goals The conference of justice ministers initiated a Deutschland Online -Project Einheitliche Verfahren für den elektronischen Rechtsverkehr (Standardized processes for the electronic justice), which was finally adopted on by the conference of prime ministers. The intention of this initiative is the advancement of the electronic communication infrastructure in justice with the goal of defining open, interoperable and internationally standardized interfaces for the participants that allow secure access to communication services as well as secure and reliable electronic communication. The S.A.F.E. concept aims at the secure registration, authentication and authorization as well as the secure storage of communication participants. Since these aims are of common interest for most E-Government services also beyond communication and beyond E-Justice, S.A.F.E. was developed as a concept consisting of two main documents. The first document Architecture and Interfaces for Federated Identity Management [1] defines a common standard for user management and registration for general E-Government services. A Web Service based Identity Management Infrastructure is defined, which can be used as a common standard for securing access to E-Government services. The standard is open and expandable to allow interoperability between different E-Government services and to provide Single-Sign-On (SSO) solutions for accessing different services with the same Digital Identity. The second document S.A.F.E. detailed technical concept [2] further specialises the general concept for its use in the concrete E-Justice communication scenario. While preserving the general concept further specializations and extensions are made to meet the demand of the concrete E-Justice application. The base concept can be customized by other E-Government applications. This generates an expanding pool of interoperable E-Government services with a common registration and authentication interface. 1.1 Functional requirements The main goals of the general concept for identity management are to provide an open and highly scalable architecture for Federated Identity Management (FIM) in E-Justice and E-Government. The primary objectives are:

5 Seite 5 von 16 Create a concept for medium-size identity management solutions with the possibility to use federation techniques to expand these to large scale, Federated Identity Management (FIM) enterprises Use Identity Management to provide secure access to E-Government services Define base services for a complete Identity Management Framework including authorisation, authentication, provisioning that are reusable by all kinds of E-Government applications Define minimum standards for security and information that must be fulfilled met by all services that are part of a S.A.F.E.-federation Be open to all kinds of registration and authentication procedures Support roles and rights concepts based on registration and authentication security Provide an address-book service that can be queried for lists of the managed identities The requirements regarding the detailed technical concept for identity management for in an electronic justice communication scenario are much more application-driven: Maintain an identity store with up to identities of legal practitioners, notaries, courts, ministries of justice, business companies, etc. Selective querying of the identity store with support of right and role management Self provisioning and administrative provisioning of these identities Secure access to E-Justice communication services Minimal effort in migrating the existing user database to the new identity management infrastructure 1.2 Design goals From the functional requirements the following design goals were derived: To be open to a variety of E-Government services the concept only defines interfaces and communication protocols between the different services and modules of the described framework, to guarantee interoperability. Realisation of the interfaces and concrete development of the services are left to the implementer. To minimize the implementation efforts and with this raise the acceptance it is necessary to base S.A.F.E. on open international standards, preferably standards with already available implementations. To provide interoperability between all applications implementing the S.A.F.E. concept, a minimum set of standard services and their communication interfaces are defined. These have to be implemented by every partner in a S.A.F.E.-federation.

6 Seite 6 von 16 To provide common security standards for all S.A.F.E. services, guidelines for administration, management and life cycle of digital identities (provisioning) are defined. Rules are established for authenticating an identity and for proving the correct authentication to service providers. A method is set that allows an individual to securely prove its verified identity. To provide common security standards for the identity data rules and interfaces for accessing and storing identity information and attributes are defined. Further conceptual goals are: Platform independence on client- and server-side High scalability to support large scale solutions as well Usage of open, vendor independent standards Possibility to integrate existing Identity Management Infrastructure Secure message exchange with Web Services Possibility to decentralize identity data for functional or spatial aspects with the opportunity of future cooperation (federation) Support of active Web Service oriented client server communication in service oriented architectures (SOAs) Possibility to integrate passive browser-clients for Single-Sign-On scenarios. 2 Identity Management Identity Management is a concept for managing identities. Identities can be individuals, legal persons or IT-components. An identity consists of information about the described individual. Each identity has a unique ID and descriptive attributes, such as address, , certificates. Identity Management is used to identify individuals in a system and to control their access to resources within that system by associating user rights and restrictions, based on the identities attributes, with the established identity. Identity Management covers: Handling of identities and their attributes Authentication of identities by trustworthy entities Authorization of identities to use (web-)resources Secure message transmission in the identity managed enterprise Provisioning of identities and management of identity lifecycles with registration, change and deletion of identities and attributes Management of roles and access rights Management of attribute access and visibility

7 Seite 7 von Identity Management in E-Government/E-Justice For the task of secure E-Justice communication it is necessary to provide a user management. This must at least include registration, provisioning and authentication of the communication users. A secure access to the communication services is needed and also some role management specifying the possible communication partners to prevent events like spamming or mass mailing. These requirements has to be met by a flexible, expandable system completely based on open, international and vendor independent standards. This guarantees the interoperability and expandability of the enterprise solution and ensures a seamless integration of components developed by different vendors. Identity Management is the discipline meeting all these requirements and leading to an open standard for user management and registration for general E-Government services also beyond E-Justice. By using the S.A.F.E.-standard identities for different E-Government applications are exchangeable. SSO solutions are possible, where the Identities are provided by local organisations and could be used to gain access to a wide range of different E-Government services. 2.2 Identity Management standards Currently different international standards in the field of digital identity management are existing. The two main standard families covering the necessary features for the described scenario are SAML 2.0/Liberty Alliance and WS-Trust/WS-Federation. Both are vendor independent, open and international standards and at least partially OASIS-ratified. Unfortunately both standard families are at least partially overlapping and incompatible to each other SAML 2.0, Liberty Alliance The SAML Standard, which is already several years in place, with its current version 2.0 [11], provides all necessary features for simple Identity Management solutions. While its main focus is browser-oriented passive federation, it also allows federation of Web Services. Open source implementations exist, but also here with the main focus on browser-sso. In this field it achieved quite some reputation over the last few years. The SAML standard is supplemented by several Liberty Alliance standards (ID-WSF standard family). These extend SAML by advanced features for federation of Web Services. In contrast to the SAML standard ID-WSF is not so widely accepted.

8 Seite 8 von WS-Trust, WS-Federation WS-Trust [7] and WS-Federation [8] are based on the stack of WS-* standards which define Web Services interoperability and are almost without alternative when implementing Web Service functionality. WS-Trust and WS-Federation are the logical continuation of the WS-* standard family and with this have their clear focus on Identity Management using Web Services. Quite some acceptance is noticeable and also implementations of the standards exist. WS-Federation provides also a solution for Browser-oriented passive federation, but is stronger in the field of Web Services Usage of standards in S.A.F.E. So far it is unknown, which of the two standard families will have the greater acceptance in the future. From todays point of view both standards will exist in coexistence. Instead of creating facts by deciding for one or the other standard family one main design goal was using the elements of the WS-* standards family to make it possible to support the SAML/Liberty Alliance standards family. Identity Management can be understood in an abstract way and the components building the Identity Management system could support both standards. Such a cross-protocol solution is called Identity- Meta-System and is a realistic goal for future development. Supporting both standard families in an initial implementation might be realistic but not cost-effective. While the given E-Justice communication scenario was clearly Web Service based, we had to support rich client applications resulting in using the standards having the greater acceptance in Web Service based Identity Management. We decided to use the following standards for the S.A.F.E.-concept focusing on the E-Justice communication scenario: SOAP 1.2 [3] WSDL 2.0 [4] for Web-Service communication for Web-Service description WS-Security 1.1 [5] WS-Policy 1.2 [6] for securing SOAP messages on the message layer for specification of the security concept WS-Trust 1.3 [7] for communication with the Identity Provider (IdP, see below)

9 Seite 9 von 16 WS-Federation 1.1 [8] WS-Secure- Conversation 1.3 [9] SPML 2.0 [10] SAML 2.0 (Assertion) [11] Liberty ID-SIS-PP [12] for federation of independent Trust Domains (TD, see below) for speeding up secure message exchange for communication to the Attribute Service (AS, see below) and the Provisioning Service (PS, see below) issued by the IdP to confirm a individuals identity for serializing identity information to XML 3 The S.A.F.E. Concept Table 1: Standards used in the S.A.F.E.-concept As described earlier, the S.A.F.E.-concept is based on the WS-* stack of standards, particularly on WS-Trust [7] and WS-Federation [8]. The S.A.F.E.-Standard is developed by profiling these standards. This means S.A.F.E. is constraining, extending and tailoring these standards and is hence fully conform to the original standards. The goal is to cut back these standards for easier interoperability and thus less implementation costs but to preserve enough flexibility to allow Federated Identity Management (FIM) for various E-Government services. High flexibility is also achieved by the deliberately inserted extensibility of the S.A.F.E.-base standard [1]. Every S.A.F.E.- conform implemented application should again profile the S.A.F.E.-base standard [1] in a similar way as described in the document [2]. This concept is shown schematically in Figure 1. The S.A.F.E.-base document Architecture and Interfaces for Federated Identity Management 1 is profiling the WS-* stack of standards shown at bottom of Figure 1 - to create a common Identity Management infrastructure for E-Government services. An implementation of this core FIM-infrastructure can be developed in.net 2 or JAVA. Then only small changes are necessary to migrate the core FIM-infrastructure to a concrete application. These steps are described in the S.A.F.E.-extension document S.A.F.E. detailed technical concept for the application of E-Justice communication 4. Other application scenarios 3 like GovernmentGateway or Bürgerportale could develop their own slim concepts adapting the FIM-infrastructure to their own application needs. All FIM-implementations based on the core FIM-infrastructure can be made interoperable and can be merged into a large scale federation with Single-Sign-On for different E-Government applications at hand.

10 Seite 10 von 16 SAFE for ejustice communication 4 Interoperability SAFE for GovernmentGatew ay SAFE for... solution Integration Migration Integration Migration Integration Migration SAFE-Concept (Document [2]) SAFE detailed technical concept 3 SAFE-Concept for GovernmentGatew ay SAFE application concept application specification Further Profiling Further Profiling Further Profiling FIM-infrastructure Open Source / Java 2 FIM-infrastructure.NET FIM-infrastructure Implementation Implementation Implementation SAFE-Concept (Document [1]) "Architecture and Interfaces for Federated Identity Management" 1 FIM-specification Profiling Metadata: WS- Policy WS- SecurityPolicy WS-Federation WS-SecureConversation WS-Trust WS-Security standards Messaging: SOAP, WS-Addressing XML Figure 1: S.A.F.E.-Trust-Domain with Services and Identity-Store

11 Seite 11 von Architectural overview The S.A.F.E. federation is organized in Trust-Domains (TD). All S.A.F.E.-TDs have a similar structure and have to provide identical services. The service interfaces are defined in the S.A.F.E.-concept. All subsystems and services in a trust domain maintain a trust relationship. This means, the services trust each other requests. A S.A.F.E.-TD is divided in three subsystems - Attribute Service (AS), Provisioning Service (PS) and Identity Provider (IdP) - each providing external interfaces. An additional internal subsystem is the identity database or Identity-Store, used by the other three subsystems but providing no external interfaces and thus is encapsulated. In Figure 2 the Trust-Domain and its services are depicted schematically. Requestor Trust-Domain Identity- Provider Service- Provider Attribute- Service Provision. Service Identity-Store Domain Identität Attribut x Attribut y Attribut z... Credential Figure 2: S.A.F.E.-Trust-Domain with Services and Identity-Store Attribute Service (AS) The Attribute Service provides information about identities and their attributes. The Attribute service can be queried for single identities or a group of identities. It can also be queried using search criteria, to provide a kind of address-book functionality. The AS provides read only access to the identities, no modification of identity or attribute data is possible.

12 Seite 12 von 16 The Attribute-Service is a realisation of the in WS-Federation [8] only conceptually described Attribute-Service. Its interface is a profiled version of the SPML-standard [10] (Service Provisioning Markup Language) and provides the SPML operations lookup and search. Identity data is transferred using the ID-SIS-PP standard [12], which defines syntax and semantics for serialising an identity with all its attributes into a defined XMLrepresentation. If more then one TD has to combine and federate their identity data a Virtual Attribute Service can be implemented. The Virtual AS queries the Attribute Services of the TDs and combines the identity data. The Virtual AS is transparent, that means it has an SPML interface identical to the interface of a TD-AS; it can query the TD-Attribute Services by only passing on the user query. The WS-Security [5] binding is used to secure the message exchange between client application and AS. Security is established by a symmetric key that is issued by the IdP Provisioning Service (PS) The Provisioning Service provides a consistent interface for data administration services. It allows administrators or users to add, modify or delete identity data. The interface implements the SPML-standard [10] and provides the SPML operations add, modify and delete. While administrators should have general rights to modify the data, users are only able to modify attributes, which were not checked in the registration process. Again a WS-Security [5] binding is used to protect the PS from fraud and provide safe authentication and authorisation via the IdP Identity-Provider (IdP) The Identity-Provider is the central instance for authentication in each TD. Registered users can use the IdP to prove their identity. The IdP confirms the correct authentication of the user by issuing a security token. These security tokens contain information about the identity and the attributes of the user. The user can use the token to claim his identity against a service. Because of the trust relationship between service and IdP the service can be sure of the users identity. Every service that belongs to a Trust Domain has to implement authentication via a security token, in particular also AS and PS.

13 Seite 13 von 16 The S.A.F.E.-IdP confirms authentication by issuing SAML 2.0 [11] assertions as security tokens. These SAML-tokens are profiled to contain the following information about the user: The unique identity descriptor Attributes, especially a role attribute Information about the registration procedure Information about the authentication procedure It is also defined, how this information is syntactically represented in the SAML-token. The implementation of the IdP strictly follows the WS-Trust standard [7]. 3.2 Conceptual features The described architecture was designed to meet specific conceptual features, especially the following: Platform independence - The described services can be implemented on different platforms like.net or JAVA. Interface centric design - S.A.F.E. primarily defines interfaces on the base of open international standards. This leaves a lot of freedom to the developer for the design of specific components but achieves the interoperability of components from different vendors. Scalability - Because S.A.F.E. is an open concept and not restricted to a particular application or subject a high scalability is absolutely necessary. By structuring Identity Management in Trust Domains it is possible to realise also large scale scenarios. Also distributed data ownership can be supported by grouping the Identities for their functional or spatial aspects. Consistent naming conventions for attributes - To maintain a federation it is necessary that all federation partners have the same understanding of the syntax and semantics of attributes. It is necessary for all federation partners to make use of the S.A.F.E. naming conventions. Attribute representations are defined for attribute representation in a SAML-token as well as for the ID-SIS-PP provisioning objects that are used to by AS and PS. Instructions show, how the set of attributes can be extended by new ones. OSCI 2.0 conformity - S.A.F.E. is compatible to the forthcoming transport-standard OSCI 2.0, and it extends OSCI by Identity Management aspects.

14 Seite 14 von 16 Open for various registration methods - In many Identity Management scenarios there is a strong focus set on the possible registration methods, for applying a digital identity and assuring the correctness of the attributes. Surely many different registration methods are possible, all of which have different security and integrity (correctness of the data). The S.A.F.E.-base concept however does not set any guidelines to the registration process; anything is allowed. Establishing a new registration process in a derived application concept, leads inevitably to the question about the security of the registration process. This security level of the registration process has to be put into the SAML-token, so every service can decide if the registration provides enough security for a possible access. Concrete registration methods are described in the derived concept [2] where the concrete services are defined and their demand for security can be evaluated. Registration methods could be: Online self registration without attribute check Registration via PostIdent Registration by a civil servant in presence of the individual Registration by electronically reading an epass Low security High security High security Normal security Table 2: Examples for registration methods Open for various authentication Methods - Like registration methods there are also different authentication methods that provide variable security. Passwords can be guessed, software certificates can be stolen, certificates stored on a smartcard provide higher security. Again concrete authentication methods are described in document [2]. Authentication Methods could be: Username/Password Software Certificates Smartcard Certificate with PIN CardSpace OpenID Normal security Normal security High security High security Normal security Table 3: Examples for authentication methods Confirmation of registration and authentication process - To be able to judge and to trust the information that the IdP confirms in the issued token, it is also necessary to know details about registration and authentication proc-

15 Seite 15 von 16 esses of an identity. The IdP thus has to provide information about these processes. By evaluating this information the accessed service can get an idea of how sure it can be that the IdP provided information is correct. Open design, expandability With the division of the S.A.F.E.-concept into two parts, it is possible and desirable that other concepts for E-Government applications set on top of the S.A.F.E.-base concept and thus first federable and later FIM scenarios are evolving in the whole German governmental sector. 4 Literature [1] S.A.F.E.-Feinkonzept - Dokument 1: System- und Schnittstellenspezifikation Föderiertes Identity-Management (Architecture and Interfaces for Federated Identity Management) [2] S.A.F.E.-Feinkonzept - Dokument 2: IT-Feinkonzept (S.A.F.E. detailed technical concept) [3] W3C, SOAP Version 1.2, 27 Apr ( [4] W3C, Web Services Description Language (WSDL) Version 2.0, 26 Jun ( [5] OASIS, SOAP Message Security 1.1 (WS-Security 2004), 1. Feb ( [6] W3C, Web Services Policy Framework (WS-Policy), 25 Apr ( [7] OASIS, WS-Trust 1.3, 19 Mär ( [8] Diverse, Web Services Federation Language 1.1 (WS-Federation), Dez ( [9] OASIS, WS-SecureConversation 1.3, 1. Mär ( [10] OASIS, Service Provisioning Markup Language (SPML) Version 2, 1. Apr (

16 Seite 16 von 16 [11] OASIS, Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, 15 Mar ( [12] Liberty Alliance Project, Liberty ID-SIS Personal Profile Service Specification V1.1 (