Title: ON MULTI-STAGE BUSINESS PROCESSES

Shibboleth does not consider an authentication and attribute exchange of a customer to service providers via his proxy in multi-stage business processes. The application of Shibboleth in multi-stage business processes is shown in Figure 5.5. The authentication of customer’s proxy is done in step 5. So that a proxy is able to prove a specific identity of a customer towards a subordinate service provider, the proxy needs the corresponding credential. The identity provider issues such a credential but only if the proxy is able to prove his authorisation for the access on customer’s data. The only possibility for a proxy to get a credential to customer’s data is to authenticate as his customer. Therefore, the proxy needs to use the secure authentication token of his customer towards the corresponding identity provider. A delegation of this secret authentication token to his proxy results in an unrestricted access for his proxy on customer’s identity. This proxy could modify the privacy policy of the customer and abuse customer’s identity for own purposes. By using the transcript of a protocol run, it is not possible to distinguish whether a customer or his proxy has used a given identity of the customer. Consequently, a customer loses control on the disclosure of his identity, if he delegates his secure authentication token to a proxy. Additionally, a proxy becomes a “Big Brother”, since he has access to all pseudonyms and personal data of the customer. Therefore, he is able to retrace all transactions of this customer. A complete profiling is possible. Finally, privacy is only preserved in multi-stage business processes, if the customer trusts his proxy with respect to the negotiated use of his delegated secure authentication token. But this is a contradiction to the assumption of an untrustworthy proxy, as assumed in the threat analysis of section 2.

Figure 5.5 Applying Shibboleth on a business process with one proxy. Security Properties of Shibboleth

Security Properties of

The specification (Carmody, Erdos, Hazelton, Hoehn, BobMMorgan, Scavo and Wasley, 2005) considers a man-in-the-middle attack on the communication between the participants of the protocol. This attacker aims to get knowledge about customer’s data and to intercept a credential in order to use it for impersonation. The specification proposes the use of a digital signature as a countermeasure for impersonation attacks. Shibboleth has the following security properties with respect to privacy of customers and accountability interests of service providers:

1. Secure data storage: The specification assumes a directory service according to LDAP for storing customer’s data. LDAP supports the use of an access control on the managed data (Yeong, Hows and Kille, 1995).

2. Situation-dependent disclosure of personal data: Shibboleth. Additionally, the protocol specification does not consider an interaction between a customer and his service provider with respect to an attribute request during a protocol run. So, a customer is not able to decide ad hoc on the disclosure of personal data.

3. Unlinkability of transactions: Shibboleth supports the use of pseudonyms, especially of transaction pseudonyms. A pseudonym is the value of the credential attribute <saml:NameIdentifier> in lieu of the customer name which is used for an authentication at the identity provider. By using transaction pseudonyms, customer’s transactions seem to be independent with respect to the customer. However, since the identity provider of a customer is involved in each authentication, the identity provider knows all customer transactions and is able to create a profile. A customer has to trust his identity provider that the identity provider does not publish or delegate this knowledge about his customer.

4. Authentification without showing identifying data: Customer’s data are disclosed by means of a credential. These data are a by the credential attribute called <saml:AttributeValue xsi:type=”xsd:anyURI”> … </saml:AttributeValue>. Shibboleth does not limit the type and values of attributes. Therefore it is possible for an identity provider to certify a property of customer’s data instead of their values which may unambiguously identify a customer.

5. Non-repudiation of customer’s transactions: A customer proves his identity towards his identity provider by his secure authentication token. Thus, only the owner of this token, the given customer, is able to give a valid proof of his identity. Based on a valid authentication proof, an identity provider certifies the identity of this customer towards a requesting service provider. Therewith a relationship exists between a given transaction of a customer and to the identity of this customer. An identity provider is able to show this relationship.

6. Revoking customer’s anonymity in case of fraud: Since an identity provider knows the relationship between the identity of a customer and his pseudonyms which are used by the customer in his transactions, an identity provider is able to revoke the anonymity of a customer in case of fraud.

However, Shibboleth does not support authorisation for an access on customer’s data which could be delegated to a proxy. As the application of the authentication protocol on multi-stage business processes shows, a customer would have to delegate his secure authentication token to his proxy. It follows that a customer would lose control on his identity, since a proxy would have unrestricted access on customer’s identity by using this authentication token. Consequently, privacy is only preserved as long as Shibboleth is used in single-stage business processes.

Conclusion

By using the identity management system Shibboleth, a customer is able to preserve his privacy against undesired identification, profiling, and linkability of his transactions by deciding on the access on personal data. Since the identity of a customer is managed by solely one identity provider and all authentication of a customer are carried out via his identity provider, this identity provider is able to create a complete profile about his customer. It is not possible for a customer to control the use of this knowledge at his identity provider. Therefore, a customer has to trust his identity provider with respect to the use of his identity.

This mandatory trust relationship will have to be extended to customer’s proxy, if Shibboleth is used in business processes with proxies. Shibboleth does not consider a usage control on disclosed customer’s data and consequently is not suitable as a security mechanism according to customer’s privacy interests in multi-stage business processes.

Single-Sign On with Several Identity Providers:

Liberty Alliance (Liberty Alliance, 2005) is also a specification for a web-based identity management system similar to Shibboleth. The aim of Liberty Alliance is Single-Sign On and an attribute exchange between customers and service providers via one or more identity providers. A customer is able to decide whom to give his personal data according to the situation. A situation is thereby defined by the URL of the given service. The specification consists of two parts: Liberty Identity Federation Framework (ID-FF) specifies the basic system for an SSO with pseudonyms in different application domains (Circles of Trust), and Liberty Alliance Web Services Framework (ID-WSF) as the extension for an attribute exchange and delegation of authorisations to service providers for an access on personal data. The classification of service providers and identity providers with respect to their application domain and the use of delegable authorisations are two main differences to Shibboleth. The aim of this section is to investigate on the identity management system of Liberty Alliance in order to identify its security properties concerning privacy interests of customers and security interests of service providers.

The Authentication Model of