WO2012028168A1

WO2012028168A1 - Identity gateway

Info

Publication number: WO2012028168A1
Application number: PCT/EP2010/062602
Authority: WO
Inventors: Gerald Meyer; Robert Seidl; Markus Bauer-Hermann
Original assignee: Nokia Siemens Networks Oy
Priority date: 2010-08-30
Filing date: 2010-08-30
Publication date: 2012-03-08

Abstract

A gateway is described for controlling communications between a user device (operating as a thin client), an identity management system (IDM), a terminal server and a service provider. The user device uses the gateway to login at a terminal server, during which process the identity of the user device is established by the IDM based on user device credentials (such as SIM data). The terminal server later uses the gateway to access an application and provides identification information provided by the IDM.

Description

Title Identity Gateway

This application is in the field of identity management and service access control. Figure 1 is a block diagram of a system, indicated generally by the reference numeral 1, for providing a user with access to one or more service providers. The system 1 comprises a user device 2, a service provider 4 and an identity

management system (IDM) 6. The user device 2, which may, for example, be a mobile communication device or a laptop, is in two-way communication with both the service provider 4 and the IDM 6.

The service provider 4 includes a secure application that the user of the user device 2 wants to access. The service provider 4 requires user credentials for the user before access to the application will be granted to the user. As is well known in the art, the IDM 6 can be used to provide such user credentials.

By way of example, Figure 2 shows a message sequence, indicated generally by the reference numeral 10,

demonstrating a known algorithm for providing user

credentials to the service provider 4.

The message sequence 10 starts with the user device 2 sending a request 12 to the service provider 4 for access to the desired application. The request may, for example, be in the form of a hypertext transfer protocol (HTTP) request. In response to the request 12, the service provider 4 seeks user credentials from the user device 2. In the exemplary message sequence 10, the application 4 seeks user credentials by sending a Security Access Markup Language (SAML) request 14 to the user device 2. SAML is an XML

(extensible Markup Language) standard for exchanging

authentication and authorization data between security domains. For example, SAML is used for exchanging assertion data between an identity provider (a producer of assertions) and a service provider (a consumer of assertions) . SAML is a specification defined by the OASIS (Organization for the Advancement of Structured Information standards) .

In accordance with the SAML protocol, the SAML request issued by the service provider 4 is redirected from the user device 2 to the IDM 6 (see the SAML request 16) . Many mechanisms for identifying the appropriate identity management system are known in the art and are not discussed here.

Assuming that the user of the user device 2 is known to the IDM 6, the IDM responds to the SAML request 16 by formulating a SAML response (including the requested user credentials) and sending the SAML response 18 to the user device 2. The SAML response is redirected to the service provider 4 (see the SAML response 20), as is well known in the art. At this stage, the service provider 4 has the user

credentials requested in the original SAML request 14 and can therefore send an HTTP response 22 to the user 2 in response to the original HTTP request 12. The user device 2 can now access the requested application at the service provider 4.

In order for the algorithm 10 to work, the user of the user device 2 must be known to the IDM 6 and must be recognised by the IDM. An identity management system, such as the IDM 6, is able to identify a user in many different ways, such as using a username/password pair. One mechanism that is well suited for use with mobile communication devices is the use of a token based system, such as the use of a SIM card or a certificate stored at the user device 2. Such token based systems are not, of course, restricted to use with mobile communications devices. For example, certificates can be readily stored within the memory of a laptop or some other device .

Token-based systems are generally popular since they provide a high level of security coupled with a high level of

convenience for the end user. Figure 3 is a block diagram of a system, indicated generally by the reference numeral 30 for providing a user with access to one or more service providers (two in the exemplary system 30) . The system 30 comprises a user device 32, a server 34, a first service provider 36 and a second service provider 38.

In the system 30, the user device 32 is a thin client. A thin client is a device that relies on another device (the server 34 in the case of the user device 32) for at least some computation functionality. Typically, a thin client provides a graphical user interface for a user, with most or all of the remaining functionality being implemented by a server (such as the server 34) . In a corporate environment, for example, a number of users may be connected to a central server, with the central server containing an operating system and a variety of software programs for use by the end users. This arrangement can reduce cost (since thin clients are typically cheap) . Moreover, this arrangement can vastly simplify the updating and control of software, since the bulk of the software is located at a common server. The use of thin clients can also have security benefits.

Mobile communication devices are increasingly able to access sophisticated functionality by acting as a thin client. In the system 30, the user device 32 uses the server 34 to access the service providers 36 and 38. The user device 32 provides a visual display to a user of the user device. The user device 32 typically provides a graphical user interface to enable the user to interact with applications provided by the service providers 36 and 38. The user device 32 may be a mobile communications device. The use of token-based systems to enable an IDM to provide credentials for a user to a service provider has many

advantages, including a high level of security and a high level of convenience for the end user. But since the token is first used for the authentication of a device on a network layer, it is only suited for authentication on an application layer if the application will be accessed from the same device. If the end user is using a thin client (such as the user device 32) to access applications via a terminal server (such as the server 34), then the applications are no longer directly accessed from the user device and so cannot take advantage of tokens (such as SIM card data) stored on the device for identification purposes in the manner described above with reference to Figures 1 and 2. The present invention seeks to address at least some of the problems discussed above.

The present invention provides a method comprising: receiving (for example at a gateway) a first access request (such as an HTTP request) for access to an application (or a service provider providing an application) , wherein the request is received from a terminal server acting on behalf of a user device (the user device might typically be a thin client) ; sending (e.g. from the gateway) a second access request to the application (or to a service provider providing said application); receiving (e.g. at the gateway) an

authentication request (such as a SAML request) from the application (or from the service provider providing said application) ; obtaining or generating an authentication response (such as a SAML response) , including the step of providing identification information for the user device; and sending the authentication response to said application (e.g. to a service provider providing said application) . The present invention also provides an apparatus (such as a gateway) comprising: a first input configured to receive a first service access request (such as an HTTP request) for access to an application, wherein the request is received from a terminal server acting on behalf of a user device (the user device may be a thin client) ; a first output configured to send a second service access request to the application (or to a service provider providing said application) ; a second input configured to receive an authentication request (such as a SAML request) from the application (or from the service provider providing said application) ; a processor configured to obtain or generate an authentication response (such as a SAML response) , including the step of providing identification information for the user device; and a second output configured to send the authentication response to said application (e.g. to a service provider providing said application) . The said processor may be configured to obtain the authentication response from an identity management system. One or more of the inputs may be provided by a common input of the apparatus. Similarly, one or more of the outputs may be provided by a common output of the apparatus. Moreover, a single input/output pin of an apparatus may be used to implement one or more of the inputs and one or more of the outputs of the apparatus. The same principles apply to any other inputs of the apparatus of the invention

described below.

As described below, one or more of the features of the present invention may be implemented using one or more processors. Where multiple processors are described or claimed herein, one or more of said processors may be

implemented by a single processor. By way of example, a first and a second processor may be implemented by a first processor apparatus and a third processor may be implemented by a second processor apparatus. b

The invention may include providing an authentication

response to the service provider, wherein the authentication response is based on identity information regarding the user device, rather than the terminal server.

The first and second service access requests may be identical (such that the gateway simply forwards the original request onto the service provider) . The step of obtaining or generating the authentication response may comprise obtaining the authentication response from an identity management system. Furthermore, the

identification information for the user device is provided to the identity management system.

The step of obtaining or generating the authentication response may comprises generating the authentication response using credentials regarding the user device known to a gateway module.

In many forms of the invention, the first access request for access to an application includes an identifier of the terminal server. The invention may further comprise

replacing the identifier of the terminal server with the identification information for the user device.

The authentication request may include identification

information relating to the terminal server and the method may further comprise replacing said identification

information relating to the terminal server with

identification information relating to said user device.

In some forms of the invention, the said first access request received from said terminal server identifies the terminal server using predefined credentials (e.g. using a tunnel generated between the terminal server and the gateway of the present invention) . The invention may further comprise: receiving (e.g. at a gateway) a login request from the user device seeking to login to the terminal server, wherein the login request identifies the user device using a network layer identifier (such as an IP address) ; using the network layer identifier to obtain a root identity for the user device from an

identity management system; and using the root identity to log the user into the terminal server. This login process typically occurs prior to the user device using the terminal server to access the said application.

The identity management system may use the network layer identifier to obtain a security token (or some other token- based credential) for the user device and may use the

security token to determine the root identity of the user device .

The security token (or token-based credential) may, for example, be SIM card data or a user certificate as stored at the user device. Advantages of token-based credentials include a high degree of security combined with a high level of convenience of the end user.

The security token (or token-based credential information) may be obtained from a network layer authentication module.

The invention may further comprise setting up tunnel

credentials between the terminal server and a gateway, wherein the tunnel credentials are used by the gateway, on receipt of a request from the terminal server, to determine the user device on that is making use of the terminal server to send the said request.

The said login request may include an account name for the terminal server.

The present invention also provides a computer program comprising: code (or some other means) for receiving (e.g. at a gateway) a first access request (such as an HTTP request) for access to an application (or a service provider providing an application) , wherein the request is received from a terminal server acting on behalf of a user device (wherein the user device is a thin client) ; code (or some other means) for sending a second access request to the application (or to a service provider providing said application) ; code (or some other means) for receiving an authentication request (such as a SAML request) from the application (or from the service provider providing said application) ; code (or some other means) for obtaining or generating an authentication response (such as a SAML response) , including the step of providing identification information for the user device; and code (or some other means) for sending the authentication response to said application (e.g. to a service provider providing said application) . 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 method comprising: receiving (e.g. at a gateway) a login request from a user device seeking to login to a terminal server, wherein the login request identifies the user device using a network layer identifier (such as an IP address) ; using the network layer identity to obtain a root identity for the user device from an identity management system; using the root identity to log the user into the terminal server; and setting up tunnel credentials between the terminal server and a gateway, wherein the tunnel credentials are used by the gateway, on receipt of a request from the terminal server, to determine the user device on that is making use of the terminal server to send the said request. The present invention yet further provides an apparatus (e.g. a gateway) comprising: a first interface with a user device, wherein the first interface receives a login request from a user device seeking to login to a terminal server, wherein the login request identifies the user device using a network layer identifier (such as an IP address) ; a second interface with an identity management system, wherein the second interface is used to obtain a root identity for the user device from the identity management system; a third interface with the terminal server, wherein the third interface is used to log the user device into the terminal server using the root identity of the user device obtained from the identity management system; and means for setting up a tunnel between the terminal server and the gateway. The said interfaces may be implemented using one or more inputs and/or one or more outputs and/or one or more input/outputs .

The identity management system may use the network layer identifier to obtain a security token (or token-based

credential) for the user device and uses the security token to determine the root identity of the user device.

The security token (or token-based credential) may, for example, be SIM card data or a user certificate as stored at the user device. Advantages of token-based credentials include a high degree of security combined with a high level of convenience of the end user. The security token (or token-based credential information) may be obtained from a network layer authentication module.

The login request may include an account name for the

terminal server.

The identity management system may be configured to use the network layer identifier to obtain a token-based credential for the user device and to use the token-based credential to determine the root identity of the user device.

The apparatus may further comprise the said identity

management system. The present invention yet further provides a computer program comprising: code (or some other means) for receiving (e.g. at a gateway) a login request from a user device seeking to login to a terminal server, wherein the login request

identifies the user device using a network layer identifier (such as an IP address) ; code (or some other means) for using the network layer identity to obtain a root identity for the user device from an identity management system; code (or some other means) for using the root identity to log the user into the terminal server; and code (or some other means) for setting up tunnel credentials between the terminal server and a gateway, wherein the tunnel credentials are used by the gateway, on receipt of a request from the terminal server, to determine the user device on that is making use of the terminal server to send the said request. 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. Exemplary embodiments of the invention are described below, by way of example only, with reference to the following numbered schematic drawings.

Figure 1 is a block diagram of a known system for providing a user with access to a service provider;

Figure 2 is a message sequence demonstrating an

exemplary use of the system of Figure 1;

Figure 3 is a block diagram of a known system for providing a user with access to one or more service

providers;

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

Figure 5 is a message sequence in accordance with an aspect of the present invention;

Figure 6 is a message sequence in accordance with an aspect of the present invention; and

Figure 7 is a message sequence in accordance with an aspect of the present invention. Figure 4 is a block diagram of a system, indicated generally by the reference numeral 40, in accordance with an aspect of the present invention.

The system 40 comprises a user device 42, a network layer authentication module 44, a gateway 46, an identity

management system (IDM) 48, a first server 50, a first service provider 54 and a second service provider 56. The user device 42 is in two-way communications with the network layer authentication module 44 and the gateway 46. The network layer authentication module 44 is also in two-way communications with the gateway 46 and the IDM 48. The gateway 46 is also in two-way communications with the IDM 48, the first server 50, and the first and second service

providers 54 and 56.

The gateway 46, IDM 48, first server 50, and the first and second service providers 54 and 56 are located within a network 58 that is typically referred to as a "cloud". The cloud may include other elements, such as one or more

additional servers (similar to the first server 50), one or more additional service providers (similar to the services providers 54 and 56) and many other elements.

Cloud computing is a paradigm that moves resources, services and applications into a so-called cloud, enabling users to access and utilise the resources, services and applications within the cloud. The cloud typically delivers resources, services and applications over the Internet (or some other network) which are sold/used on demand, thereby providing substantial flexibility. In the telecommunications industry, for example, services and applications are increasingly being implemented in the "cloud" instead of (or at least in

addition to) the traditional telecommunications domain.

The user device 42 is operating as a thin client and may, for example, be a mobile communications device. Thin clients, such as the user device 42, are particularly well suited to exploit the advantages of cloud computing services.

As described in detail below, the gateway 46 establishes a logical assignment between the token-based identity of the user device, an associated "terminal server" identity, and a root identity as known to the Identity Management (IDM) system 48. Thus, as shown in the system 40, the gateway 46 has connections not only to the user device 42 and to the server 50 (which, as discussed below, acts as a terminal server) but also to the IDM system 48.

The network 58 may be any network, e.g. an enterprise network with workstations acting as thin clients, or a Communication Service Provider' s (CSP) mobile network with smartphones or other mobile communication devices acting as thin clients.

Figure 5 shows a message sequence, indicated generally by the reference numeral 60, in accordance with an aspect of the present invention. The message sequence 60 shows the

transfer of messages between the user device 42, the network layer authentication module 44, the gateway 46, the IDM 48 and the first server 50. As explained in detail below, the message sequence 60 provides a method for associating the various identities of the user device 42. Once the

identities are associated, the first server 50 can be used to access one or more service providers for the user, as

described below with reference to Figure 7. Thus, the first server 50 can be used as a terminal server.

The message sequence 60 starts at step 62, where the user device 42 contacts the network layer authentication module 44 to establish a network connection. Step 62 involves the network layer authentication module 44 obtaining a network layer identity for the user device (such as an Internet

Protocol (IP) address of the user device) . As part of the authentication process, the module 44 obtains a security token of the user device (such as SIM card data or a user certificate) . At this stage, the user device 42 can connect to elements of the network 58, such as the gateway 46. The user device 42 is not, yet, able to access either of the service providers 54 and 56.

Next, the user device 42 seeks to log-in to a terminal server in the network 58. In the present example, the user device 42 connects to the first server 50. This server might be one terminal server out of a set of many; the detailed process of assigning a specific terminal server to this client is of no relevance here, but it could, for example, be done by

managing a list of free terminal servers and choosing an arbitrary entry from this list. Cases where roaming is involved may require a discovery processes for the suitable gateway and terminal server. As described in detail below, the user device 42 communicates with the server 50 via the gateway 46.

As shown in the message sequence 60, the user device 42 sends a login request 64 to the gateway 46, so that the gateway can forward that request to the server 50. The login request 64 includes a network layer identifier for the user device 42 (typically the IP address of the user device) and also includes an account name for the user at the server 50.

The gateway 46 now seeks to authenticate the user device. In order to do so, the gateway 46 sends an authentication request 66 to the IDM 48. The authentication request

includes the IP address of the user device 42.

As described above, the present invention makes use of a token (such as a certificate) to authenticate the user device. Accordingly, the IP address of the user device is not sufficient to enable the IDM 48 to identify and

authenticate the user. The token required by the IDM 48 was provided to the network layer authentication module 44 in the step 62 described above. Thus, the IDM sends an ID request 68 to the network layer authentication module 44 requesting the token data. The request 68 includes the IP address (or other network layer identification) of the user device 42, as provided in the login request 64. In response to the request 68, the network layer

authentication module 44 provides the token to the IDM 48 in an ID response message 70. The IDM 48 uses the token to obtain the root identity of the user device as stored at the IDM 48. This root identity is provided to the gateway 46 in an authentication response message 72. Accordingly, the IDM 48 provides the authentication response 72 in response to the authentication request 66.

At this stage, the gateway 46 has received (from the user device 42) a login request (the request 64) that identifies the server 50 and provides an account name that the user wishes to access. The gateway 46 has also received (from the IDM 48) identification information for the user device (in the authentication response 72) . The gateway uses this information to generate a login request 74 including the account information and the identity information and sends the request 74 to the server 50. The login request 74 is based on the login request 64, but additionally includes the identity data (e.g. a root identity) received from the IDM 48.

In response to the request 74, the server 50 performs the requested login procedure at step 75 (assuming that the login credentials are correct) and responds to the login request by sending a login response message 76 to the gateway 46. The gateway forwards the login response to the user device

(message 78) . The login response 78 is provided as a

response to the original login request message 64. The gateway 46 is provided in the path between the user device (typically a thin client) and the server 50 (typically one of a number of terminal servers) . This gateway is also connected to an Identity Management (IDM) system (e.g. residing in a communication service provider's (CSP's) network) which knows the identifiers of the user device 42 (and typically of many other thin clients) . These identifiers may be e.g. SIM card data, or certificates stored at the user device.

The message sequence 60 demonstrates how the insertion of the gateway 46 between the user device 42 and the server 50 and the interaction of this gateway with an IDM 48 allows the association of the identity of the server 50 (or the

processes running there) with the root ID of the user, as stored at the IDM.

At this stage, the user of the user device 42 has used token- based identification information to login to the server 50. As described below with reference to Figure 7, the user device can access a service provider, such as the service provider 54, using the server 50. A problem is that the server 50 may act on behalf of a number of different user devices 42. Accordingly, the server needs to identify the relevant user device.

Figure 6 is a message sequence, indicated generally by the reference numeral 80, showing an algorithm that enables the server to identify the user device. The message sequence 80 follows the message sequence 60 and starts with the server 50 sending a request 82 for credentials to the gateway 46. In response to the message 82, the gateway generates credentials (step 84) and returns the credentials to the server in a message 86. The credentials, which are now known to both the server 50 and the gateway 46 can, in future, be used to identify the user device that the server is acting on behalf of and can also be used to confirm the identity of the server 50.

The server 50 uses the credentials provided in the message 86 to setup a tunnel between the server 50 and the gateway 46 (step 88) . The tunnel uses the credentials provided in the message 86 to identify the user device 42 that the server 50 is acting on behalf of.

Thus, the tunnel can be used to identify the relevant user device 42. Further, since the tunnel details are known only to the server 50 and the gateway 46, the tunnel can be used to confirm that a communication from the server 50 on behalf of the user device is coming from the genuine server. The tunnel can be implemented in a number of ways. For example, the tunnel may be an IPsec tunnel. Alternatively, the tunnel may be setup using the SOCKS protocol. For HTTP traffic, the tunnel may configure the gateway as a web proxy. The message sequence 80 shows the server 50 asking the gateway 46 to provide credentials and then setting up the tunnel on receipt of the credentials. In an alternative embodiment, the server 50 may setup the tunnel and send the credentials data to the gateway 46 once the tunnel has been setup. Other variants will also be apparent to the skilled person .

As discussed above, the message sequence 60, initialises the system 40 so that the user is able to use the server 50 (in the exemplary message sequence) to access one or more service providers. Figure 7 shows a message sequence, indicated generally by the reference numeral 90, in which the server is used to access the service provider 54. The message sequence 90 starts with the server 50 requesting access to an application at the service provider 54. This access request takes the form of an HTTP request 92. The request 92 is sent from the server 50 to the gateway 46. As part of the message 92, the gateway obtains tunnel

information from the server 50 in order to determine the identity of the user device 42 and to confirm that the server 50 is able to act on behalf of the user device. The gateway 46 simply forwards the request to the service provider 54 as an HTTP request 94. On receipt of the HTTP request 94, the service provider 54 determines that it has not been provided with the required user authentication.

Accordingly, the service provider generates a SAML request 96, requesting user authentication, and sends the SAML request to the gateway 46. The gateway 46 forwards the SAML request 96 to the server 50 as SAML request 98. In accordance with the SAML protocol, the server 50 redirects the SAML request 98 to the relevant IDM (the IDM 48 in this case) . However, as shown in Figure 7, the redirected SAML request is not sent directly to the IDM 48; instead, the server 50 forwards the SAML request to the gateway 46 as SAML request 100.

The SAML request 100 targets the IDM 48 and identifies the originator of the request 92 (i.e. the server 50) . The gateway 46 is used to replace the identification information (of the server 50) included in the request 100 with the root ID of the user (obtained by the gateway in the message 72 discussed above) in a step 102.

The SAML request 100, suitable modified by the gateway 46, is forwarded to the IDM 48 (message 104) . In response to the SAML message 104, the IDM 48 provides a SAML response 106. The IDM uses the root ID provided in the message 104 to extract any further requested attributes for the user device and provides those in the SAML response 106. Such attributes may include data such as the real name or address of the user .

The SAML response 106 is sent to the gateway 46 (in response to the SAML request 104) . The response is forwarded by the gateway 46 to the service provider 54. In accordance with the SAML protocol, the SAML response is sent via the server 50 using redirection. Thus, the SAML response is sent from the gateway 46 to the server 50 as a message 108, redirected to the service provider 54 via the gateway 46 in a first message 110 sent from the server to the gateway and a

subsequent message 112 sent from the gateway to the service provider 54.

The SAML response 112 is received at the service provider as a response to the original SAML request 96. The service provider 54 can now respond to the original HTTP request 94 received from the server 50. Thus, the service provider 54 sends an HTTP response 114 to the gateway 46 and the gateway forwards the response to the server 50 (message 116) . The service provider 54 may, for example, set a cookie at the server 50 in order to mark an ongoing HTTP session with the server 50 as "authenticated". The cookie may be sent from the service provider 54 to the server 50 via the gateway 46.

The steps of the algorithm 90 are similar to the steps of the algorithm 10 described above with reference to Figure 2. The HTTP requests 92 and 94 correspond to the HTTP request 12 of the algorithm 10. Similarly, the SAML requests 96 and 98 correspond to the SAML request 14, the SAML requests 100 and 104 correspond to the SAML request 16, the SAML responses 106 and 108 correspond to the SAML response 18, the SAML

responses 110 and 112 correspond the SAML response 20 and the HTTP responses 114 and 116 correspond to the HTTP response 22.

The message sequence 90 differs from the message sequence 10 in the use of the gateway 46, as described in detail above. The IDM 48, server 50 and the service provider 54 all act in a largely conventional manner in the message sequence 90. It is the gateway 46 and the routing of the messages that is not conventional . The message sequence 90 shows how the server 50 is used to access the service provider 54. Although not shown in Figure 7, the message sequence 90 is typically initiated by the user using the user device 42 and the output provided by the service provider is typically presented to the user using a graphical user interface of the user device 42. However, as is clear from the message sequence 90 shown in Figure 7, the user device does not need to be involved with the access of the service provider. Accordingly, the user device 42 is being used as a thin client, as discussed above, and the first server 50 is acting as a terminal server.

The message sequences of the present invention are described with reference to the SAML protocol. The use of the SAML protocol is not essential to all embodiments of the present invention. Alternative identity federation algorithms may be used, such as the protocols provided by OpenID and WS- Federation. Furthermore, the identity federation protocol landscape is under fast development and may also bring up new protocols, which may be used with the present invention.

The associated IDM system enables thin clients to identify themselves towards third party services e.g. in the public Internet. The benefits resulting from this invention include the use of an IDM system also for thin clients, offering the typical functionality of an IDM which includes but is not limited to:

• single sign-on to third-party web services, including management of different log-in methods and

credentials for those web services;

• storage and exposure management of personal user

attributes (e.g. age verification data);

• value-added services from the IDM operator, e.g.

payment from user accounts to web services;

• using anonymous or pseudonymous identities (e.g. with limited validity time) for certain web services.

In the message sequence 60, the messages 66 to 72 involve the IDM 48. In some forms of the invention, it would not be necessary to associate the user's root ID with the server 50; it would be sufficient to associate the root ID with the network layer identifier which can be obtained from the network layer authentication entity 44. Rejection of an unknown user would then happen in the message sequence 90 at messages 104 and 106, because only then the IDM would be queried for the user's root ID. The proposed solution enables very early rejection of unknown users, thereby reducing load in the network and giving the opportunity to trigger some roaming process.

In the message sequence 60, the gateway 46 obtains, in the message 72, not only information regarding whether or not the user is known, but also the user's root ID (if he is known) .

This simplifies subsequent queries to the IDM as in message

104 of the message sequence 90, because the IDM does not need to query the network layer authentication entity 44 for this information (this would provide the "network layer

identifier" which the IDM then could associate with the user' s root ID) .

It should be noted that in the messages 104 and 106 of the message sequence 90 could be omitted in some embodiments of the invention, since the gateway 46 already knows the user's root ID. The inclusion of these messages, as in the exemplary message sequence 90, enables the gateway to obtain more personal user information from the IDM. This additional information, e.g. full name and address of the user, would be specific for the requesting web service (as specified in the SAML request) , and in particular allows the use of

pseudonymous data for the specific web service. The method is not limited to HTTP traffic, but can be used for any kind of traffic. This allows any application using any protocol to be run on terminal servers without

restrictions . 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 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:

receiving a first access request for access to an application, wherein the request is received from a terminal server acting on behalf of a user device;

sending a second access request to the application;

receiving an authentication request from the

application;

obtaining or generating an authentication response, including the step of providing identification information for the user device; and

sending the authentication response to said application.

2. A method as claimed in claim 1, wherein the step of obtaining or generating the authentication response comprises obtaining the authentication response from an identity management system.

3. A method as claimed in claim 2, wherein the

4. A method as claimed in claim 1, wherein obtaining or generating the authentication response comprises generating the authentication response using credentials regarding the user device known to a gateway module.

5. A method as claimed in any preceding claim, wherein the first access request for access to an application includes an identifier of the terminal server.

6. A method as claimed in claim 5, further comprising replacing the identifier of the terminal server with the identification information for the user device.

7. A method as claimed in any preceding claim, wherein the authentication request includes identification information relating to the terminal server and wherein the method further comprises replacing said identification information relating to the terminal server with identification

information relating to said user device.

8. A method as claimed in any preceding claim, wherein said first access request received from said terminal server identifies the terminal server using predefined credentials.

9. A method as claimed in any preceding claim, further comprising :

receiving a login request from the user device seeking to login to the terminal server, wherein the login request identifies the user device using a network layer identifier; using the network layer identifier to obtain a root identity for the user device from an identity management system; and

using the root identity to log the user into the

terminal server.

10. A method as claimed in claim 9, wherein the identity management system uses the network layer identifier to obtain a security token for the user device and uses the security token to determine the root identity of the user device.

11. A method as claimed in claim 10, wherein the security token is obtained from a network layer authentication module.

12. A method as claimed in any one of claims 9 to 11, further comprising setting up tunnel credentials between the terminal server and a gateway, wherein the tunnel credentials are used by the gateway, on receipt of a request from the terminal server, to determine the user device on that is making use of the terminal server to send the said request.

13. A method as claimed in any one of claims 9 to 12, wherein the login request includes an account name for the terminal server.

14. An apparatus comprising:

a first input configured to received a first service access request for access to an application, wherein the request is received from a terminal server acting on behalf of a user device;

a first output configured to send a second service access request to the application;

a second input configured to receive an authentication request from the application;

a processor configured to obtain or generate an

authentication response, including the step of providing identification information for the user device; and

a second output configured to send the authentication response to said application.

15. An apparatus as claimed in claim 14, wherein the

processor is configured to generate the authentication response using credentials regarding the user device known to a gateway module.

16. An apparatus as claimed in claim 14 or claim 15, wherein the first access request for access to an application

includes an identifier of the terminal server.

17. An apparatus as claimed in claim 16, wherein the

processor is configured to replace the identifier of the terminal server with the identification information for the user device.

18. An apparatus as claimed in any one of claims 14 to 17, further comprising:

a third input configured to receive a login request from the user device seeking to login to the terminal server, wherein the login request identifies the user device using a network layer identifier; a second processor configured to use the network layer identifier to obtain a root identity for the user device from an identity management system;

a third processor configured to use the root identity to log the user into the terminal server.

19. A apparatus as claimed in claim 18, further comprising a fourth processor configured to set up tunnel credentials between the terminal server and a gateway, wherein the tunnel credentials are used by the gateway, on receipt of a request from the terminal server, to determine the user device on that is making use of the terminal server to send the said request .

20. A computer program product comprising:

means for receiving a first access request for access to an application, wherein the request is received from a terminal server acting on behalf of a user device;

means for sending a second access request to the

application

means for receiving an authentication request from the application

means for obtaining or generating an authentication response, including the step of providing identification information for the user device; and

means for sending the authentication response to said application .

21. A method comprising:

receiving a login request from a user device seeking to login to a terminal server, wherein the login request

identifies the user device using a network layer identifier; using the network layer identity to obtain a root identity for the user device from an identity management system;

using the root identity to log the user into the

terminal server; and setting up tunnel credentials between the terminal server and a gateway, wherein the tunnel credentials are used by the gateway, on receipt of a request from the terminal server, to determine the user device on that is making use of the terminal server to send the said request.

22. A method as claimed in claim 21, wherein the identity management system uses the network layer identifier to obtain a security token for the user device and uses the security token to determine the root identity of the user device.

23. An apparatus comprising:

a first interface with a user device, wherein the first interface receives a login request from a user device seeking to login to a terminal server, wherein the login request identifies the user device using a network layer identifier; a second interface with an identity management system, wherein the second interface is used to obtain a root

identity for the user device from the identity management system;

a third interface with the terminal server, wherein the third interface is used to log the user device into the terminal server using the root identity of the user device obtained from the identity management system; and

means for setting up a tunnel between the terminal server and the gateway.