WO2012072098A1

WO2012072098A1 - Cross-authentication arrangement

Info

Publication number: WO2012072098A1
Application number: PCT/EP2010/068389
Authority: WO
Inventors: Gabor Marton; Markus Bauer-Hermann; Norbert Goetze; Robert Seidl; Hannes Tschofenig
Original assignee: Nokia Siemens Networks Oy
Priority date: 2010-11-29
Filing date: 2010-11-29
Publication date: 2012-06-07

Abstract

Various arrangements for providing SIP-to-HTTP and HTTP-to-SIP cross-authentication are described. In use, a SIP client and an HTTP client of a user device both seek to access one or more service providers and both need to be authenticated. The invention enables the authentication of one of the SIP client and the HTTP client to be used by the other. Accordingly, a single-sign-on arrangement can be provided.

Description

Title Cross-Authentication Arrangement

The invention is related to cross-authentication. In

particular, the invention is related to SIP-to-HTTP and HTTP- to-SIP cross-authentication.

Session Initiation Protocol (SIP) is a signalling protocol that is widely used for setting up and tearing down

multimedia communication sessions such as voice and video calls over the Internet. SIP is the signalling protocol of the IP Multimedia Subsystem (IMS) and is also used in many other applications. SIP is also supported, for example, by Skype .

Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia

information systems. The use of HTTP for retrieving interlinked resources led to the establishment of the World Wide Web. Identity brokering solutions (such as Liberty/SAML, OpenID,

Windows CardSpace, and GBA) support service providers in end- user authentication. They do so such that a dedicated entity (usually called the Identity Provider or IDP) assumes the burden of authentication, instead of the service provider (SP) . Typically, authentication is performed between the user's device and the identity provider. The service provider then receives an authentication assertion containing a service provider-specific user identifier from the identity provider. The service provider then provides the service to the user based on the received user identifier. For the rest of the communication session, the service provider can use its own means for associating the obtained user identity with the session, e.g. by means of cookies or using transport layer security (TLS) . Thus, the user can be provided with single sign-on across service providers.

In use, a SIP client and an HTTP client typically function alongside one another within a user device (such as a

personal computer (PC) or a mobile communication device) . In many applications, both the SIP client and the HTTP client need to be authenticated by the end service, but it would be desirable if the user/subscriber only needed to be

authenticated once (thereby providing a single sign-on arrangement) .

The present invention seeks to address at least some of the problems outlined above.

The present invention provides a method comprising: using a session initiation protocol (SIP) client of a user device to authenticate the user device at an internet protocol

multimedia subsystem (IMS); obtaining identification

information from the internet protocol multimedia subsystem at the session initiation protocol client; sharing the identification information with a hypertext transfer protocol (HTTP) client of the user device; and using the hypertext transfer protocol client to communicate with an identity provider, wherein the identity provider is provided with the said identification information and wherein, in use, the identity provider uses the identification information to determine the identity of the user device on the basis of the authentication of the user device at the internet protocol multimedia subsystem.

The identification information may be shared with the HTTP client in many different ways. For example, sharing the identification information with the HTTP client of the user device may comprise sending the said identification

information to the HTTP client of the user device.

Alternatively, or in addition, sharing the identification information with the HTTP client of the user device may comprise storing the information in a data store (such as a memory) to which the HTTP client of the user device has access . The identification information itself may take many different forms. In some forms of the invention, the identification information is a hypertext transfer protocol uniform resource locator. The hypertext transfer protocol uniform resource locator may contain a nonce (i.e. a number used once ) .

The hypertext transfer protocol uniform resource locator (URL) may be sent from the IMS to the SIP client of the user device. The URL may be subsequently sent from the SIP client of the user device to the HTTP client of the user device. For example, the HTTP URL may be sent from an application server (AS_IDP) of the IMS.

The said HTTP client may be launched in response to receiving said hypertext transfer protocol uniform resource locator.

In some forms of the invention, the said HTTP uniform

resource locator points the HTTP client to the said identity provider . In some forms of the invention, the identification

information comprises a globally routable user agent uniform resource indicator (GRUU) . The said globally routable user agent uniform resource indicator may be obtained from the internet protocol multimedia subsystem by the SIP client of the user device and may be subsequently sent from the SIP client of the user device to the HTTP client of the user device .

In many forms of the invention, the identification

information comprises a nonce (i.e. a number used once) .

In many forms of the invention, the identification

information comprises a cookie. The said cookie may contain the user's registered IMPU(s). Alternatively, or in

addition, the cookie may contain a nonce.

In a SIP-to-HTTP cross-authentication arrangement, when the HTTP client seeks to access a service, an authentication request sent to the said identity provider may be accompanied with the said cookie, thereby enabling the identity provider to authenticate the user device. For example, the

authentication request (e.g. OpenID, Liberty, SAML) may be transmitted to the identity provider by means of HTTP, the housing HTTP request may contain the cookie (the Cookie header) .

In some forms of the invention, the identification

information is stored at a proxy, wherein the SIP client communicates with the internet protocol multimedia subsystem via the proxy and the HTTP client communicates with the identity provider via the proxy. In some forms of the invention, the identification

information comprises a certificate. In a SIP-to-HTTP cross- authentication arrangement, the certificate may be obtained by the SIP client of the user device and stored at a

certificate store (typically, but not necessarily, of the user device) , wherein the HTTP client of the user device has access to the certificate store.

The said identification information may comprise a

cryptographic key. In a SIP-to-HTTP cross-authentication arrangement, the cryptographic key may be obtained by the SIP client of the user device and may be stored at a

cryptographic key store of the user device and the HTTP client of the user device may have access to the

cryptographic key store.

The present invention also provides a method comprising:

using a hypertext transfer protocol (HTTP) client of a user device to authenticate the user device at an identity provider (IDP); obtaining identification information from the identity provider at the hypertext transfer protocol client; sharing the identification information with a session

initiation protocol (SIP) client of the user device; and using the session initiation protocol client to communicate with an internet protocol multimedia subsystem, wherein the internet protocol multimedia subsystem is provided with the said identification information and wherein the internet protocol multimedia subsystem uses the identification

information to determine the identity of the user device on the basis of the authentication of the user device at the identity provider.

Sharing the identification information with the SIP client may be achieved in many different ways. For example, sharing the identification information with the SIP client of the user device may comprise sending the said identification information to the SIP client of the user device.

Alternatively, or in addition, sharing the identification information with the SIP client of the user device may comprise storing the information in a data store (such as a memory) to which the SIP client of the user device has access . The said identification information may comprise a nonce (i.e. a number used once) .

In some forms of the invention, the identification

information comprises a cookie. The cookie may contain the user's registered IMPU(s). Alternatively, or in addition, the cookie may contain a nonce.

In an HTTP-to-SIP cross-authentication arrangement, when the SIP client seeks to access a service, an authentication request sent to the IMS would typically be accompanied with the said cookie, thereby enabling the IMS to authenticate the user device. The identification information may be stored at a proxy, wherein the session initiation protocol client communicates with the internet protocol multimedia subsystem via the proxy and the hypertext transfer protocol (HTTP) client

communicates with the identity provider via the proxy.

The identification information may comprise a certificate. In an HTTP-to-SIP cross-authentication arrangement, the said certificate may be obtained by the HTTP client of the user device and stored at a certificate store (typically, but not necessarily, of the user device) , wherein the SIP client of the user device has access to the certificate store.

In the use of the invention, either the SIP client or the HTTP client may derive a temporary certificate (for example using the SIP CERT method) . The SIP client may then share the certificate with the HTTP client (or the HTTP client may share the certificate with the SIP client) , for example by storing the temporary certificate within a certificate store. Thus, when the HTTP client accesses a service provider and communicates with the identity provider to authenticate the user, the temporary certificate can be used in a transport layer security (TLS) session. Similarly, when the SIP client accesses a service provider and communicates with the IMS to authenticate the user, the temporary certificate can be used in a TLS session.

The identification information may comprise a cryptographic key. In an HTTP-to-SIP cross-authentication arrangement, the cryptographic key may be obtained by the HTTP client of the user device and may be stored at a cryptographic key store of the user device. The SIP client of the user device may have access to the cryptographic key store. The present invention further provides a user device

comprising a session initiation protocol (SIP) client and a hypertext transfer protocol (HTTP) client, wherein: the session initiation protocol (SIP) client is configured to authenticate the user device at an internet protocol

multimedia subsystem (IMS), obtain identification information from the internet protocol multimedia subsystem and to share the identification information with the hypertext transfer protocol (HTTP) client of the user device; and the hypertext transfer protocol client is configured to communicate with an identity provider, wherein the identity provider is provided with the said identification information and wherein the identity provider uses the identification information to determine the identity of the user device on the basis of the authentication of the user device at the internet protocol multimedia subsystem.

information to the HTTP client of the user device.

Alternatively, or in addition, sharing the identification information with the HTTP client of the user device may comprise storing the information in a data store (such as a memory) to which the HTTP client of the user device has access . The identification information itself may take many different forms, such as an HTTP URL, a globally routable user agent uniform resource indicator (GRUU) , a certificate and/or one or more cryptographic keys. The identification information may comprise a nonce.

Alternatively, or in addition, the identification information may comprise a cookie. The said cookie may contain the user's registered IMPU(s). Alternatively, or in addition, the cookie may contain a nonce.

In some forms of the invention, the identification

information is stored at a proxy, wherein the SIP client of the user device communicates with the IMS via the proxy and the HTTP client of the user device communicates with the identity provider via the proxy.

The present invention yet further provides a user device comprising a session initiation protocol (SIP) client and a hypertext transfer protocol (HTTP) client, wherein the hypertext transfer protocol client is configured to

authenticate the user device at an identity provider, obtain identification information from the identity provider and share the identification information with the session

initiation protocol (SIP) client of the user device; and the session initiation protocol client is configured to

communicate with an internet protocol multimedia subsystem, wherein the internet protocol multimedia subsystem is provided with the said identification information and wherein the internet protocol multimedia subsystem uses the

identification information to determine the identity of the user device on the basis of the authentication of the user device at the identity provider.

Alternatively, or in addition, sharing the identification information with the SIP client of the user device could comprise storing the information in a data store (such as a memory) to which the SIP client of the user device has access.

The said identification information may take a variety of different forms, such as a nonce or a cookie. The

identification information may also be a certificate or one or more cryptographic keys.

The identification information may be stored at a proxy, wherein the SIP client communicates with the IMS via the proxy and the HTTP client communicates with the identity provider via the proxy.

The present invention also provides a computer program comprising: code (or some other means) for using a session initiation protocol (SIP) client of a user device to

authenticate the user device at an internet protocol

multimedia subsystem (IMS); code (or some other means) for obtaining identification information from the internet protocol multimedia subsystem at the session initiation protocol client; code (or some other means) for sharing the identification information with a hypertext transfer protocol (HTTP) client of the user device; and code (or some other means) for using the hypertext transfer protocol client to communicate with an identity provider, wherein the identity provider is provided with the said identification information and wherein the identity provider uses the identification information to determine the identity of the user device on the basis of the authentication of the user device at the internet protocol multimedia subsystem. The computer program may be a computer program product comprising a computer- readable medium bearing computer program code embodied therein for use with a computer. The present invention further provides a computer program comprising: code (or some other means) for using a hypertext transfer protocol (HTTP) client of a user device to

authenticate the user device at an identity provider (IDP); code (or some other means) for obtaining identification information from the identity provider at the hypertext transfer protocol client; code (or some other means) for sharing the identification information with a session

initiation protocol (SIP) client of the user device; and code (or some other means) for using the session initiation protocol client to communicate with an internet protocol multimedia subsystem, wherein the internet protocol

multimedia subsystem is provided with the said identification information and wherein the internet protocol multimedia subsystem uses the identification information to determine the identity of the user device on the basis of the

authentication of the user device at the identity provider. The computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.

The invention may also provide a method comprising: using a session initiation protocol (SIP) client of a user device to communicate with an internet protocol multimedia subsystem (IMS) using a channel and using the internet protocol

multimedia subsystem to authenticate the user device; making the channel available to a hypertext transfer protocol (HTTP) client of the user device, such that the hypertext transfer protocol (HTTP) client of the user device is able to

communicate with an identity provider (IDP) using said channel and such that the identity provider is able to determine the identity of the user device. The invention may also provide a user device for implementing the said method.

The invention may also provides a method comprising: using a hypertext transfer protocol (HTTP) client of a user device to communicate with an identity provider using a channel and using the identity provider to authenticate the user device; making the channel available to a session initiation protocol (SIP) client of the user device, such that the session initiation protocol (SIP) client of the user device is able to communicate with an internet protocol multimedia subsystem using said channel and such that the internet protocol multimedia subsystem is able to determine the identity of the user device. The invention may also provide a user device for implementing the said method.

The invention may also provide a method comprising: using a session initiation protocol (SIP) client of a user device to communicate with an internet protocol multimedia subsystem (IMS) via a local proxy and using the internet protocol multimedia subsystem to authenticate the user device; using a hypertext transfer protocol (HTTP) client of the user device to communicate with an identity provider via the local proxy; and using identification information relating to the

authentication of the user device by the internet protocol multimedia subsystem to enable the identity provider to determine the identity of the user device.

The identity information may be obtained from the IMS. The identity information may be made available to the identity provider via the channel. The invention may also provide a user device for implementing the said method.

The invention may also provide a method comprising: using a hypertext transfer protocol (HTTP) client of a user device to communicate with an identity provider via a local proxy and using the identity provider to authenticate the user device; using a session initiation protocol (SIP) client of the user device to communicate with an internet protocol multimedia subsystem (IMS) via the local proxy; and using identification information relating to the authentication of the user device by the identity provider to enable the internet protocol multimedia subsystem to determine the identity of the user device. The invention may also provide a user device for implementing the said method.

Exemplary embodiments of the invention are described below, by way of example only, with reference to the following numbered drawings . Figure 1 is a block diagram of a system in which the present invention may be used;

Figure 2 is a flow chart of an algorithm in accordance with an aspect of the present invention;

Figure 3 is a block diagram of a system in accordance with an aspect of the present invention;

Figure 4 is a message flow diagram in accordance with an aspect of the present invention; Figure 5 is a flow chart of an algorithm in accordance with an aspect of the present invention;

Figure 6 is a flow chart of an algorithm in accordance with an aspect of the present invention;

Figure 7 is a block diagram of a system in accordance with an aspect of the present invention;

Figure 8 is a flow chart of an algorithm in accordance with an aspect of the present invention;

Figure 9 is a block diagram of a system in accordance with an aspect of the present invention;

Figure 10 is a flow chart of an algorithm in accordance with an aspect of the present invention;

Figure 11 is a flow chart of an algorithm in accordance with an aspect of the present invention; and

Figure 12 is a flow chart of an algorithm in accordance with an aspect of the present invention.

Figure 1 is a simplified block diagram of a system, indicated generally by the reference numeral 1, in which the present invention may be used. The system 1 makes use of both SIP- based and HTTP-based authentication methods.

The system 1 comprises a user device 2, an IP multimedia subsystem (IMS) 4, a first service provider 6, a second service provider 8, a third service provider 10 and an identity provider (IDP) 22. The user device 2 comprises a processor 12, a memory 14, a session initiation protocol (SIP) client 16 and a hypertext transfer protocol (HTTP) client 18. The processor 12 controls at least some of the functions of the user device 2. The processor 12 is

typically implemented with a microprocessor, a signal

processor or separate components and associated software. The memory 14 may store various software and data required in the operation of the user device 2. The memory may be

integrated into the processor, or may be provided separately, as shown in Figure 1. The user device 2 uses the SIP client 16 to communicate with the IMS 4 and with the first service provider 6, wherein both the IMS 4 and the first service provider 6 use SIP to

authenticate the user device 2. The user device 2 uses the HTTP client 18 to communicate with the second service

provider 8 and the third service provider 10. The HTTP client 18 communicates with the second and third service providers via a network, such as Internet 20. The second and third service providers use the IDP 22 (which is also coupled to the network 20) to authenticate the user device 2.

The use of the SIP client 16 to authenticate a user towards the IMS 4 and the first service provider 6 is well known. The use of the HTTP client 18 and the IDP 22 to authenticate a user towards the second service provider 8 and the third service provider 10 is also well known.

In the system 1, the SIP client 16 and the HTTP client 18 function alongside one another. This situation is known, for example, in the converged Internet/telco world, where a communication services provider (CSP) may offer its

subscribers multimedia services by means of SIP/IMS, a web portal via HTTP, and the CSP may also provide authentication of its own subscribers as a service to third-party service providers (thereby providing the IDP functionality) . All of these services require user authentication. The present invention seeks to provide arrangements in which the user device only needs to be authenticated once (thereby providing a single sign-on arrangement) .

Figure 2 is a flow chart, indicated generally by the

reference numeral 30, of an algorithm in accordance with an aspect of the present invention. The algorithm starts at step 32, where the user device 2 connects to a network and launches an application, such as an application provided by the first service provider 6 (which application uses SIP for authentication purposes, as indicated above) . Next, at step 34, the user is authenticated by the IMS 4; the authentication may, for example, rely on a smartcard ( ISIM/USIM/SIM application) or a username/password pair. Other mechanisms by which the IMS 4 might authenticate the user device 2 will be known to the skilled person. Once the authentication step 34 is complete, the application launched in step 32 can be used.

Next, the user decides to access a service via HTTP. In order to do so, the user first launches a suitable browser, namely the HTTP client 18 (step 36) . The service is then accessed via HTTP (step 38) by pointing the browser to a Uniform Resource Locator (URL) for the service. Although the service accessed in step 38 requires authentication of the user, this is achieved by virtue of the IMS authentication performed at step 34, as described in detail below.

Thus, in the algorithm 30, the user is not required to perform any further authentication for the HTTP session; the user therefore experiences single sign-on across the SIP and HTTP domains.

A number of implementations and variations of the algorithm 30 are described below. In each solution, the SIP and HTTP clients on the user's device share some information. This shared information is then used by the IDP on the HTTP "leg" to associate the HTTP session with the authentication session on the SIP "leg". Some of the solutions can also be used in the opposite direction i.e. for HTTP-to-SIP cross-authentication. Such algorithms involve an application being launched via the HTTP client 18 and an HTTP authentication being carried out. A subsequent application launched via the SIP client 16 then makes use of the HTTP authentication.

First Example In the first example, the shared information is a nonce in an HTTP URL (uniform resource locator) passed from the IMS to the SIP client and then from the SIP client to the HTTP client (browser) .

Figure 3 is a block diagram of a system, indicated generally by the reference numeral 40, in which the first example of the invention may be used. The system 40 comprises the user device 2, an IMS 44, an IDP 46 and a service provider 48. The IMS 44, IDP 46 and service provider 48 are similar to the IMS 4, IDP 22 and service provider 10 described above.

The IMS 44 comprises a *-CSCF module 50, a home subscriber service (HSS) 52 and an AS_IDP module 54. (As is well known in the art, the notation *-CSCF is shorthand for the chain of P-CSCF, I-CSCF and S-CSCF of IMS 44, where CSCF is an acronym for Call Session Control Function.)

In one implementation of the system 40, the elements *-CSCF 50, HSS 52, AS_IDP 54 and possibly also the identity provider 46 reside in the realm of a communication service provider (CSP) behind firewalls. The service provider 48 (which may be an Internet service) is generally external to the CSP. As shown in Figure 3, the SIP client 16 of the user device 2 is in two-way communication with the *-CSCF module 50 of the IMS 44, the HTTP client 18 of the user device 2 is in two-way communication with the IDP 46 and the service provider 48 and the IDP 46 is also in two-way communication with the AS_IDP 54. The HTTP client 18 may communicate with the IDP 46 and the service provider 48 directly (as shown in Figure 3) or via a network (such as the network 20 as shown in Figure 1) .

In the block diagram 40, the AS_IDP 54 is shown as being a part of the IMS 44. This is not essential to all forms of the invention. The AS_IDP is an application server.

Application servers can be thought of as functions on top of IMS and, although often implemented as part of the IMS, can be provided as separate modules.

Figure 4 is a message sequence, indicated generally by the reference numeral 60, demonstrating an exemplary use of the system 40 in accordance with the first example implementation of the invention.

The message sequence 60 starts with the SIP client 16 of the user device 2 registering with the IMS 44. This is shown in Figure 4 by a SIP REGISTER message 62 being sent from the user device 2 to the IMS 44. As is well known in the art, the SIP REGISTER message 62 involves the *-CSCF 50 and the HSS 52 of the IMS 44. In response to the message 62, an OK message 64 is sent from the IMS 44 to the user device 2.

The user's initial Filter Criteria (iFC) (which reside in the IMS and are used by the S-CSCF) are configured such that SIP REGISTER messages are forwarded to the AS_IDP 54.

Accordingly, the IMS 44 (or more specifically the S-CSCF of the IMS 44) forwards the SIP REGISTER message 62 to the

AS_IDP (see message 66) .

In response to the message 66, the AS_IDP 54 confirms the SIP REGISTER message (message 68 sent from the AS_IDP 54 to the IMS 44) .

Next, the AS_IDP 54 sends a SIP REFER message to the user device 2 via the IMS 44 (message 70 from the AS_IDP 54 to the IMS 44 and message 72 from the IMS to the user device 2) .

The SIP REFER messages 70 and 72 contain an HTTP URL pointing to the identity provider 46.

The URL included in the messages 70 and 72 also contains a nonce (a random number used only once ) (such as

123456789abcdef0123456789abcdef0) , which uniquely identifies the session and hence also the user. This nonce is generated by the AS_IDP 54 and is associated with the user' s identity (IMPU) for the time of the IMS session. The AS_IDP 54 maintains the mapping between the IMPU(s) and the nonce and this mapping is used later in the algorithm 60 to identify the user, as described further below.

The user device 2 then confirms receipt of the REFER message 72 by sending an "Accepted" message to the AS_IDP via the IMS 44 (message 74 sent from the user device 2 to the IMS 44 and message 76 sent from the IMS 44 to the AS_IDP 54) .

As an effect of the received SIP REFER message 72, the SIP client 16 in the user device 2 triggers the HTTP client 18 in the user device 2 and passes an HTTP URL of the IDP 46 to the HTTP client. The HTTP client 18 in the user device then issues an HTTP request to the received URL i.e. to the identity provider 46 (message 78) .

On receipt of the message 78, the identity provider 46 extracts the nonce from the URL and passes it to the AS_IDP 54 (message 80) .

The AS_IDP 54 looks up the user's identity (IMPU) based on the nonce and returns it to the identity provider in message 82. Note that multiple identifiers may returned here, as the user may have registered more than one IMPU with the IMS 44.

The identity provider 46 responds to the HTTP request

(received in step 78) in a message 84. As part of the response 84, the identity provider 46 sets a cookie in the HTTP client on the user device 2 (using the Set-Cookie header) . This cookie will identify the HTTP client i.e. the browser for the identity provider 46 in later requests.

Thus, the message sequence 60 includes the following

features:

• A special application server (the AS_IDP 54) is connected to the IMS (e.g. the AS_IDP may be provided as part of the IMS 44) . The users' initial filter criteria (iFC) are configured so that the AS_IDP 54 is notified whenever the user registers at the IMS.

• The AS_IDP 54 makes the SIP client 16 of the user device 2 launch the HTTP client (browser) 18 and point it to the identity provider 46, by passing an HTTP URL to it.

• The HTTP URL contains a nonce that uniquely identifies the user .

• The identity provider 46 contacts the AS_IDP 54 to

determine who the user is (based on the nonce) .

• The identity provider 46 sets a cookie in the HTTP client.

With this, the identity provider has effectively

established an authentication session with the client. As described above, the message sequence 60 enables the identity provider to establish an authentication session with the user device 2 based on the IMS authentication process. Figure 5 is a flow chart of an algorithm, indicated generally by the reference numeral 90, showing how the HTTP client of the user device 2 can access the service provider 48.

The algorithm 90 starts at step 92, where the user device 2 points the browser (the HTTP client 18) to a URL of the service provider (SP) 48. This is achieved using an HTTP GET request.

In response to the HTTP GET request, the service provider 48 authenticates the user by means of a standard single sign-on protocol (e.g. OpenID, SAML/Liberty, Windows CardSpace) at step 94 of the algorithm 90. This procedure involves

cooperation with the identity provider 46 (the identity provider is responsible for carrying out the actual

authentication) by means of HTTP redirect via the browser in the user device 2. As the identity provider has already "marked" the browser with a cookie (see message 84 described above) , the identity provider does not have to carry out any authentication procedures; it receives the cookie in the HTTP request as part of the redirect, and so it treats the user as authenticated .

Assuming that the single sign-on procedure of step 94

succeeds, the service provider provides the content requested (step 96 of the algorithm 90) .

An advantage of the first example is that the order of events is quite natural. Once a user registers with the IMS 44, the identity provider 46 is immediately notified about this fact. This not only makes subsequent HTTP sessions relatively seamless (with no further authentication needing to take place), but it may also enable further useful features; e.g. the identity provider may be queried by service providers about the user's availability, by what SIP URIs the user could be reached, or whether a user with a given SIP URI is available at the moment.

In some forms of the invention the AS_IDP 54 and the identity provider 46 are co-located, but this is not essential to all forms of the invention.

Second Example The second example may be implemented using the system 40 described above with reference to Figure 3. In the second example, the information shared between the SIP and HTTP "legs" is a cookie by which either the IMS 44 or the identity provider 46 "marks" the user's device.

Figure 6 is a flow chart of an algorithm, indicated generally by the reference numeral 100, in accordance with the second example . Assume that the P-CSCF and the identity provider 46 are in the same domain, namely .csp.com. Then the steps of the algorithm 100 are as follows. The algorithm 100 starts at step 102, where a SIP registration procedure occurs. This SIP registration is well known and typically involves a message (similar to the message 62 referred to above) being sent from the user device 2 to the IMS 44.

Next, at step 104, the P-CSCF returns the 200 OK response to the SIP client 16 as part of the normal SIP registration process. However, in step 104, the response also contains a cookie (in a Set-Cookie header) ; this cookie is made valid for the domain .csp.com. The cookie may contain the user's registered identifiers (IMPUs); alternatively, the cookie may contain a nonce. Then when (at step 106) the HTTP client 18 later issues an HTTP request to the identity provider 46, the HTTP client also sends the cookie to the identity provider.

Finally, at step 108, the identity provider 46 extracts the cookie from the HTTP request, passes the cookie to the *-CSCF and retrieves the IMPUs corresponding to the cookie.

In an alternative form of the second example, the identity provider 46 may, at step 108, extract the nonce from the cookie, and then contact the SIP domain for looking up the registered IMPUs associated with the nonce (cf. steps 80 and 82 in the description of first example above) .

The second example can also be used for HTTP-to-SIP cross- authentication: the cookie is set by the identity provider 46 and is read by one of the *-CSCF 50 elements. For example, the HTTP client 18 may first connect to the identity provider 46. The identity provider authenticates the user (by a means outside the scope of this invention) and then "marks" the user's device with an HTTP cookie (Set-Cookie header in the HTTP response) . Later on, when the SIP client 16 carries out the registration procedure with the IMS 44, the

authentication of the user takes place in a different way than usually in IMS; the SIP client sends the cookie (Cookie header in the SIP message) to the *-CSCF 50, the *-CSCF passes the cookie to the identity provider and retrieves the user's identity (e.g. their IMPI) corresponding to the cookie.

Third Example

Figure 7 is a block diagram of a system, indicated generally by the reference numeral 110, in accordance with the third example. The system 110 has many similarities with the system 1.

In the third example, the shared information is a SIP and HTTP proxy 118 commonly used by the SIP and HTTP clients (to be more precise, the information extracted by the shared local proxy) . In use, the proxy intercepts the SIP and HTTP traffic, and is able to extract and insert cookies, as described further below.

The system 110 comprises a user device 112 (similar to the user device 2), an IP multimedia subsystem (IMS) 114 (similar to the IMS 4) and an identity provider 132 (similar to the identity provider 22) . The user device 112 comprises a processor 122, a memory 124, a session initiation protocol (SIP) client 126 and a hypertext transfer protocol (HTTP) client 128 that are similar to the corresponding elements of the user device 2. The user device 112 also includes a proxy 118 that is in two-way communication with both the SIP client 126 and the HTTP client 128.

The user device 112 uses the SIP client 126 to communicate with the IMS 114, wherein the IMS 114 uses SIP to

authenticate the user device 112 and wherein communications between the SIP client 126 and the IMS are sent via the proxy 118. Similarly, the user device 112 uses the HTTP client 128 to communicate with identity provider 132. The HTTP client 128 communicates with the identity provider 132 via the proxy 118. The identity provider 132 is used to authenticate the user device 112.

Thus, the SIP client 126 and the HTTP client/browser 128 are configured to use the shared local proxy 118. During SIP registration, the shared local proxy 118 extracts some information from the SIP traffic. This information uniquely identifies the SIP authentication session. A cookie as proposed in the second example described above may be such information. Another alternative is to extract the nonce field of the Authorization header contained by the SIP

REGISTER message; the number of options is unlimited.

Then when the HTTP client 128 issues an HTTP request to the identity provider 132 later on (cf . step 78 in the

description of the first example) , the shared local proxy 118 injects the said extracted information into the HTTP request; e.g.: it inserts it as a cookie.

The identity provider 132 communicates with the SIP "domain" for associating the received SIP-related information with the user's registered IMPU(s).

The third example can also be used for HTTP-to-SIP cross- authentication. First the HTTP client 128 is authenticated by the identity provider 132, during which process the shared local proxy 118 extracts some information from the HTTP traffic. This information uniquely identifies the HTTP authentication session. A cookie as proposed in the second example may be such information; the number of options is again unlimited. Later on, when the SIP client 126 registers with the IMS 114, the shared local proxy 118 injects the said extracted information into the SIP request; e.g.: it inserts it as a cookie. Fourth Example

The fourth example may be implemented using the system 1 described above with reference to Figure 1. In the fourth example, the shared information is a Globally Routable User Agent URI (GRUU) . A GRUU is a standard mechanism in SIP for obtaining a unique (and "callable") identifier for the device .

Figure 8 is a flow chart of an algorithm, indicated generally by the reference numeral 140, showing an exemplary use of the fourth example implementation of the invention. The algorithm 140 starts at step 142, where the SIP client 16 obtains the GRUU (e.g.: sip : asd887f9dfkk76690@example . com; gr) in a known manner.

Next, at step 144, the SIP client 16 passes the GRUU to the HTTP client 18 (e.g. as described in steps 70 and 72 of the first example) .

The HTTP client 18 then sends the GRUU to the identity provider 46 (step 146) and the identity provider checks with the IMS who the owner of the GRUU is (corresponding to steps 80 and 82 of the first example) .

Fifth Example Figure 9 is a block diagram of a system, indicated generally by the reference numeral 150, in accordance with the fifth example. The system 150 has many similarities with the system 1 and 110. In the fifth example, the shared information is a

certificate, as described further below. The system 150 comprises a user device 152 (similar to the user devices 2 and 112 described above) , an IP multimedia subsystem (IMS) 154 (similar to the IMS 4 and 114) and an identity provider 156 (similar to the identity providers 22 and 132) . The user device 152 comprises a processor 158, a memory 160, a session initiation protocol (SIP) client 162 and a hypertext transfer protocol (HTTP) client 164 that are similar to the corresponding elements of the user devices 2 and 112. The user device 152 also includes a certificate store 166 that is in two-way communication with both the SIP client 162 and the HTTP client 164.

The user device 152 uses the SIP client 162 to communicate with the IMS 154, wherein the IMS 154 uses SIP to

authenticate the user device 152. Similarly, the user device 152 uses the HTTP client 164 to communicate with identity provider 156. The identity provider 156 is used to

authenticate the user device 152. The SIP client 162 and the HTTP client 164 are also both in two-way communication with the certificate store 166.

SIP CERT (Certificate Management Service for The Session Initiation Protocol) , which is currently work in progress at Internet Engineering Task Force (IETF), can be used for deriving a temporary certificate. This can be used as follows :

1. The SIP client 162 derives a temporary certificate (for example using the SIP CERT method) .

2. The SIP client 162 shares the certificate with the HTTP client 164, e.g. by inserting the temporary certificate into the certificate store 166.

3. When the HTTP client 164 issues an HTTP request to the

identity provider later on (cf . step 78 in the description of the first example) , it uses the temporary certificate as a client certificate in the transport layer security (TLS) connection. 4. Either the client certificate directly contains the user's registered IMPU(s), or the certificate contains a unique identifier which the identity provider passes to the SIP "domain" for looking up the registered IMPU(s) .

The fifth example can be used for HTTP-to-SIP cross- authentication in a straightforward way. First the HTTP client authenticates to the identity provider over TLS by means of a client certificate. It shares this client

certificate with the SIP client (for example, by storing it in the certificate store 166) . Then the SIP client

authenticates to the SIP proxy (P-CSCF) over TLS by means of the same client certificate. Then the SIP proxy contacts the identity provider and queries the user' s identity based on the client certificate they used.

Sixth Example

In the sixth example, the shared information is some

cryptographic keys.

Figure 10 is a flow chart of an algorithm, indicated

generally by the reference numeral 170, in accordance with the sixth example. The algorithm 170 may be implemented using the system 1 described above.

The algorithm 170 starts at step 172, where a SIP

registration procedure occurs. SIP registration typically (it is compulsory at least in the IMS) involves the creation of a security association between the user device and the P- CSCF.

Thus, as part of the SIP registration step 172, the SIP client 16 and the SIP proxy agree on some cryptographic keys for securing the communication channel. In IMS, these keys are called IPSec SAs (security associations) , referring to the IPSec method by which the communication channel is secured. Another possibility is to consider the TLS session key as the characteristic SA between the SIP client and proxy .

Such cryptographic keys are unguessable random numbers, so whoever later on is able to show one of the key values to a service running in the telecommunication operator' s network can be safely assumed to reside in the same UE as the SIP client that registered in step 172. Next, at step 174, the SIP client 16 shares the key material with the HTTP client 18.

At step 176, the HTTP client issues an HTTP request to the identity provider (cf . step 78 in the description of the first example) . The HTTP request includes the key material for the TLS connection (e.g. by means of PSK-TLS) . In this way, the HTTP client presents a convincing secret to the identity provider. Finally, at step 178, the identity provider together with the SIP proxy identify the user device based on the provided security information.

The sixth example can be used for HTTP-to-SIP cross- authentication in the following way. First the HTTP client authenticates to the identity provider over TLS (not

necessarily by means of a client certificate; the point is that the communication happens over TLS) . As part of the TLS handshaking procedure, a session key is agreed upon by the client and the server (identity provider) . This session key is shared with the SIP client. Then the SIP client

authenticates to the SIP proxy (P-CSCF) by means of password (digest) authentication, using the shared TLS session key as the password. The SIP proxy, based on the user (SIP) identity claimed by the SIP client, retrieves the TLS session key from the identity provider and hence is able to verify the

authentication response provided by the SIP client. Seventh Example

Figure 11 is a flow chart of an algorithm, indicated

generally by the reference numeral 180, in accordance with the seventh example. The algorithm 180 may be implemented using the system 1 described above.

The algorithm 180 starts at step 182, where a transport layer security (TLS) connection is established between the SIP client 16 of the user device 2 and the P-CSCF of the IMS 4.

The SIP client registers to the IMS 4 via the TLS connection. If the registration is unsuccessful, the TLS connection is torn down, otherwise the following steps take place. As described further below, the TLS connection itself is used as the shared information between the HTTP and SIP legs.

Thus, at step 184, the user device 2 registers at a SIP proxy using the TLS connection. When a message is sent by the user device using the TLS connection (e.g. a SIP or an HTTP request arriving from the user device to the core network of a telecommunications operator) , the recipient of the message can be sure that the message has come from the user device that was previously registered with that SIP identity. The algorithm 180 then moves to step 186 where the TLS channel is made available to the HTTP client 18 of the user device 2. This can be done in a number of different ways. For example, the HTTP client/browser 18 may be configured such that it uses a local proxy as HTTP proxy. The local proxy may then use the TLS channel if it receives SIP traffic destined for the P-CSCF or HTTP traffic targeted to the IDM system. In case the HTTP client/browser selects URLs not targeted to the IDM system, the local proxy does not forward the traffic to the P-CSCF (i.e. does not use the TLS

connection) . Alternatively, a simple TLS tunnel can be set up on the user side which originates on a specific source port of the localhost ( sourcePortOfTLS ) and terminates on the server port for TLS tunnels on the P-CSCF. The SIP client registers by sending the SIP messages to

localhost : sourePortOfTLS of the tunnel. If the client's browser is used to contact the IDM system, the URL must be set to e.g.:

http : //localhost : sourcePortOfTLS/easyAccount /index . j sf .

With the TLS channel made available to the HTTP client, the algorithm 180 moves to step 188 where the HTTP client issues an HTTP request to the identity provider (cf . step 78 in the description of the first example) . Importantly, the HTTP request is made using the said TLS channel for the HTTP communication .

Finally, at step 189, the IDP and the SIP proxy of the IMS communicate to determine which SIP identity has been

associated with the particular TLS connection. Once the identity provider knows the user's SIP identifier, the identity provider can map the SIP identifier to another identifier of the same user, this latter identifier being relevant for the actual service that initiated the

authentication at the identity provider.

The P-CSCF should be enhanced to forward HTTP traffic

received on the TLS server port (and inject the user's identity into the HTTP request when the request is targeted to the identity provider) , provided that the user has successfully registered via SIP.

In the event that the TLS channel is made available to the HTTP client by setting up a TLS channel which originates on a specific source port of the localhost and terminates on the server port for TLS tunnels on the P-CSCF (as described above), step 189 of the algorithm 180 may be modified (or effectively eliminated) as follows. The local proxy detects that the P-CSCF sends the 200 OK message upon receiving the REGISTER message; from this, it knows that the user has successfully authenticated to the IMS, and so it extracts the IMPU(s) from the REGISTER message and offers it to the IDP right in step 188 (no need for further cooperation between the IMS and the IDP) . For this to be secure, the identity provider must check the origin of the received HTTP messages and accept the received IMPU(s) only if the HTTP request comes via the P-CSCF.

The seventh example can be used for HTTP-to-SIP cross- authentication in the following way. Instead of establishing the TLS connection between the SIP client 16 and the P-CSCF, the TLS connection is established between the HTTP client 18 and the identity provider 46. The SIP client and the HTTP client, as well as the P-CSCF and the identity provider, switch roles in the above description. Eighth Example

Figure 12 is a flow chart of an algorithm, indicated

generally by the reference numeral 190, in accordance with the eighth example. In the eighth example, the shared information is the virtual private network (VPN) connection. As is well known in the art, a VPN connection makes use of an insecure Internet for creating a secure communication channel between two nodes. The algorithm 190 may be implemented using the system 1 described above.

The algorithm 190 starts at step 192, where a VPN connection is generated between the user device (where both the SIP client 16 and HTTP client 18 reside) and the operator's domain (where the identity provider as well as the SIP

"domain" resides) .

Then when the HTTP client issues an HTTP request (step 194) to the identity provider later on (cf . step 78 in the

description of the first example above) , the request will go though the VPN connection. The identity provider and the SIP "domain" communicate for associating the VPN connection and the user' s registered IMPU (s) (step 196) . The (VPN) IP address of the user device 2 is already

something that is shared between the SIP client and the HTTP client, when they both communicate with the core network (SIP proxy and identity provider, respectively) through the VPN connection .

The VPN-assigned IP address of the user equipment can be trusted; i.e. whatever IP packets come with that source address, it can be safely assumed to come from the same user equipment. This is already enough for associating the SIP registration with the authentications session at the identity provider .

The eighth example can be used for HTTP-to-SIP cross- authentication in the following way. The VPN connection is built as a side-effect of authenticating the user to the identity provider over HTTP (variation of step 192 above) . Then when the SIP client registers to the SIP proxy (P-CSCF) later on, the communication takes place though the VPN connection (variation of step 194 above) . The SIP "domain" and the identity provider communicate for associating the VPN connection and the user's SIP identity that is being

authenticated (in case of IMS registration, this identity is the IMPI; variation of step 196 above) . As all the solutions rely on either the SIP or the HTTP "leg" transmitting some secret and unguessable piece of information that was originally received by the user' s device on the other one of the SIP and the HTTP "leg", both "legs" must use secure communication channels. This is inherent in some of the variants (examples 5 to 8 above) , but must explicitly be ensured in other ones (examples 1 to 4 above) . The shared information may reside on the application level (examples 1 to 4 above) as well as on the connection level (examples 5 to 8 above) . At least some embodiments of the invention are not limited to HTTP sessions initiated by an IMS application service (i.e. the invention applies to any HTTP session initiated by the user after registering to the IMS) . Furthermore, the solutions are not limited to service

provides that are prepared to the solution (i.e. the solution is completely transparent for the service providers) .

The embodiments of the invention described above are

illustrative rather than restrictive. It will be apparent to those skilled in the art that the above devices and methods may incorporate a number of modifications without departing from the general scope of the invention. It is intended to include all such modifications within the scope of the invention insofar as they fall within the scope of the appended claims.

Claims

CLAIMS :

1. A method comprising:

using a session initiation protocol client of a user device to authenticate the user device at an internet

protocol multimedia subsystem;

obtaining identification information from the internet protocol multimedia subsystem at the session initiation protocol client;

sharing the identification information with a hypertext transfer protocol client of the user device; and

using the hypertext transfer protocol client to

communicate with an identity provider, wherein the identity provider is provided with the said identification information and wherein the identity provider uses the identification information to determine the identity of the user device on the basis of the authentication of the user device at the internet protocol multimedia subsystem.

2. A method as claimed in claim 1, wherein sharing the identification information with the hypertext transfer protocol client of the user device comprises sending the said identification information to the hypertext transfer protocol client of the user device.

3. A method as claimed in claim 1 or claim 2, wherein sharing the identification information with the hypertext transfer protocol client of the user device comprises storing the information in a data store to which the hypertext transfer protocol client of the user device has access.

4. A method as claimed in any preceding claim, wherein the identification information is a hypertext transfer protocol uniform resource locator containing a nonce.

5. A method as claimed in claim 4, wherein the hypertext transfer protocol uniform resource locator is sent from the internet protocol multimedia subsystem to the session

initiation protocol client of the user device.

6. A method as claimed in claim 4 or claim 5, wherein the hypertext transfer protocol client is launched in response to receiving said hypertext transfer protocol uniform resource locator.

7. A method as claimed in any one of claims 4 to 6, wherein said hypertext transfer protocol uniform resource locator points the hypertext transfer protocol client to the said identity provider.

8. A method as claimed in any one preceding claim, wherein the identification information comprises a globally routable user agent uniform resource indicator.

9. A method as claimed in claim 8, wherein the globally routable user agent uniform resource indicator is obtained from the internet protocol multimedia subsystem by the session initiation protocol client of the user device and subsequently sent from the session initiation protocol client of the user device to the hypertext transfer protocol client of the user device.

10. A method comprising:

using a hypertext transfer protocol client of a user device to authenticate the user device at an identity

provider ;

obtaining identification information from the identity provider at the hypertext transfer protocol client;

sharing the identification information with a session initiation protocol client of the user device; and

using the session initiation protocol client to

11. A method as claimed in claim 10, wherein sharing the identification information with the session initiation protocol client of the user device comprises sending the said identification information to the session initiation protocol client of the user device.

12. A method as claimed in any preceding claim, wherein the identification information comprises a nonce.

13. A method as claimed in any preceding claim, wherein the identification information comprises a cookie.

14. A method as claimed in any preceding claim, wherein the identification information is stored at a proxy, wherein the session initiation protocol client communicates with the internet protocol multimedia subsystem via the proxy and the hypertext transfer protocol client communicates with the identity provider via the proxy.

15. A method as claimed in any preceding claim, wherein the identification information comprises a certificate.

16. A method as claimed in any preceding claim, wherein the identification information comprises a cryptographic key.

17. A user device comprising a session initiation protocol client and a hypertext transfer protocol client, wherein: the session initiation protocol client is configured to authenticate the user device at an internet protocol

multimedia subsystem, obtain identification information from the internet protocol multimedia subsystem and to share the identification information with the hypertext transfer protocol client of the user device; and

the hypertext transfer protocol client is configured to communicate with an identity provider, wherein the identity provider is provided with the said identification information and wherein the identity provider uses the identification information to determine the identity of the user device on the basis of the authentication of the user device at the internet protocol multimedia subsystem.

18. A user device comprising a session initiation protocol client and a hypertext transfer protocol client, wherein

the hypertext transfer protocol client is configured to authenticate the user device at an identity provider, obtain identification information from the identity provider and share the identification information with the session

initiation protocol client of the user device; and

the session initiation protocol client is configured to communicate with an internet protocol multimedia subsystem, wherein the internet protocol multimedia subsystem is provided with the said identification information and wherein the internet protocol multimedia subsystem uses the

19. A computer program product comprising:

means for using a session initiation protocol client of a user device to authenticate the user device at an internet protocol multimedia subsystem;

means for obtaining identification information from the internet protocol multimedia subsystem at the session

initiation protocol client;

means for sharing the identification information with a hypertext transfer protocol client of the user device; and means for using the hypertext transfer protocol client to communicate with an identity provider, wherein the

identity provider is provided with the said identification information and wherein the identity provider uses the identification information to determine the identity of the user device on the basis of the authentication of the user device at the internet protocol multimedia subsystem.

20. A computer program product comprising:

means for using a hypertext transfer protocol client of a user device to authenticate the user device at an identity provider ;

means for obtaining identification information from the identity provider at the hypertext transfer protocol client; means for sharing the identification information with a session initiation protocol client of the user device; and means for using the session initiation protocol client to communicate with an internet protocol multimedia

subsystem, wherein the internet protocol multimedia subsystem is provided with the said identification information and wherein the internet protocol multimedia subsystem uses the identification information to determine the identity of the user device on the basis of the authentication of the user device at the identity provider.