Afiliados al Sistema Privado de Pensiones (SPP)

7.2

The Integration Model

We first observe that there is a noticeable similarity between the message flow within the ID-WSF LEC SSO profile and the message flow within CardSpace. This sim- ilarity can be exploited in order to enable interoperation between the two identity management schemes, which is the approach followed here. This section presents the motivation for this integration proposal, and provides a preliminary discussion of possible integration scenarios.

7.2.1 Motivation

Liberty is currently one of the leading federated identity management systems, and has gained the acceptance of a number of technology-leading companies and organi- sations. In parallel with this, ICIM systems have emerged during the last few years, and have gained the support of well-known organisations such as Microsoft. Prob- ably the best known ICIM system is CardSpace. CardSpace is deployed freely with Windows Vista and Windows 7, and can also be installed on Windows XP systems. However, CardSpace currently only works on Windows platforms, a situation which seems likely to continue, at least for the near future [20]. Given the wide use of Windows, CardSpace is likely to have a significant impact despite this restriction.

Because of their practical importance, enabling interoperation between Liberty and CardSpace is likely to be of significant benefit to a wide range of service providers and users, and will enhance the practicality of both systems. It seems that interoperation between Liberty and CardSpace can be achieved by integrating their frameworks, and this is the approach we follow here.

7.2 The Integration Model

developed by a variety of bodies, including the open source community. These schemes can be used on a range of operating systems. One example is provided by DigitalMe1, which can be regarded as providing CardSpace-like functionality for platforms using the Mac operating system. Given that these rival schemes tend to use a very similar message flow to CardSpace, we believe that the integration approach described in this chapter will also work with such schemes, although the details remain a topic for future research.

We conclude by considering why we have chosen to develop a method of interopera- tion between CardSpace and Liberty ID-WSF LEC SSO profile as opposed to other Liberty frameworks. The main reason for pursuing this approach is the similarity between the CardSpace framework and Liberty ID-WSF LEC SSO profile; this sim- ilarity can be exploited to enable interoperability between Liberty and CardSpace. In particular, both frameworks:

1. require the existence of an enabling component on the user machine; 2. do not require ‘identity federation’;

3. can be used for both authentication and authorisation; 4. support SAML 2.0 assertions; and

5. require IdP discovery to be performed on the user machine.

7.2.2 Discussion

In the case where all SPs and IdPs support at least one of the two identity manage- ment systems (either Liberty or CardSpace, or both), Windows users will face one of the following four scenarios:

1

7.2 The Integration Model

• Scenario A: The IdP supports only one identity management system (either Liberty or CardSpace). In this case, users are only able to access SPs using the identity management system supported by their IdP. This appears likely to be the most common case.

• Scenario B: The IdP supports both identity management systems (Liberty and CardSpace). In this case, the IdP performs the potentially onerous task of maintaining two different identity management systems, thereby providing flexibility to users when they federate their identities with SPs/RPs. Users are able to access services provided by SPs regardless of which identity man- agement system they adopt.

• Scenario C: The SP supports both identity management systems (Liberty and CardSpace). In this case, the SP performs the potentially onerous task of maintaining two different identity management systems. Users are able to access services provided by the SP regardless of which identity management system they adopt.

• Scenario D: The User Agent supports both identity management systems (Lib- erty and CardSpace). In this case, the user agent performs the potentially onerous task of maintaining two different identity management systems. Users are able to access services provided by an SP regardless of which identity man- agement system that it adopts. In this case, the user agent will convert the security tokens (or assertions) to suit the SP. Such an approach relies on the fact that CardSpace can support any token type.

In Scenario A, Windows users have a compatibility problem if the SP is CardSpace- Enabled while their IdP is Liberty-Enabled, or vice versa. Table 7.1 shows the applicability of the identity management systems in the four possible cases, where L-E stands for Liberty Enabled, and CS-E stands for CardSpace Enabled. The (X) sign indicates that there is no compatibility problem, whereas the (×) sign indicates

7.2 The Integration Model

the opposite.

Table 7.1: The applicability of the identity management systems. User L-E IdP CS-E IdP L-E IdP CS-E IdP

Agent L-E SP CS-E SP CS-E SP L-E SP

Unenhanced × × × ×

L-E X × × ×

CS-E × _X × ×

L-E and CS-E _{X X} × ×

A number of integration models for identity management systems have been pro- posed (see Section 4.8.1), many of which are based on scenarios B or C (or both). One example is provided by the method of integration proposed by Project Concor- dia (see Section 4.8.1).

Although most of the integration models are based on scenarios B or C, some SPs and IdPs may not be prepared to accept the burden of supporting two identity management systems and maintaining them simultaneously, at least unless there is a significant financial incentive. Currently, major Internet players such as MSN2 do not support any integration model for identity management systems. We therefore have reason to believe that an integration model based on scenario D could be prac- tically useful. However, no integration model for web-based identity management based on scenario D has previously been proposed.

The CardSpace identity management system consists of two parts:

1. The user agent supporting components: i.e. the Service Requestor and the Identity Selector. These components are responsible for managing the cards and communicating with other parties in the model. It appears that these components could be integrated with Liberty ID-WSF services; however, how this might be achieved remains a possible topic for future research.