Afiliación del trabajador independiente al SNP

6. CEUA←SP : PoAto be presented next time.

After being issued with aPoA, the user will be able to use CardSpace in subsequent login attempts from this host machine.

6.5

Discussion

The proposed methods have the potential to increase the security level of ICIM systems, as they mitigate the risk of SPs being deceived by untrustworthy IdPs. They can also help to make the SP’s judgement regarding the validity of the security token less critical. This will not only enhance the reliability of the system from the perspective of SPs, but will also indirectly benefit users by reducing the risk to information held by SPs on their behalf. These methods should also reduce the significance of ‘token-stealing’ attacks, such as those described by Gajek, Schwenk and Xuan [68].

The Proof-of-Authenticity method assumes that the SP supports two authentica- tion mechanisms, one CardSpace-based and the other not (e.g. username/password). This is not an unreasonable assumption, especially as a similar requirement has been discussed in recent CardSpace specifications (see Section 3.3 of [125]).

The proposed challenge-response method is built on the WS-SecurityPolicy stan- dard, which is widely used in ICIM systems. Hence, integrating the method into currently deployed ICIM systems should be straightforward.

Finally, it merits mentioning that a solution similar to the Proof-of-Authenticity method can also be used with Federated identity management systems, and it offers

6.6 Limitations

to implement a scheme similar to the Challenge-Response method in a Federated identity management system, since there is no SP policy-negotiation step during the authentication process.

6.6

Limitations

One possible disadvantage of the proposed methods is that they have an impact on user mobility. This can be addressed by storing the PoAor the user keys on a portable security token such as a smart card, or by storing them at a trusted third party (or TTP). The latter approach would, however, add complexity to the system.

One obvious limitation of the Proof-of-Authenticity method is that it requires the user to be authenticated at least once using another technique before the ICIM system can be used. However, the security risks of this limitation do not appear to be significant, especially if the user is a frequent visitor to the SP’s web site.

A limitation of the Challenge-Response method is that it requires modifications to the ICIM-enabling components on the user machine (i.e. the Identity Selector), and the SP server (including the SP Security Token Service, an SP server based component responsible for declaring the SP security policy and managing received security tokens).

Another limitation of the Challenge-Response method is that, in the MACed-response mechanism, there is a risk of a malicious IdP masquerading as one of its client users to register with an SP. In such a case, the malicious IdP could obtain the shared secret key from the SP, and thus would be able to produce valid responses to SP challenges. This risk could be mitigated if the SP performs a robust user authenti- cation procedure during the registration process. For example, the SP could ask the

6.7 Conclusions

registrant to submit an activation-code sent to the submitted email address and/or mobile number, or it could ask the registrant to enter the last three digits printed on the reverse of the credit card for a submitted card number.

A further limitation is the key management overhead. However, if the shared key is compromised or stolen by an attacker, then it would not by itself give immediate access to the SP, since it only provides an additional layer of authentication. That is, the key management process is arguably less security-critical than in many other applications.

6.7

Conclusions

In this chapter we have proposed two independent methods to enhance user au- thentication in ICIM systems, namely the Proof-of-Authenticity method and the Challenge-Response method. These methods, if implemented correctly, provide the SP with an implicit indication that a log-in attempt was initiated by the legitimate user. A proof-of-concept implementation of the first method has been described.

The proposed techniques add a certain degree of complexity and overhead to the system. However, implementing them should help to enhance the accuracy of the SP judgement of the authenticity of the user.

Chapter 7

Integrating Information Card-based

and Federated identity management

systems

Contents

7.1 Introduction . . . 185

7.2 The Integration Model . . . 186

7.2.1 Motivation . . . 186

7.2.2 Discussion . . . 187

7.3 Integrating the Two Schemes . . . 190

7.3.1 Restrictions and assumptions . . . 191

7.3.2 Message flows . . . 192

7.4 An Analysis of the Integration Model . . . 197

7.5 Prototype Implementation . . . 199

7.5.1 The Prototype Framework . . . 201

7.5.2 Technical Details . . . 203

7.5.3 Operational Details . . . 203

7.6 Related Work . . . 207

7.7 Conclusions . . . 208

Over the last few years, many identity management schemes and frameworks have been proposed; however they are typically not interoperable. In this chapter we pro-

7.1 Introduction

pose an approach to enable interoperation between two of the most widely discussed identity management schemes, namely the Liberty Alliance Project ID-WSF LEC SSO profile (a Federated identity management scheme) and the Microsoft CardSpace framework (a ICIM scheme). This approach to integration enhances the practicality of both schemes by enabling users to make use of identity management systems even if other system participants are using different schemes. The main advantages and disadvantages of the proposed integration model are described. A prototype imple- mentation of the proposed integration scheme is also discussed. Much of the material in this chapter has previously been published in [8, 10].

7.1

Introduction

As we have described, a number of identity management systems have been proposed and deployed. These systems are typically not interoperable, which makes it difficult to use them in open environments such as the Internet.

This chapter proposes an approach designed to help address this problem. Specif- ically, it proposes a method to enable interoperation between the Liberty Alliance Project and the Microsoft CardSpace schemes (see Sections 4.2 and 4.4).

The remainder of this chapter is organised as follows. Section 7.2 presents the proposed integration model, and the message flows are described in Section 7.3. In Section 7.4 we provide an operational analysis, and in Section 7.5 we describe a prototype implementation. Section 7.6 contains a brief review of related work, and Section 7.7 concludes the chapter.