Title: BUSINESS PROCESSES AND IDENTITY MANAGEMENT

Business Processes and Identity Management

David Chaum introduces the idea of identity management in 1985 (Chaum, 1985). He considers privacy threats by undesired information flow and abuses while customers authenticates themselves towards service providers and introduces an approach for identification by digital pseudonyms and credentials for certified personal data. Therefore, an unique and verifiable identification of a customer is possible which prevents at the same time undesired data collection and linkability of the collected data. Verification of a customer’s identity is achieved by using credentials. The meaning of a credential is a certified statement based on a customers’ “relationship with organisations that are, in general, provided to other organisations” (Chaum, 1985). Organisations would profit by the small amount of customer data which has to be protected against abuse. Additionally, a customer remains identifiable by using Chaum’s system. Furthermore, David Chaum proposes a personal mobile device, a card computer, for a customer who stores customer’s pseudonyms and credentials in a protected storage.

Nowadays, the development of identity management systems aims from two sides. Scientific developments, such Dresden Identity Management (DRIM) of the TU Dresden (Kriegelstein, 2002), as iManager of the University of Freiburg (Jendricke and Gerd tom Markotten, 2000; Wohlgemuth, Jendricke, Gerd tom Markotten, Dorner and Müller, 2004), and of the anonymous credential system of Stefan Brands (Brands, 2000) as well as of the system of Jan Camenisch and Anna Lysyanskaya IBM idemix (Camenisch and Lysysanskaya, 2001; Camenisch and Van Herreweghen, 20002) aims primarily at customer’s privacy. Industrial developments, such as Liberty Alliance (Liberty Alliance, 2005), Microsoft .NET Passport (Microsoft, 2003), and Security Assertion Markup Language (SAML) (Maler, Mishra and Philpott, 2003) standardised by Organisation for the Advancement of Structured Information Standards (OASIS) aims primarily at a authentication system for a Single-Sign On (SSO). An identity management focusing both on SSO and on privacy is Shibboleth (Carmody, Erdos, Hazelton, Hoehn, BobMMorgan, Scavo and Wasley, 2005; Dors, 2005) by the consortium Internet2.

All identity management systems are based on existing public key infrastructures (PKI) for issuing and verifying credentials. Whereas a certification authority (CA) takes up an additional role depending on the identity management system. The main tasks of a CA are to certify statements of customers, issue credentials with respect to these statements, and revoking them. Concerning identity management systems such as Microsoft .NET Passport, Shibboleth, and Liberty Alliance, a CA also manages personal data of their customers. This means that a CA securely stores customer’s data and discloses them upon request of service providers and according to customer’s privacy policy. Such a CA is called identity provider.

The aim of this section is to investigate on current identity management systems whether they fulfil the security requirements of section 2.3 for access control and usage control on customer’s data in combination with the security interests of service providers towards accountability. Current identity management systems are classified by the role of a CA and customer’s trust in it with respect to his privacy. Identity management systems either use one CA as an identity provider, e.g., Microsoft .NET Passport and Shibboleth, several CA as identity providers for different domains, e.g., Liberty Alliance, a common CA, e.g., iManager, and a CA without mandatory trust of customers, e.g., IBM idemix. In the following, the mentioned identity management systems are examined as representatives of these identity management classes. An exception is Microsoft .NET Passport. Microsoft .NET Passport does not preserve customer’s privacy. Each customer has a global unique identifier. Furthermore, a service provider will get access on the complete customer’s data at the global CA upon request. So, there is no access control on customer’s data according to the security requirements of section 2.3.

Single-Sign On with One Identity Provider:

Shibboleth is a web-based identity management system with one identity provider which issues credentials for his customers. It aims at a SSO of customers and an attribute exchange of customer’s data to service providers. A customer logs on an identity provider. Afterwards, a customer does not need to log explicitly on other service providers, since this identity provider confirms this authentication to service providers by a credential. This credential contains also the requested customer’s data, if the customer has agreed to this attribute exchange. A customer is able to act with pseudonyms and to decide on the disclosure of personal data while the access control is managed by the identity provider on behalf of a customer. Shibboleth is based on the standard SAML V1.1 (Maler, Mishra and Philpott, 2003) and presumes a web browser without any extensions. The following investigation on Shibboleth concerning it as a security mechanism for private data is based on its specifications (Carmody, Erdos, Hazelton, Hoehn, BobMMorgan, Scavo and Wasley, 2005; Dors, 2005).

Model and Authentication Protocol

The participants of the model are customers, an identity provider, service providers, and optional a lookup service called WAYF (Where are you from?). Shibboleth supports two variants for authentication and attribute exchange: Browser/Post and Browser/Artifact protocol.

A customer is identified by his name and disclosed personal data. These data are managed by one identity provider who is part of the trust domain of this customer. An identity provider certifies statements about the identity of a customer by means of attribute certificates (credentials). So, an identity provider takes up the role of a certification authority. Service providers trust an identity provider that this identity provider certifies customer’s identity according to his certification policy. The identity of a customer is protected against unauthorised access by the identity provider. This is a presumption for a controlled disclosure of personal data by the customer. A service provider offers a web-based service and protects it by an access control. Based upon the identity of a customer, a service provider gives or denies access to his service to a requesting customer. The centralised lookup service WAYF is used, if a service provider does not know the address of the identity provider. This service redirects the authentication request of a service provider to customer’s identity provider.

The protocol variants Browser/Post und Browser/Artifact differs in the kind of attribute exchange. Regarding the Browser/Post protocol, a service provider receives customer’s data by means of a credential which has been issued by the identity provider of the corresponding customer. Regarding the Browser/Artifact protocol, a service provider receives a token by the customer. By using this token, a service provider is allowed to get access on customer’s data at his identity provider. Both variants are adopted from SAMLV1.1 and extended by the WAYF service. The protocol variant Browser/Post as specified in (Carmody, Erdos, Hazelton, Hoehn, BobMMorgan, Scavo and Wasley, 2005) is described in the following. Figure 5.4 shows the message flow of this protocol. The dashed flows and the use of the WAYF service are optional. As the message flow shows, the identity provider of a customer is involved in each authentification and attribute exchange.

Step 1 request a service of a service provider by a customer. The customer uses a web browser for his service request. Step 2 represents the authentication request of a service provider to his customer. If the address of customer’s identity provider is not known to this service provider, the authentication request is posed to the WAYF service. The WAYF service redirects this request to the identity provider of this customer in step 3. Otherwise, the request is posed directly to the corresponding identity provider. Step 4 asks the customer to log on at his identity provider, if he has not already done it. The customer uses a secret token, e.g., a password, for his authentication towards his identity provider. This secret token is solely known to him and his identity provider. The identity provider certifies the identity of the customer for the requesting service provider in step 5. The result is either a credential or an error message. Latter is sent, if the customer could not authenticate himself. Step 6 and 7 realise the attribute exchange between a customer and the requesting service provider via the identity provider. Therefore, the service provider proves his authorisation by the credential which he has got in step 5. A disclosure of customer’s attributes is done with respect to the negotiated policy between the customer and his identity provider. Based on the credential and customer’s data, the service provider grants or denies access to his services to the requesting customer in step 8.

Figure 5.4 Authentification by using the Browser/Post protocol of Shibboleth.

Applying