WO2012098265A1

WO2012098265A1 - Method and system for controlling access to networks and/or services

Info

Publication number: WO2012098265A1
Application number: PCT/EP2012/050991
Authority: WO
Inventors: Lionel Wolovitz
Original assignee: Lionel Wolovitz
Priority date: 2011-01-21
Filing date: 2012-01-23
Publication date: 2012-07-26
Also published as: GB2501653A; GB201101073D0; GB2487533A; GB201314269D0

Abstract

Embodiments of the invention are concerned with an access control system. In a first aspect, the access control system is directed towards controlling network access by an application running on the client device. Ina second aspect, the access control system is directed towards controlling access to services within a network, using known single sign on technology such as Kerberos ^(TM). A unifying feature of both access control systems is that access is controlled on the basis of an identifier corresponding to the application running on the client device. This identifier is known to the client device and to (a) device(s) configured within the network by means of an application provisioning process.

Description

Method and system for controlling access to networks and/or services

Field of the Invention

The present invention relates to a network access control system for controlling access to a network and/or services, and is particularly, but not exclusively, suited to ensuring secure access to single sign-on services.

Background of the Invention

Demand for mobile devices with powerful processors, high-resolution screens, abundant memory, fast wireless networking and operating systems that allow third party applications is growing rapidly. Sales growth of smartphones has outstripped the rest of the mobile phone market for several years and this trend is set to continue. Apple Inc. created a new tablet computing device category with the introduction of the iPad in April 2010 that has seen an unprecedented rate of adoption and other manufacturers are now responding with their own tablet devices, mostly based on the Android operating system from Google Inc. The 2011 market forecast for tablet devices is forecast by various analysts to exceed 24 million devices.

These smartphones and tablets are powerful computers with advanced wireless networking capable of both local area and wide-area network connections to the Internet and enterprise private networks. These mobile devices are based on modern open operating systems (for example iOS from Apple Inc., Android from Google Inc., Symbian OS from Nokia Corporation) that allow users to install applications of their choice, commonly available for purchase through application store-fronts (App Stores).

The ease of use and utility of these devices and applications means that users increasingly demand convenient access to their work information and services for example email, CRM or corporate intranet on their devices, in addition to personal use. The needs of these employees presents a security challenge for the employer who needs to protect the enterprise private network and services within the network from unauthorised access and malware (computer viruses, Trojans or worms) as well as protecting confidential data from tampering or theft, both within the enterprise private network and on all employee's computing devices that connect to the network.

There are well established technologies and products available on the market designed to protect and secure the enterprise network and computing devices that access the network. For example 802. l lx can be used for network access control to the local network over Wi-Fi or Ethernet and VPNs can be used for remote network access, both of these requiring users to authenticate to the network before access is granted. In addition services on the network are configured to require user authentication for users who are authorised to access these services.

To avoid the inconvenience of users having to provide their authentication credentials to each service every time they require access to these services, single sign-on (SSO) methods are commonly deployed, for example Kerberos or Integrated Windows Authentication. To protect computers from virus, worm and Trojan attacks, anti -virus technology is commonly deployed to attempt to secure the computer from these attacks as well as applying regular security patches to the operating system and applications that fix security vulnerabilities that are discovered. To protect computers from data theft and unauthorised access hard disk encryption or application data encryption can be used in addition to requiring users to enter a password (login) to access the computer and automatically locking the computer after a period of inactivity or when it is switched off.

Managing the computers and ensuring that they have the correct antivirus software and latest virus definition files, latest security patches and correct security and access control policies in place is a complex, time consuming and expensive task. The task is made even more difficult for mobile devices for a number of reasons. The increasing trend is for these devices to be owned by employees, which makes enforcing security policies and restricting users from installing unknown third party applications impractical. The device manufacturers provide infrequent software updates and therefore security vulnerabilities remain deployed in the field for extended periods of time.

The device operating systems do not yet support sophisticated secure device management and with the wide range of devices and operating system variants from different device manufacturers, remotely managing these devices except for the most rudimentary tasks is not feasible. File system encryption is commonly supported but it is well known that the method employed is ineffective in securing data as there are known methods for attackers to extract unencrypted data from the devices without having to tamper or modify the device software at all. Furthermore there are methods, commonly called jailbreaking or rooting, that allow users (or attackers) to gain unlimited (root) access to both iOS and Android devices that enables modification or removal of security measures and unlimited access to user and system data and settings. Consequently a working assumption for any security professional tasked with securing mobile devices and securing the enterprise private network should be that these mobile devices are not trusted platforms and that the device has been compromised. The challenge then is to still protect enterprise confidential data and the network when these mobile devices are used to access the network.

Virtual Private Networks (VPNs) have been available for both Android and iOS devices for some time; however the older VPN technologies do not work well in a mobile context and newer Secure Sockets Layer (SSL) VPN clients have only recently become available, for example AnyConnect from Cisco Systems Inc. and Junos Pulse from Juniper Networks Inc. Wi-Fi access can also be protected with WPA2 enterprise. Both these technologies provide network data encryption and user authentication to the network, but they both suffer from the same security flaw in that once the user has been authenticated then any application or service on the device is able to gain access to the enterprise private network, including any malware. Similarly any SSO method would be unprotected and would allow malware to gain access to services on the enterprise private network once the user had been initially authenticated. An example of a typical unsecure client server arrangement is shown in Figure 1. In this example a user is accessing an enterprise intranet remotely using a VPN. VPN client 150 is a service on the client device 100 that enables IP communication between any application or service on device 100 and services on the intranet 305 via Internet 200 and VPN server 350 once the user has authenticated with the VPN service. Kerberos 110 is a conventional service on the client device 100 that enables, in conjunction with the Kerberos Key Distribution Center (KDC) 315, any application to authenticate with services on the intranet 305 that support Kerberos authentication. Kerberos 110 communicates with KDC 315 via a VPN tunnel over the Internet 200.

As shown in the figure, the client device 100 has three applications 120, 130, 140 installed thereon; the first two are enterprise applications (which is to say that they have been provisioned by the network), while the third has been installed independently of the enterprise. As will be seen, a conventional client- server arrangement makes no distinction between the three applications, and grants full access to the enterprise network 305 to each application.

The first applicationl 120 wishes to access Service 1 320 in the intranet and makes a request to the Kerberos service 110 for a service ticket using the Kerberos API 5. As the user (user A) of the client device 100 has not yet authenticated, the Kerberos service 110 does not have a valid Ticket Granting Ticket (TGT) in the keystore 105. The user is prompted for their credentials and then the Kerberos service 110 obtains a TGT from KDC 315 and saves this in keystore 105. The Kerberos service 110 then obtains a service ticket for Servicel 320 from KDC 315, saves this in keystore 105, and returns the service ticket to applicationl 120. The applicationl 120 then presents this service ticket to Service 320, which then grants access to the application 120.

The second application 2 130 makes a request to the Kerberos service 110 for a service ticket using the Kerberos API. Kerberos 110 has a valid TGT in the keystore 105 so the user does not have to be prompted for their credentials. Using the stored TGT, Kerberos 110 obtains a service ticket for Service2 330 from the KDC 315, saves this in keystore 105, and returns the service ticket to the application2 130. The application 130 then presents this service ticket to Service2 330, which then grants access to Application2 130.

Malware 140 then makes a request to the Kerberos service 110 for a service ticket using the Kerberos API 6. As Kerberos 110 has no access control in place, Malware 140 has full access to the Kerberos service 110. Kerberos 110 has a valid service ticket for Service 1 320 in the keystore 105 and returns this to Malware 140, which presents this service ticket to Service 1 330. As VPN client 150 has no access control in place beyond initial user authentication, Malware 140 is able to connect to Service 1 330 and indeed any destination on the intranet 305.

It is an object of the present invention to provide an improved network and application access control system and method.

Summary of the Invention

In accordance with aspects of the invention there is provided a device, a network entity system, computer readable medium and methods which collectively make up an access control system according to the appended claims.

A first embodiment provides a device for use in controlling access by an application executing on the device to a network, the application having an identity and the device comprising a network access portion arranged to:

perform a cryptographic function whereby to generate a cryptographic credential corresponding to the application, said cryptographic credential being suitable for use in verification of said application by a corresponding network access portion in the network; and

transmit said cryptographic credential and an identifier corresponding to said application identity for reception by the corresponding network access portion in the network whereby to grant access by said application to said network.

A second embodiment provides a network entity system for use in controlling access by an application executing on a device to a network, the application having an identity and the network entity system comprising a network access portion arranged to:

receive data indicative of a cryptographic credential corresponding to the application and an identifier corresponding to the application identity from the device;

validate said received cryptographic credential using a cryptographic function on the basis of the identifier corresponding to the application; and

selectively grant access by said application to said network in dependence on said validation.

A third embodiment provides a computer program, or a suite of computer programs, comprising a set of instructions, which, when executed by a device (100a), causes the device to perform a method for use in controlling access by an application (120) executing on the device to a network (305a), the method comprising:

performing a cryptographic function whereby to generate a cryptographic credential (Ck) corresponding to the application, said cryptographic credential being suitable for use in verification of said application by a corresponding network access portion (350, 520) in the network; and

transmitting said cryptographic credential and an identifier (400a) corresponding to said application identity for reception by the corresponding network access portion (350, 520) in the network whereby to grant access by said application to said network.

A fourth embodiment provides a computer program, or a suite of computer programs, comprising a set of instructions, which, when executed by a network entity system, causes the network entity system to perform a method for use in controlling access by an application (120) executing on a device (100a) to a network (305a) with which the network entity system is associated, the application having an identity (310a) and the method comprising the steps of: receiving data indicative of a cryptographic credential (Ck) corresponding to the application and an identifier (400a) corresponding to the application identity from the device; validating said received cryptographic credential using a cryptographic function on the basis of the identifier corresponding to the application; and

selectively granting access by said application to said network in dependence on said validation.

These embodiments collectively make up a system hereinafter referred to as a network access control system, which controls access by an application running on a client device to a network. When viewed in combination, the network access control system comprises:

a first network access portion configured on the client device; and a second network access portion configured within the network, wherein the first network access portion and the second network access portion cooperate such that access to the network is granted on the basis of an identifier corresponding to a said application and a cryptographic credential suitable for use in verification of said application by the second network access portion in the network. Accordingly, the first network access portion is that configured on the device of the first embodiment and the second network access portion is that configured on the network entity system of the second embodiment.

In preferred embodiments the identifier further corresponds to a user of the application and said client device. This enables the second network access portion to make use of single sign on technology, in which access to a given service is authenticated using user credentials, when granting access to the network.

Preferably the first network access portion comprises an activation component that is responsive to an activation request received from the application to prompt a user of the client device for credential data associated with the application such as a key, and credential data associated with the user, and to send an application activation request message to the second network access portion. The afore-mentioned key may be provided to the user as part of a separate application provisioning process, in which case it is stored in the network and accessible by the second network access portion. The application activation request message additionally includes an application authentication credential, which may, for example, be a checksum of the application executable code, and be encrypted using the provisioning key. This can be used as a means of authenticating the application itself to the second network access portion.

The activation component selectively combines the user credential data with data identifying the application and data identifying the client device so as to generate the identifier corresponding to the application, and the activation component encapsulates the identifier within the application activation request message. Further, the activation component generates a token granting token authenticator from the user credential data and can encrypt the token granting token authenticator using the application credential data; this is then combined with the identifier corresponding to the application within the application activation request message.

The token granting token authenticator is decrypted by the second network access portion using a provisioning key corresponding to the one entered by the user, i.e. the key issued at the time of application provisioning. If successfully decrypted, the token granting token authenticator is then used by the second network access portion to request a token granting token from a token issuer. The token granting token that is issued by the token issuer is stored in a keystore accessible by the second network access portion.

The second network access portion can generate a cryptographic key, which is for use in authenticating network access requests and also for securely passing tokens associated with a given token generating token to the first network portion. Accordingly the cryptographic key is stored in the aforementioned keystore in the network and, using the provisioning key, is securely forwarded to the activation component of the first network access portion on the client device.

Once an application has been activated, network access request messages can be authenticated by the second network access component: a network access request comprises the identifier corresponding to at least the application requesting network access, and, when received by the second network access portion, is used to identify a token granting token corresponding thereto. If the application has been successfully activated, in the manner described above, such a token granting token will be available to the second network access portion. In certain circumstances the token granting token may have expired, in which case the second network access portion performs a token generating process; however, if the token granting token is still valid, the first network access portion is granted access to the network via e.g. a suitable network access granting instruction that is sent to the first network portion.

The token generating process involves the second network portion sending a challenge request message to the first network portion, this causing the first network portion to request credentials from the user. These credentials are then used to generate a token generating token authenticator, as described above in relation to the activation process. The token generating token authenticator is securely sent to the second network access portion, this time using the cryptographic key generated during the activation process and, if successfully decrypted, is used to request a token granting token from the token issuer. The first network access portion is then granted access to the network.

In a first arrangement the first network access portion further comprises a data communications client capable of controlling a communications interface on the client device so as to configure a connection with the second network access portion. In a particularly convenient arrangement the data communications client and indeed the activation component are integrated with the application, but the data communications client can alternatively be configured as a service on the client device.

When the client device is remotely accessing the network via a further network, such as the Internet, the first and second network access portions may implement virtual private network technology to enable communication therebetween. In this case the first and second network access portions may be a VPN client and a VPN server respectively, and the VPN server may implement a Remote Authentication Dial In User Service (RADIUS) client to cooperate with the AAA server incorporating a RADIUS server so as to authenticate incoming access requests. In a further arrangement, such as where the client device is locally accessing the network, the first and second network access portions may implement any of Wi-Fi and Ethernet technologies.

In a further arrangement the first network access portion comprises a plurality of data communications clients, each of which is configured to communicate with different second network access portions. This means that client devices can be configured with multiple data communications clients, each implementing, for example, a different VPN technology and thereby enabling applications to connect to different networks using a variety of data communication technologies. The different second network access portions may be located in different networks, enabling applications to access different networks. In arrangements in which the data communications clients are integrated with the application, the plurality of data communications clients may be provided as a plug-ins to, or communicate with, the applications via Application Programming Interface (API) libraries, which are private to the application.

In the case where the data communications client comprises a VPN client, this has to authenticate with the AAA server before it is granted access to the network via the VPN server. Consequently a malware application such as that shown in Figure 1 is denied access to the network.

A fifth embodiment provides a device for use in enabling single sign on access to services for an application running thereon and a service provided by a computer system, the computer system being located on a network, the device comprising an access control portion arranged to cooperate with a corresponding access control portion configured within the network such that single sign on access to said service is controlled on the basis of at least an identifier corresponding to said application.

A sixth embodiment provides a network entity system for use in enabling single sign on access to services for an application running on a device and a service provided by a computer system, the computer system being located on a network, the network entity system comprising an access control portion arranged to:

receive data indicative of an application identifier;

validate said received identifier on the basis of an identifier independently accessible by the network entity system and corresponding to said application; and

selectively authorise single sign on access by said application to said service in dependence on said validation.

A seventh embodiment provides a computer program, or a suite of computer programs, comprising a set of instructions, which, when executed by a device, causes the device to perform a method for enabling single sign on access to services for an application running on the device and a service provided by a computer system, the computer system being located on a network, the method comprising causing a access control portion configured on the device to cooperate with a corresponding access control portion configured within the network such that single sign on access to said service is controlled on the basis of at least an identifier corresponding to said application.

An eighth embodiment provides a computer program, or a suite of computer programs, comprising a set of instructions, which, when executed by a network entity system, causes the network entity system to perform a method for use in enabling single sign on access to services for an application (120) running on a device and a service (320) provided by a computer system, the computer system being located on a network (305a), the method comprising the steps of: receiving data indicative of an application identifier (400a);

validating said received identifier on the basis of an identifier independently accessible by the network entity system and corresponding to said application; and

selectively authorising single sign on access by said application to said service in dependence on said validation.

The fifth to eighth embodiments collectively make up a system hereinafter referred as an application access control system for use in enabling single sign on access to a service for at least one application running on a client device and a service provided by a computer, the computer being located on a network. When viewed in combination, the application access control system comprises:

a first access control portion configured on the client device; and a second access control portion configured within the network, wherein the first access control portion and the second access control portion cooperate such that single sign on access to said service is controlled on the basis of at least an identifier corresponding to a said application. The first access control portion is that configured on a device according to the fifth embodiment, and the second access control portion is that configured on the network entity system of the sixth embodiment.

In preferred embodiments the identifier further corresponds to a user of the application and said client device. This enables access to services to be provided using single sign on technology, in which access to a given service is authenticated using user credentials.

In a first arrangement the first access control portion comprises a token based client and the second access control portion comprises a token issuer and a token repository. The token repository stores tokens in association with identifiers corresponding to services for which a token has been issued, these having been generated in response to either an initial token request message from the first access control portion or on demand, e.g. if a previously generated token has expired; the token is thereafter accessible for subsequent requests from the application to access the service.

Most preferably a client device is configured with an application access control system and a network access control system, in which case the second access control portion has access to the cryptographic key generated during the activation process. In addition the token based client has access to the activation component, which holds the cryptographic key. This cryptographic key is preferably used to securely transmit a token to the token based client, and, because the token based client has access to the cryptographic key via the activation component, it is able to decrypt the token and provide it to the application. The application subsequently sends the token to the service in the network.

In the event that a token for the identifier corresponding to the application does not exist or has expired, the second access control portion performs a token generating process, which involves identifying a token granting token in the token repository and sending the token granting token to the token issuer. The token issuer issues a token that is subsequently stored in a token repository and which is securely transmitted to the first access control portion in the manner described above.

The token based client can be integrated with the application, or configured as a service on the client device. Most conveniently the token based client is integrated with the application, and, when the application access control system is used in combination with the network access control system, any unknown application such as malware cannot access services within the network because they are unable to be authenticated by the AAA Server as part of the network access granting process. Further, since the token repository provides a token to an authenticated token based client, this being encrypted with its respective unique cryptographic key, only that token based client associated with the specific application can decrypt and use the token.

Token based systems are commonly referred to as "single sign on" (SSO) systems, and examples include the Kerberos^(TM) technology mentioned in the background section. A particular advantage of the access control system according to embodiments of the invention is that it extends existing enterprise single sign-on (SSO) authentication technology that is already deployed in the enterprise (e.g. Kerberos) without requiring any modification to this deployment, and ensures that only the authenticated applications can use this SSO authentication. This provides an extremely effective and elegant means of protecting the network services from malware.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.

Brief Description of the Drawings

Figure 1 is a schematic block diagram of a conventional client server arrangement;

Figure 2 is a schematic block diagram showing an application provisioning system utilised by embodiments of the invention;

Figure 3 is a schematic block diagram showing an access control system according to an embodiment of the invention;

Figure 4 is a timing diagram showing steps performed by the components shown in Figure 3 for activating an application according to an embodiment of the invention;

Figure 5 is a schematic block diagram illustrating the storage of cryptographic keys, application, user and device identifiers according to an embodiment of the invention;

Figure 6 is a timing diagram showing steps performed by the components shown in Figure 3 for granting network access to an application according to an embodiment of the invention;

Figure 7 is a timing diagram showing steps performed by the components shown in Figure 3 for access to a network according to an alternative embodiment of the invention;

Figure 8 is a schematic block diagram showing a configuration of a plurality of data communications clients according to an embodiment of the invention;

Figure 9 is a schematic block diagram showing an application access control system according to an embodiment of the invention;

Figure 10 is a timing diagram showing steps performed by the components of Figure 9 for granting single sign on access to a service according to an embodiment of the invention; Figure 11 is a timing diagram showing steps performed by the components of Figure 9 for granting single sign on access to a service according to an alternative embodiment of the invention;

Figure 12 is a schematic block diagram illustrating the storage of token granting tokens, tokens, applications, user and device identifiers according to an embodiment of the invention;

Figure 13a is a schematic block diagram showing an alternative configuration of the first network access portion and the first application access control portion according to an embodiment of the invention;

Figure 13b is a timing diagram showing steps performed by the components of Figure 13a according to an embodiment of the invention; and

Figure 14 is a schematic block diagram showing an access control system according to an embodiment of the invention when a client device connects to the network via Wi-Fi.

Components and steps that are common between the figures are labelled with the same reference numeral for clarity; indices "a, b, c" etc. are used to distinguish between instances of a given component, step or element.

Detailed Description of the Invention

Embodiments of the invention are concerned with an access control system. In a first aspect of the invention the access control system is directed towards controlling network access by an application running on the client device. In a second aspect of the invention, the access control system is directed towards controlling access to services within a network, using known single sign on technology such as Kerberos^(TM) Each aspect will be described separately and in combination, since the two mechanisms operate independently of one another as well as in conjunction with one another.

A unifying feature of both access control systems is that access is controlled on the basis of an identifier corresponding to the application running on the client device. This identifier is known to the client device and to (a) device(s) configured within the network by means of an application provisioning process.

In this manner, embodiments of the invention enable access control of individual applications on the basis of their identifiers. Any application unknown to the access control system is not permitted to access the network and/or services within the network, thereby restricting network access to applications that can be authenticated by the access control system.

Provisioning

The applications that may be authenticated to connect to the network and/or access services therein are, in one embodiment, hosted by a repository of applications (commonly referred to as "an App Store") that may be internal or external to the network.

An example of application provisioning by an exemplary such App Store will now be explained with reference to Figure 2. The App Store 500 is accessible by connected and trusted client devices connected to the intranet 305 and may conveniently be accessed using web technology such as a browser 550a, 550b in a manner well known to one skilled in the art. The access rights of the users 600a and 600b, as regards the app store 500, may be limited to downloading applications, whereas the administrator 610 has access to management functions for maintaining applications provided via the app store 500. Without limitation, the management functions include adding a new application, updating or removing an existing application

Every application that can be provisioned by the App Store is associated with a unique application identifier 310a (hereinafter ID), which is typically defined when the application is added to the App Store 500. The mapping between applications and their IDs is maintained in a database 510 that may be internal or external to the App Store 500.

As is known in the art, and as described in http://developer.apple.eom/library/ios/#featuredarticles/F A_Wireless_Enterprise App Distribution/Introduction/Introduction.html, users can initiate application provisioning via the (trusted) browser 550a, 550b by downloading a file that triggers download of a selected application and installation on the client device 100a. Thus the user 600a interacts with the App Store user interface so as to navigate the list of identified applications, and upon identifying a desired application 310a, an application 120 is selected, triggering the download and installation process described above. The App Store 500 generates a unique instance 400a (hereinafter UID) that is at least in part indicative of the application ID 310a, and which preferably corresponds to the user ID 600a and/or device UDID 300a. This UID 400a is stored in the network 305, e.g. at least in repository 510, and utilised by the access control system for selectively granting access to the network 305 and/or a service within the network as will be described in detail later in the description.

As mentioned, the UID 400a may correspond to the User ID 600a, thereby establishing a link between the User ID 600a and the application 310a. In this way, the UID 400a would be different for different users downloading the same application 120 to the same client device. This is particularly useful in controlling network access by applications on multi-user devices, such as open access computers, and multi-user applications, such as a web browser.

When the UID 400a corresponds to the UDID 300a of the client device, a link is established between a given application downloaded by a given user on a given client device. Thus, users with multiple devices would have different UID's 400a for what is the same application, but on different client devices, thereby enabling the access control system to grant access on the basis of the individual client device being used to access the network. The App Store 500 may generate the UID 400a by hashing one or more of the ID 310a, the User ID 600a and the UDID 300a.

In this way, the access control system can uniquely identify a given application on a given client device operated by a given user from the UID 400a alone, thus creating a three way relationship between users, client devices and applications. This is particularly useful with the advent of ultra portable computing devices, for which there is increasingly a demand to accommodate users with multiple devices and indeed multiple users of devices. The usage of devices further complicates the already difficult task faced by network operators, namely to monitor each and individual user device for the presence of suspicious applications. Granting network access on the basis of an identifier that represents an instance of an application (namely the UID 400a) alleviates the risk of unknown applications accessing the network, as access to unknown applications would not be granted.

In addition to the UID 400a, the App Store 500 also generates an application credential 502a for use in application activation. This application credential 502a is stored in the database 510 in the record corresponding to the associated UID 400a and transmitted to the user, e.g. via email or other separate communication means. This application credential may comprise an activation encryption key 502a (hereinafter activation key), which may be utilised for securely activating the application.

The App Store 500 may further provide the application credential 502a to the AAA server 520 so as to enable the AAA server 520 to validate network access requests by the application. The AAA server stores these credentials and indeed identifiers in a keystore, to be described below, also located within the network.

Activation

An example of granting an application 120, which has been provisioned from the App Store 500, access to the network 305, will now be explained with reference to Figure 3.

As shown in Figure 3, client device 100a is configured with an activation component 200a and a data communications client 180a. These components make up the first network access portion of embodiments of the invention, and may be integrated with the downloaded application 120, e.g. via a plug -in or via a library of APIs which can be provisioned by the App Store 500. Alternatively the components can be embodied as a service on the client device and centrally accessible by individual applications. Figure 3 depicts the first embodiment, while Figure 13a depicts the second embodiment and is described later in the description.

The activation component 200a is responsible for handling activation of the application 120: it will be appreciated from the foregoing that until an application has been activated, an application that has been provisioned from the App Store 500 is effectively inoperable. After activation, the application can subsequently be invoked (and its access requests scrutinized according to embodiments of the invention) without requiring activation every time it executes.

The steps involved in activating an application 120 provisioned to the client device 100a will now be explained with reference to Figure 4. The application activation component 200a, in response to receiving an activation request received from the application 120, prompts the user for credential data associated therewith, which may include the user ID 600a and/or a user password (step 4.1). The activation component 200a further acquires the credential data associated with the application from the user, which as discussed above may include the activation encryption key 502a provided to the user as part of application provisioning.

The activation component 200a generates the UID 400a, i.e. the application instance ID, comprising at least the application ID 310a and optionally the UDID 300a and the user ID 600a. Using a cryptographic function, the activation component 200a may then generate an application authentication credential Ck, which may include the tamper-detect checksum of the application 120. The application authentication credential Ck may be further combined with the application credential 502a, which, in an arrangement where the application credential is the activation encryption key 502a, may involve encrypting the application authentication credential Ck using the activation encryption key 502a. The cryptographic function may comprise a non-reversible cryptographic function or any other non-forgeable function, which makes it extremely difficult, if not impossible, for the application authentication credential Ck to be created for anything other than the intended application. The activation component 200a creates a token granting token authenticator on the basis of user credentials using the user ID 600a and password, and encrypts the token granting token authenticator with the activation encryption key 502a (step 4.2).

The application authentication credential Ck may be also combined with further data, such as a timestamp corresponding to the generation of the application authentication credential Ck at the client device 100a. Usage of the timestamp imparts temporality to the application authentication credential Ck, thereby preventing replay attacks. In effect, the usage of the timestamp makes the application authentication credential Ck a time limited password.

The activation component 200a then provides the UID 400a, the encrypted token granting token authenticator and the application authentication credential Ck to the VPN client 180a (step 4.3), which transmits an application activation request message to the VPN server 350 comprising these data therein (step 4.4). In response to receiving the application activation request message at step 4.5 the AAA server 520 performs an application activation process.

In the present embodiment, this is triggered by the VPN server 350 transmitting an access request message comprising the received UID 400a, the encrypted token granting token authenticator and the application authentication credential Ck to AAA Server 520 via the RADIUS client 540 (step 4.5). The AAA server 520 receives the request from its RADIUS Server 530 and uses the UID 400a to retrieve the corresponding application credential 502a from database 510, which is used to decrypt the encrypted token granting token authenticator (step 4.6). In addition the AAA Server 520 retrieves application executable code corresponding to UID 400a (this having been stored in database 510 as described above) in order to verify the application authentication credential Ck (part of step 4.6). The AAA server 520 generates its own version of the application authentication credential: the activation component 200a and the AAA server 520 follow the same process for generating the application authentication credential. For example, this may involve checksum processing of the application executable code, involving performing a cryptographic function in respect thereof. As noted above, the cryptographic function may comprise a non-reversible cryptographic function or any other non-forgeable function.

Responsive to generation of the application authentication credential, the AAA server 520 verifies that the application authentication credential Ck it received at step 4.4 matches the generated application authentication credential. In the event that the verification of the application or of the token granting token authenticator is unsuccessful, the AAA server 520 aborts the activation process. The AAA server 520 may transmit an error message to the VPN client 180a via the VPN server 350 comprising data indicative of the unsuccessful verification.

Assuming the token granting token authenticator to be verified at step 4.6, the AAA Server 520 uses the decrypted token granting token authenticator to request a token granting token TGT (hereinafter TGT) from the KDC 315 (step 4.7), whereupon the KDC 315 validates the user's credentials using standard Kerberos techniques. In the event that the credentials are validated, the KDC 315 generates a TGT 420a (step 4.8) and returns it to the AAA Server 520 (step 4.9); otherwise the AAA Server 520 returns a RADIUS-Access-Reject error response to VPN Server 350 and the activation process ends.

Assuming the TGT 420a is returned to the AAA server 520, the AAA server 520 stores the token granting token TGT 420a in the keystore 370 in association with the user ID 600a, thereby configuring single sign on access to the network 305, specifically services therein. The AAA server 520 then generates and stores a cryptographic key 410a in the keystore 370 in association with the UID 400a. The key 410a is preferably encrypted using activation encryption key 502a and returned to the VPN server 350 for delivery to the application 120 (steps 4.10 and 4.11). The VPN server 350 then generates an activation instruction message comprising the encrypted cryptographic key 410a and transmits it to the activation component 200a via the VPN client 180a (steps 4.12 and 4.13).

Thus this key 410a is available, and specific, to the application 120 and is held by the network 305. Since the key 410a is shared between the application 120 and the network 305, it can be used to secure application data particular to the user to whom the application 120 was provisioned, and this application data can be recovered from the client device 100a under control of the network 305. In addition, and when the key 410a is linked to a user ID 600a (which it is when the UID 400a corresponds to a user of the application), it can be used to encrypt, and thereby sandbox, individual user's data on a device that is shared by multiple users.

Delivery of the cryptographic key 410a to the application 120 concludes activation; in the event that the received cryptographic key 410a has been encrypted using the application credential 502a, the activation component 200a decrypts the encrypted cryptographic key using the locally held application credential 502a, and stores the unencrypted cryptographic key 410a in a local store in association with the UID 400a corresponding to the application (step 4.14).

When the application 120 subsequently requests access to the network 305, the VPN client 180a and the VPN server 350 perform a network access granting process. The network access granting process comprises identifying a TGT 420a corresponding to the UID 400a stored at the keystore 370 (as a result of step 4.10). The TGT 420a at least in part corresponds to the user credentials 600a and may be utilised by applications for when requesting access to services to enable the application 120 to access network services without having to provide the user credentials each time a service is requested.

When single sign-on is implemented using the known Kerberos^(TM) technology, the specific mechanism by which the TGT is generated is as specified in the published Kerberos^(TM) standard; however, use of the mechanism in the context of granting access to the network 305 is new and provides a particularly elegant mechanism for configuring single sign-on access to services, since it ensures that a TGT is always available when access to the network 305 is thereafter requested.

The various credentials that are maintained at the client device 100a and the keystore 370 will now described with reference to Figure 5. The keystore 370 maintains a three way mapping uniquely identifying every application that is installed on every client device accessible by users. For example, a user A has access to applications corresponding to IDs 310a, 310b and 310c on the client device 100a, whereas a user B has access to applications corresponding to IDs 310a and 310c on the same client device 100a and user C has access to applications corresponding to ID 310b, again, the same client device 100a. Thus, the fine grained mapping architecture not only uniquely associates a given application to a given client device, but also associates it with a given user. The keystore 370 additionally stores the cryptographic key 410a provided by the AAA server 520 during activation.

As will be appreciated, embodiments of the invention are tailored to the needs of multi-user and multi-device applications by way of the three-way mapping between the application, the client device and the user. Thus, each user can be independently authenticated for an application and each application instance can be independently authenticated for each authenticated user.

Network Access

As described above, applications may request network access after they have been activated. Referring back to Figure 3, secure network access is granted by means of interactions between the data communications client 180a and a data communications server 350. In an arrangement in which the client device 100a is remotely accessing the network 305 via a further network, such as the Internet, the first and second network access portions may implement virtual private network technology to enable communication therebetween. In this case the first and second network access portions may be a VPN client 180a and a VPN server 350 respectively, and the VPN server 350 may implement a Remote Authentication Dial In User Service (hereinafter RADIUS) client 540 to cooperate with the AAA server 520 incorporating a RADIUS server 530 so as to authenticate incoming access requests.

In a further arrangement, such as where the client device is locally accessing the network 305, the first and second network access portions may implement any of Wi-Fi and Ethernet technologies. In a yet further arrangement, such as where the network 305 comprises a Local Area Network (hereinafter LAN) and the client device is directly connected to the LAN, the first network access portion implements an access control mechanism particular to the type of connection to the LAN. As will be appreciated, the first and second network access portions are suitable for implementing any access control mechanisms for both local and remote connections in both the first and the second arrangements.

An example in which a network access request is processed will be described with reference to Figure 6. The application 120 transmits an access request to the activation component 200a (step 6.1), which may generate the authentication credential Ck associated with the application (step 6.2). As described above, this may include a tamper detect checksum of the application executable code, encrypted using the key 410a and optionally incorporating a timestamp corresponding to the generation of the application authentication data at the client device 100a.

The activation component 200a then sends the access request comprising the UID 400a and, if it has been generated, the application authentication credential Ck to the VPN client 180a for delivery to the VPN server 350 (steps 6.3 and 6.4). In response to receiving the access request, the VPN server 350 sends the UID 400a and the application authentication credential Ck to the AAA server 520 for verification (step 6.5).

The AAA server 520 utilises the UID 400a to retrieve the corresponding record, in particular the key 410a, which as described above, may be held at the keystore 370 (step 6.6). If included in the network access request message, the AAA server 520 decrypts the received application authentication credential Ck using the retrieved key 410a and generates a checksum of the application executable code that it retrieves from database 510. AAA server 520 uses UID 400a to retrieve the TGT 420a from database 370 and checks that it is still valid (also part of step 6.6).

In the event that verification is unsuccessful, the AAA server 520 transmits an error message to the VPN client 180a. In the event the activation is successful, the AAA server 520 sends an access granting message to the VPN client 180a, via the VPN Server 350 to access the network 305 (steps 6.7, 6.8). The VPN client 180a sends confirmation that access to the network has been granted to the activation component 200a at step 6.9, which forwards same to the application 120 (step 6.10).

An arrangement in which the TGT has expired, meaning that the user has to be authenticated before access to the network is granted, will now be described with reference to Figure 7. That the TGT has expired is identified by the AAA server 520 when it attempts to locate a valid TGT in the manner described above (step 6.6 described above). Indeed steps 7.1-7.6 progress as described above with reference to steps 6.1-6.6.

At step 7.6, in the event that the identified TGT is determined to have expired, the AAA server 520 transmits an access challenge request message to the VPN server 350, which forwards the challenge request message to the activation component 200a via the VPN client 180a (steps 7.7 - 7.9). In response to receipt of the access challenge request message, the activation component 200a creates a token granting token authenticator on the basis of user credentials, which are acquired from the user in the manner described above in relation to step 4.2 (step 7.10).

The token granting token authenticator may be encrypted using the key 410a, thereby preparing a secure token granting token authenticator; this serves to prove the authenticity of the request to the AAA server 520. The content of a subsequently generated and transmitted challenge response message (steps 7.11- 7.13) may additionally include a computed application authentication credential Ck (cf step 4.2) and it includes the UID 400a.

In response to receiving the challenge response message, the AAA server 520 verifies the application authentication credential Ck if it was included in the challenge response message (step 7.14), and the AAA server 520 decrypts the secure token granting token authenticator using key 410a retrieved from the keystore 370. The AAA server 520 sends the now-decrypted token granting token authenticator to the KDC 315, along with a request for a TGT (step 7.15). In response to receiving the request message for a TGT, the KDC 315 validates the user's credentials and generates a TGT 420a (step 7.16). In response to successful generation of the TGT 420a, the KDC 315 transmits the TGT 420a to the AAA server 520 for storage in the record corresponding to the UID 400a maintained at the keystore 370 (steps 7.17 and 7.18).

The AAA server 520 then transmits an access confirmation message to the activation component 200a via the VPN server 350 and the VPN client 180a (steps 7.19-7.21). The activation component 200a may then notify the application 120 that it has been granted access to the network 305.

The foregoing scenarios assume that the data communications client 180a is compatible with the network server 350. However, as is well known in the art, a problem with VPN technology in particular is that there are several different proprietary technologies for implementing a VPN. Thus for an application to be able to connect to a range of networks, each implementing different VPN servers, the client device needs to be equipped with corresponding different VPN clients.

Figure 8 illustrates an example where the first network access portion comprises a plurality of data communications clients 180a and 185a, each of which is configured to communicate with different second network access portions 540 and 550. This means that client devices can be configured with multiple data communications clients, each implementing, for example, a different VPN technology and thereby enabling applications 120 and 130 to connect to different networks using a variety of data communication technologies. The different second network access portions may be located in different networks 305a and 305b, thereby enabling applications 120 and 130 to access different networks 305a and 305b.

In a particularly convenient arrangement the data communications clients 180a, 185a, 180b or 185b are integrated with the application 120 or 130, in which case the plurality of data communications clients may be provided as a plug-ins to, or communicate with, the applications via API libraries.

As shown in Figure 8, this arrangement enables the following configurations: User A is granted access to use Application 1 120 that connects to Service 1 320a on intranet 305a via VPN clientl 180a and VPN serverl 350.

User A is granted access to use Application2 130 that connects to Service2 330b on intranet 305b via VPN client2 185b and VPN server2 355.

User B is granted access to use Application 1 120 that connects to

Service 1 320a on intranet 305a via VPN clientl 180a and VPN serverl 350.

User C is granted access to use Application2 130 that connects to Service2 330a on intranet 305a via VPN clientl 180b and VPN serverl 350.

Malware 140 is unable to connect to intranet 305a as it cannot connect to VPN serverl 350 and is unable to connect to intranet 305b as it cannot connect to VPN server2 355.

Application Access Control

As described above, in addition, or separate, to granting network access, the access control system is capable of granting single sign on access, to an application running on the client device, in relation to a service within the network 305a. In this aspect of the invention, the first and second access control portions cooperate such that single sign on access to requested services is granted on the basis of at least an identifier correspond to the application, i.e. the UID 400a.

Referring to Figure 9, the first access control portion may comprise a token based client, which, in the event that the single sign on is implemented using Kerberos technology, may be a Kerberos client. The second access control portion may comprise a token-issuer and a token repository, which in the event that the single sign on is implemented using Kerberos technology, may be the KDC 315 and a token server 360, 370 respectively (hereinafter referred to as a ticket server 360 and keystore 370; tokens are alternatively referred to as tokens or tickets herein). As described above, the keystore 370 is arranged to store tokens in association with the UID 400a corresponding to the service for which a given token has been granted. In accordance with this aspect of the invention, a token based client may be integrated with the application 120 requiring single sign on access to a service within the network 305, or may be a service embodied on the client device 100a that is available to all applications on the client device.

The means for, and process of, enabling the application 120 to access the service 320 provided by the computer located in the network 305, in which single sign on access to a service is implemented using Kerberos technology will now be described with reference to Figures 9 and 10. Application 120 initiates a request to access service 320 by transmitting a token request to the Kerberos client 190a, which encapsulates the UID 400a corresponding to the application 120 in the token request and transmits it to the ticket server 360 (steps 10.1 and 10.2).

In response to receiving the token request comprising the UID 400a, the ticket server 360 triggers a token retrieval process or a token generation process. The decision as to which of the processes is invoked is dependent upon the ticket server identifying a token corresponding to the received UID 400a in the keystore 370. For example, in the event that a token corresponding to the received UID 400a is identified, the ticket server 360 triggers the token retrieval process, and in the event that it is not identified, the ticket server 360 triggers the token generation process (step 10.3). As will be appreciated, the presence of a valid token by the ticket server 360 indicates that the user has been authenticated for the requested service.

In the event that a token is not identified, the ticket server 360 checks for the presence of a TGT 420a in the keystore 370 corresponding to the UID 400a. In response to identification of the TGT 420a, the ticket server 360 checks the validity of the identified TGT 420a and, if it is determined to be valid, encrypts it using the afore-mentioned key 410a. The ticket server 360 then encrypts, whereby to securely transmit, the identified TGT 420a to the Kerberos client 190a, whereby to perform a first part of the token generation process (step 10.4).

In response to receiving the encrypted TGT, the Kerberos client 190a decrypts the encrypted TGT using the key 410a associated with the application 120 (step 10.5, this key being stored locally as a result of step 4.14). The Kerberos client 190a then transmits the TGT to the KDC 315 to trigger generation of a token for the requested service 320 (step 10.6). The KDC 315 verifies the received TGT, and in response to successfully verifying the received TGT, the KDC 315 generates a token and transmits the token to the Kerberos client 190a (steps 10.7 and 10.8). In response to receiving the token from the KDC 315, the Kerberos client 190a encrypts the received token using the cryptographic key 410a corresponding to the application (step 10.9).

The Kerberos client 190a then transmits the encrypted token in conjunction with the UID 400a to the ticket server 360 (step 10.10). The ticket server 360 retrieves the key 410a corresponding to the UID 400a and uses this to decrypt the token (step 10.11), thereby authenticating the application 120. The ticket server 360 stores the token in a record corresponding to the UID 400a maintained at the keystore 370 (step 10.11). The Kerberos client 190a additionally passes the token to the application 120 for use in accessing the service 320 (step 10.12).

These steps enable the application 120 to access the service 320 by presenting the token to the service 320, whereby to gain access to the service 320 without having to provide user credentials (steps 10.13 and 10.14).

As mentioned above, if a token corresponding to the received UID 400a exists, the second access portion (here ticket server 360) initiates a token retrieval process. Referring to Figure 11, this process involves the ticket server 360 retrieving, from the keystore 370, the token, and securely transmitting the token to the Kerberos client 190b (step 11.4). In one arrangement, secure transmission may involve the ticket server 360 encrypting the token using the key 410a and transmitting the encrypted token to the application 120.

In response to receipt of the encrypted token, the Kerberos client 190b decrypts the token using the key 410a, and passes the unencrypted token to the application 120 for use in accessing the service 320 (step 11.6). The application 120 then accesses the service 320 by presenting the token to the service (steps 11.7 and 11.8). Referring to Figure 12, the keystore 370 forming part of the second access portion may be embodied by a keystore 370a or 370b, each of which maintains tokens in relation to every user of a given client device 100a. In a first arrangement (370a), the keystore 370a maintains a list of token granting tokens 420a...420d as a function of associated users and devices: there is one TGT for each user and each device associated with the user, and there are as many tokens 430a...430n as there are authenticated requests to access services from the user and from a given device. Thus in this configuration of the keystore, token granting tokens 420a...420d and the corresponding tokens 430a...430n may be associated with the corresponding client device UDID 300a, 300b and user ID 600a, 600b.

By contrast, and assuming tokens 430 can be shared between devices for a given user, only one token granting ticket (TGT) 420 is required for each user, while there are as many tokens 430 as there are authenticated requests to access services for a given user.

Figure 13a illustrates an example in which, rather than integrating the token based client and data communications client with respect to a given application 120, the first application access control portion comprises a token based client 115 as a service on the client device 100a, and the first network access control portion comprises a data communications client 155 configured as a service on the client device 100a.

As described above, the second access control portion may comprise the KDC 315 and the ticket server 360. In such an arrangement the ticket server 360 maintains the cryptographic key 410a in association with the UID 400a. This prevents malware application 140 - which has an identity other than those UID 400a that are known to the second network access portion - from gaining access to network services by sniffing data corresponding to authenticated applications 120 and 130.

The steps involved in granting access to a network service 320 to the application 120, where the token based client 115 is provided as a service on the client device 100a, will now be described with reference to Figure 13b. The application 120 requests access to the service 320 by transmitting a request to the Kerberos client 115 using a standard Kerberos API, which then attempts to identify a token corresponding to the UID 400a in a locally maintained associated keystore 105 whereby to selectively trigger a token retrieval process or a token granting process (steps 13.1 and 13.2)

In the event that a valid token is not identified in the keystore 105, the Kerberos client 115 retrieves a ticket granting ticket corresponding to the UID 400a associated with the application 120 from the local keystore 105 (step 13.2). The Kerberos client 115 then transmits a token request to the KDC 315, the request comprising the retrieved ticket granting ticket (step 13.3).

In response to receiving the token request, the KDC 315 verifies the ticket granting ticket, and if valid, the KDC 315 generates a token (step 13.4) and transmits the generated token to the Kerberos client 115 (step 13.5). The Kerberos client 115 then sends a request to the ticket server 360 for the key 410a associated with the UID 400a (step 13.6), which responds by retrieving the requested key 410a from the keystore 370 and sending the key 410a to the Kerberos client 115 (step 13.7).

In response to receiving the token, the Kerberos client 115 saves the token in the local keystore 105, encrypts the token with the key 410a received at step 13.7, and passes the encrypted token to the application 120. The application 120, having access itself to the key 410a, decrypts the token and presents the token to the service 320, thereby invoking single sign on access to the service (steps 13.8 - 13.12).

In the event that a valid token is retrieved at step 13.2, the Kerberos client 115 requests a key 410a from the ticket server 360, and in response to receipt of the key 410a, encrypts the retrieved token with the key 410a, and passes the encrypted token to the application 120. This part of the process is as described above with reference to steps 13.8-13.12.

As mentioned above, in the arrangement shown in Figure 13a, the first network access control portion comprises a data communications client 155 configured as a service on the client device 100a (shown as VPN client 155). In this arrangement, and in order to ensure that the malware application 140 is not granted access to the network 305, the public APIs associated with the VPN client 155 include a means to enforce network access control such that the malware application 140 is unable to use a connection to the network 305 that has already been established by an authenticated application. One such means, which may be implemented using the known Network Access Protection (NAP) client-server technology developed by Microsoft^(TM), as described in e.g. "Introduction to Network Access Protection" in a white paper published June 2004. The client device 100a could be provisioned with a NAP client (not shown), which, via the associated APIs, is configured with firewall outbound connection filtering/operating system access control/network APIs so as to limit access to a network 305 to a preconfigured list of applications on the device.

Figure 14 shows an arrangement in which the client device 100a accesses the network 305 locally via Wi-Fi. As for the arrangement shown in Figure 13a, the data communications client 155 is provided as a service on the client device 100a, and in this arrangement includes a Wi-Fi client that cooperates with a Wi-Fi access point 650 embodying at least part of the second network access portion. Wi-Fi access presents particular problems to secure access since, if a device is within range of a Wi-Fi access point, if the client device 100a is able to connect to the Wi-Fi access point, the device is then effectively given unfettered access to all services on the network 305, meaning that Malware 140 can access services on the intranet 305. The Wi-Fi client 155 and Wi-Fi Access Point 650 are configured to support 802. l lx, which enables the RADIUS client 540 to interoperate with AAA Server 520 to implement the access control method described for the arrangement shown in Figure 13a. As an alternative embodiment the Wi-Fi Access Point 650 may support guest account access which allows Wi-Fi clients to be connected to the external Internet only and have no access whatsoever to the network 305. Preferably the data communications client 155 additionally includes a VPN client and the second network access portion includes a VPN server, which cooperate to grant access using the mechanism described above with reference to Figures 6 and 7. As regards the arrangements shown in Figure 13a and 14, subsequent single sign on access by application 120 to service 320 within the network 305 is controlled by a token based client as described above with reference to Figures 9 and 10. The token based client can either be provisioned as a service 115 on the client device (Figures 13a, 14), or implemented as individual token based clients, as shown in Figure 9.

Example Implementations

The foregoing describes embodiments of the invention in terms of generic "applications". Indeed, embodiments of the invention can be implemented in relation to the full range of proprietary applications, web browsers and the like.

In the event that the application 120 is a web browser, and services to which the application 120 connects are web services, these can be web sites and/or servers implemented behind an enterprise's firewall. The browser is preferably configured with a built-in VPN and Wi-Fi client as shown in e.g. Figures 3 and 14 and which implements the network access functionality described with reference to Figures 4, 6 and 7. Further, the browser can support multiple built-in VPN clients that use different vendor VPN technologies, as described with reference to Figure 8. This enables a user of the device to securely browse web sites and services that are behind enterprise's firewall, both locally on intranet (using wired or wireless local area network e.g. Ethernet or Wi-Fi) and remotely using a VPN (via Wi-Fi, Ethernet or Wireless Wide-Area Network).

All browser data relating to a given user's browsing session (cookies, browsing history, bookmarks and downloaded content e.g. HTML, CSS, images, files) can be encrypted locally using key 410a thereby safe-guarding all sensitive enterprise data that the user may have accessed. Further, all browser data is sandboxed and is inaccessible to other applications or other user sessions within the browser. In addition, by means of key 410a, browser data can be securely wiped (deleted) either remotely by user or administrator for the case where a device is lost or stolen, after defined number of failed unlock attempts or locally by user.

Access to the browser can be locked by means of a password-protection mechanism; preferably this password is distinct from the credentials described above with respect to step 4.1 that are required to authenticate user to the enterprise network, since these may only be required once per day for example.

The browser makes use of built in secure single sign-on authentication (Kerberos, WebSSO and Integrated Windows Authentication) that enables the user to automatically authenticate to any web-site or service on the protected network without having to re-enter their credentials. In particular, and as described above, the application access control system incorporated in the browser supports multiple users and multiple authentication realms, enabling multiple users to use the same browser to authenticate to services on one or more different enterprise networks.

In this regard the browser has support for multiple users, each with their own password lock and separate and private browser data. Further, individual users can create multiple user accounts and switch between them.

Each user has one or more user accounts:

Each user account has completely separate and isolated (sandboxed) data that is encrypted and password protected as described above;

Each user account has its own tabs, favourites, settings and secured browser data as described above;

Each user account can be separately authenticated with choice of enterprise network (domain);

· Each account may use the same or different VPN client technology, compatible with the VPN server deployed for their enterprise network, as described above.

Each account is locked when user switches to another account, exits their account or automatically after a defined inactivity period. The user may also manually lock their account. This allows the same device to be securely shared with colleagues to access their data. As a result, a single user can securely access different systems by having separate accounts, thereby ensuring secure access to each network and ensuring that data from each network is isolated.

In addition, and because all of a given user's data is sandboxed, the browser can be configured to allow users to access the Internet in addition to enterprise networks while keeping the user's data associated with each network separate and secure. In a particularly convenient arrangement, the data communications client 180a can be configured to automatically switch between the Internet and an enterprise network based on the URL or IP address of the data or service being accessed.

As regards proprietary, or enterprise, applications, the data communications client 180a, 155 and the token based client 190a, 115 are embodied as application libraries which enable these applications to benefit from secure network access, VPN, Kerberos, password and encryption key management in the manner described above .

As described above, Figures 4, 6, 7, 10, 11, 13b illustrate messages transmitted between, and functions performed by, a device and various network entities according to example embodiments of the invention. It will be understood that each functional step may be implemented by various means, such as hardware, firmware, processor, circuitry, and/or other devices associated with execution of software including one or more computer program instructions. For example, one or more of the procedures described above may be embodied by computer program instructions. In this regard, the computer program instructions which embody the procedures described above may be stored by a memory device of an apparatus employing an embodiment of the present invention and executed by a processor of the apparatus. As will be appreciated, any such computer program instructions may be loaded onto a computer or other programmable apparatus (e.g., hardware) to produce a machine, such that the resulting computer or other programmable apparatus implements the functions specified in the figures. These computer program instructions may also be stored in a computer-readable memory that may direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture the execution of which implements the function specified in the figures. The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operations to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide operations for implementing the functions specified in the figures

The above embodiments are to be understood as illustrative examples of the invention. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

Claims 1. A device (100a) for use in controlling access by an application

(120) executing on the device to a network (305a), the application having an identity (310a) and the device (100a) comprising a network access portion (180a; 155) arranged to:

perform a cryptographic function whereby to generate a cryptographic credential (Ck) corresponding to the application, said cryptographic credential being suitable for use in verification of said application by a corresponding network access portion (350, 520) in the network; and

transmit said cryptographic credential and an identifier (400a) corresponding to said application identity for reception by the corresponding network access portion (350, 520) in the network whereby to grant access by said application to said network.

2. A device according to claim 1, wherein the cryptographic function is a non-reversible cryptographic function.

3. A device according to claim 1, wherein said identifier (400a) further corresponds to a user of the application (120).

4. A device according to claim 1 or claim 2, wherein said identifier (400a) further corresponds to said device.

5. A device according to any one of the preceding claims, wherein said network access portion (180a; 155) comprises an activation component (200a), the activation component being responsive to an activation request received from the application to prompt a user of the device for credential data associated with the application and credential data associated with the user (600a), the credential data associated with the application comprising an encryption key (502a), and to transmit an application activation request message to the corresponding network access portion.

6. A device according to claim 5, wherein the application activation request message comprises said cryptographic credential (Ck) and the identifier (400a), the network access portion (180a; 155) being arranged to selectively generate the identifier (400a) from data identifying the device (300a) and the received user credential data (600a).

7. A device according to claim 5 or claim 6, wherein the activation component is arranged to use the application encryption key (502a) associated with the application to generate an authentication credential associated therewith and to encapsulate the application authentication credential within the application activation request message.

8. A device according to any one of claim 5 to claim 7, wherein the activation component (200a) is arranged to generate a secure token granting token authenticator from the user credential data by means of the application encryption key (502a), and to encapsulate the secure token granting token authenticator and the cryptographic credential corresponding to the application within the application activation request message.

9. A device according to any one of claim 5 to claim 8, wherein the network access portion (180a; 155) is arranged to receive an activation instruction message comprising data indicative of a cryptographic key (410a), said cryptographic key (410a) being suitable for use in securing messages transmitted by said network access portion for receipt by said corresponding network access portion (350, 520).

10. A device according to claim 9, wherein at least a portion of said activation instruction message is encrypted, and the network access portion (180a; 155) is arranged to decrypt said received activation instruction message on the basis of said application encryption key (502a) whereby to obtain data indicative of said cryptographic key (410a).

11. A device according to any one of the preceding claims, wherein said network access portion comprises a data communications client (180a; 155) capable of controlling a communications interface on the device (100a) so as to configure a connection with said network.

12. A device according to claim 11, wherein the data communications client (180a) is integrated with the application (120).

13. A device according to claim 11, in which the device (100a) comprises a plurality of applications (120), each said application being capable of accessing corresponding services in the network, wherein the data communications client (155) is a client service provided on the device (100) and accessible by said plurality of applications (120).

14. A device according to claim 12 or claim 13, wherein the network access portion comprises a plurality of said data communications clients (180a; 185a), each said data communications client being configured to configure connections with different network access authorisation entities.

15. A device according to any one of claim 11 to claim 14, wherein the data communications client is further configured with one or more firewall outbound connection rules, said rules being used to control access to the network by applications on the device.

16. A device according to any one of claim 11 to claim 15, wherein the data communications client is further configured with operating system mandatory access control, said access control being for use in controlling access to the network by applications on the device.

17. A device according to any one of claim 11 to claim 16, wherein the data communications client is further configured with access control for all network Application Programming Interfaces, said access control being for use in controlling access to the network by applications on the device.

18. A device according to any one of claim 11 to claim 17, wherein the network comprises a Local Area Network (LAN) and the device is directly connected to the LAN, wherein the data communications client (155) is a service provided on the device (100) which implements an access control mechanism particular to the type of connection to the LAN.

19. A device according to any one of the preceding claims, wherein said network access portion (180a; 155) implements any one of Wi-Fi, VPN and Ethernet technologies.

20. A network entity system for use in controlling access by an application (120) executing on a device (100a) to a network (305a), the application having an identity (310a) and the network entity system comprising a network access portion arranged to:

receive data indicative of a cryptographic credential (Ck) corresponding to the application and an identifier (400a) corresponding to the application identity from the device;

21. A network entity system according to claim 20, wherein the network access portion is arranged to use a one-way cryptographic function, whereby to validate the received cryptographic credential.

22. A network entity system according to claim 20 or claim 21, wherein said identifier (400a) further corresponds to a user of the application (120).

23. A network entity system according to any one of claim 20 to claim 22, wherein said identifier (400a) further corresponds to said device.

24. A network entity system according to any one of claim 20 to claim 23, wherein, responsive to receiving an application activation request message comprising a secure token granting token authenticator, said secure token granting token authenticator being generated from a user credential, the network access portion is further arranged to perform an application activation process, the application activation process comprising:

requesting a token granting token (420a) from a token-issuer (315) said request comprising the token granting token authenticator.

25. A network entity system according to claim 24, wherein at least a portion of said application activation request message is encrypted, wherein the application activation process comprises decrypting said portion of the application activation request message on the basis of an application encryption key (502a) assigned thereto.

26. A network entity system according to claim 24 or claim 25, wherein the network access portion is responsive to receipt of said requested token granting token (420a) to store the token granting token (420a) in a token repository (370) in association with said identifier (400a) corresponding to the application (120).

27. A network entity system according to any one of claim 24 to claim 26, wherein, responsive to at least receipt of the token granting token

(420a), the application activation process comprises:

generating a cryptographic key (410a);

transmitting an activation instruction message comprising the generated cryptographic key (410a) for reception by the device; and

storing the generated cryptographic key (410a) in the repository (370) within the network.

28. A network entity system according to claim 27, wherein the network access portion is arranged to encrypt the generated cryptographic key (410a) using an application encryption key (502a) prior to transmitting said generated cryptographic key (410a) within the activation instruction message.

29. A network entity system according to any one of claim 20 to claim 28, wherein said network access portion (350, 520) is responsive to a network access request message comprising said cryptographic credential, to perform a network access granting process, said network access granting process comprising:

retrieving a token granting token (420a) held within the network (305a) on the basis of said identifier (400a) corresponding to said application; and

responsive to retrieval of a valid said token granting token (420a), granting the application (120) access to the network.

30. A network entity system according to claim 29, wherein the network access portion has access to a repository (510) arranged to store application encryption keys (502a) and identifiers corresponding to applications that have been installed on a device, and is arranged to recover a token granting token authenticator from the network access request message on the basis of a corresponding application encryption key (502a) stored in the repository.

31. A network entity system according to any one of claim 19 to claim 32, wherein said network access portion (350, 520) implements any one of

Wi-Fi, VPN and Ethernet technologies.

32. A computer program, or a suite of computer programs, comprising a set of instructions, which, when executed by a device (100a), causes the device to perform a method for use in controlling access by an application (120) executing on the device to a network (305a), the method comprising:

33 A computer program according to claim 32, wherein, when executed by the device and responsive to an activation request received from the application, the set of instructions causes the device to prompt a user of the device for credential data associated with the application and credential data associated with the user (600a), the application credential data comprising an application encryption key (502a), the set of instructions further causing the device to transmit an application activation request message to the network entity system.

34. A computer program according to claim 33, wherein the application activation request message comprises said cryptographic credential (Ck) and the identifier (400a), and the set of instructions causes the device to selectively generate the identifier (400a) from data identifying the device (300a) and the received user credential data (600a).

35. A computer program according to claim 33 or claim 34, wherein, when executed by the device, the set of instructions causes the device to use the application encryption key (502a) associated with the application to generate an authentication credential associated therewith and to encapsulate the application authentication credential within the application activation request message.

36. A computer program according to any one of claim 33 to claim 35, wherein, when executed by the device, the set of instructions causes the device to generate a secure token granting token authenticator from the user credential data by means of the application encryption key (502a), and to encapsulate the secure token granting token authenticator and the cryptographic credential corresponding to the application within the application activation request message.

37. A computer program according to claim 36, wherein the device receives an activation instruction message, at least a portion of said application activation instruction message being encrypted and, when executed by the device, the set of instructions causes the device to decrypt said received activation instruction message on the basis of said application encryption key (502a), whereby to obtain data indicative of said cryptographic key (410a), the cryptographic key (410a) being for use in securing messages transmitted by the device for receipt by said network entity system (350, 520).

38. A computer program, or a suite of computer programs, comprising a set of instructions, which, when executed by a network entity system, causes the network entity system to perform a method for use in controlling access by an application (120) executing on a device (100a) to a network (305a) with which the network entity system is associated, the application having an identity (310a) and the method comprising the steps of: receiving data indicative of a cryptographic credential (Ck) corresponding to the application and an identifier (400a) corresponding to the application identity from the device;

validating said received cryptographic credential using a cryptographic function on the basis of the identifier corresponding to the application; and

39. A computer program according to claim 38, wherein, when executed by the network entity system, the set of instructions causes the network entity system to use a one-way cryptographic function, whereby to validate the received cryptographic credential.

40. A computer program according to claim 38 or claim 39, wherein, when executed by the network entity system and responsive to receiving an application activation request message comprising a secure token granting token authenticator, the set of instructions causes the network entity system to perform an application activation process, the application activation process comprising: requesting a token granting token (420a) from a token-issuer (315) said request comprising the token granting token authenticator.

41. A computer program according to claim 40, wherein at least a portion of said application activation request message is encrypted, wherein the application activation process comprises decrypting said portion of the application activation request message on the basis of an application encryption key (502a) assigned thereto.

42. A computer program according to claim 40 or claim 41, wherein, responsive to at least receipt of the token granting token (420a), the application activation process comprises:

generating a cryptographic key (410a);

43. A computer program according to claim 42, wherein, when executed by the network entity system, the set of instructions causes the network entity system to encrypt the generated cryptographic key (410a) using an application encryption key (502a) prior to transmitting said generated cryptographic key (410a) within the activation instruction message.

44. A computer program according to any one of claim 38 to claim 43, wherein, when executed by the network entity system, and responsive to a network access request message comprising said cryptographic credential, the set of instructions causes the network entity system to perform a network access granting process, said network access granting process comprising:

45. A method for use in controlling access by an application (120) executing on a device (100a) to a network (305a), the application having an identity (310a), the method comprising:

receiving data indicative of a cryptographic credential (Ck) corresponding to the application and an identifier (400a) corresponding to the application identity from the device; validating said received cryptographic credential on the basis of an application credential independently generated by the network entity system on the basis of the identifier corresponding to the application ; and

46. A method according to claim 45, the method comprising:

performing a one-way cryptographic function in respect of the application and on the basis of said application identifier (400a) whereby to generate a validation credential; and

comparing said validation credential to said received cryptographic credential for validation thereof.

47. A method according to claim 45 or claim 46, wherein the method comprises performing an application activation process, the application activation process comprising:

48. A method according to claim 47, wherein at least a portion of said application activation request message is encrypted, wherein the application activation process comprises decrypting said portion of the application activation request message on the basis of an application encryption key (502a) assigned thereto.

49. A method according to claim 47 or claim 48, wherein, responsive to at least receipt of the token granting token (420a), the application activation process comprises:

generating a cryptographic key (410a);

transmitting an activation instruction message comprising the generated cryptographic key (410a) for reception by the device; and storing the generated cryptographic key (410a) in the repository (370) within the network.

50. A method according to claim 49, wherein the method comprises encrypting the generated cryptographic key (410a) using an application encryption key (502a) prior to transmitting said generated cryptographic key (410a) within the activation instruction message.

51. A method according to any one of claim 45 to claim 50, wherein the method comprises performing a network access granting process, said network access granting process comprising:

52. A device for use in enabling single sign on access to services for an application (120) running thereon and a service (320) provided by a computer system, the computer system being located on a network (305a), the device comprising an access control portion arranged to cooperate with a corresponding access control portion configured within the network such that single sign on access to said service is controlled on the basis of at least an identifier (400a) corresponding to said application.

53. A device according to claim 52, wherein the access control portion is arranged to perform a cryptographic function on the basis of the identifier (400a) corresponding to said application whereby to generate a cryptographic credential (Ck), said cryptographic credential being suitable for use in verification of said application by the corresponding access control portion in the network; and transmit said cryptographic credential for reception by said corresponding access control portion in the network whereby to grant access to said service.

54. A device according to claim 52 or claim 53, wherein the identifier (400a) further corresponds to a user of the application.

55. A device according to any one of claim 52 to claim 54, wherein the identifier (400a) further corresponds to said device.

56. A device according to any one of claim 52 to claim 55, wherein the access control portion comprises a token based client (190a)

57. A device according to claim 56, wherein the token based client (190a) is integrated with said application.

58. A device according to claim 56 or claim 57, wherein the token based client (190a) is arranged to receive a token granting token, and perform a token generation process so as to generate a token for use by said application in accessing said service.

59. A device according to claim 58, wherein the token based client (190a) is arranged to pass the generated token to the application (120) to enable single sign on access to the service (320).

60. A device according to any one of claim 52 to claim 55, wherein the access control portion comprises a token based client (115, 105) as a service on the device, said token based client (115, 105) being accessible by a plurality of applications.

61. A device according to claim 60, wherein the token based client (115, 105) is responsive to a token request comprising said identifier (400a) from the application whereby to selectively trigger a token retrieval process or a token generation process, selection of a given process being dependent on the presence of a token corresponding to said identifier (400a) being locally accessible to the token based client (115, 105).

62. A device according to claim 61, wherein the token based client (115, 105) is responsive to said token request to identify a valid token granting token corresponding to said identifier (400a) and to request and store a token corresponding to said identified token granting token received from the network, whereby to perform said token generation process.

63. A device according to claim 62, wherein the token based client (115, 105) is arranged to request and receive a cryptographic key (410a) corresponding to said identifier (400a) from a corresponding network access control portion (360, 370), for use in encrypting the token received therefrom.

64. A device according to claim 61, wherein the token based client (115, 105) is responsive to said token request to identify and retrieve a valid token corresponding to said identifier (400a), whereby to perform said token retrieval process.

65. A device according to claim 63 or claim 64, wherein the token based client (115, 105), using the received cryptographic key (410a), is arranged to securely pass the token to the application (120) for use in single sign on access to the service (320).

66. A device according to any one of claim 62 to claim 65, wherein the device comprises a network access portion (180a; 155), said network access portion being arranged to cooperate with a corresponding network access portion, wherein access to said network is granted on the basis of at least said identifier (400a) corresponding to a said application.

67. A device according to claim 66, wherein the network access portion (180a) is integrated with said application (120).

68. A network entity system for use in enabling single sign on access to services for an application (120) running on a device and a service (320) provided by a computer system, the computer system being located on a network (305a), the network entity system comprising an access control portion arranged to:

receive data indicative of an application identifier (400a);

69 A network entity system according to claim 68, wherein the received data comprises a cryptographic credential (Ck) corresponding to said application and the access control portion is arranged to validate the cryptographic credential.

70. A network entity system according to claim 68 or claim 69, wherein the identifier (400a) further corresponds to a user of the application.

71. A network entity system according to any one of claim 68 to claim 70, wherein the identifier (400a) further corresponds to said device.

72. A network entity system according to any one of claim 68 to claim 71, wherein the access control portion comprises a token-issuer (315) and a token repository (360, 370), wherein the token repository is arranged to store issued tokens in association with an identifier (400a) corresponding to an application to which a given said token has been issued.

73. A network entity system according to claim 72, wherein the token repository (360, 370) is responsive to a token request message comprising said identifier (400a) from the application whereby to selectively trigger a token retrieval process or a token generation process, selection of a given process being dependent on the presence of a token corresponding to said identifier (400a) within the token request message being stored in the token repository (360, 370).

74. A network entity system according to claim 73, wherein the token repository (360, 370) is responsive to said token request message to identify a valid token granting token corresponding to said identifier (400a) and to securely transmit the identified token granting token to the device, whereby to perform said token generation process.

75. A network entity system according to claim 74, wherein the token-issuer (315) is responsive to receipt of the token granting token to generate a token for issuance to the device and wherein the token repository (360, 370) is responsive to receipt of said generated token from the device in conjunction with said identifier (400a) to store the generated token in dependence on the identifier (400a).

76. A network entity system according to claim 73, wherein the token repository (360, 370) is responsive to said token request to identify and retrieve a valid token corresponding to said identifier (400a) and to securely transmit the retrieved token to the device, whereby to trigger said token retrieval process.

77. A network entity system according to any one of claim 69 to claim 76, wherein the network entity system is arranged to cooperate with a network access portion in the network (305a), said network access portion being arranged to cooperate with a corresponding network access portion on the device such that access by said application to said network is granted on the basis of at least said cryptographic credential corresponding to said application.

78. A computer program, or a suite of computer programs, comprising a set of instructions, which, when executed by a device (100a), causes the device to perform a method for enabling single sign on access to services for an application (120) running on the device and a service (320) provided by a computer system, the computer system being located on a network (305a), the method comprising causing an access control portion configured on the device to cooperate with a corresponding access control portion configured within the network such that single sign on access to said service is controlled on the basis of at least an identifier (400a) corresponding to said application.

79. A computer program according to claim 78, wherein, when executed by the device, the set of instructions causes the device to:

perform a cryptographic function on the basis of the identifier (400a) corresponding to said application whereby to generate a cryptographic credential (Ck), said cryptographic credential being suitable for use in verification of said application by the corresponding access control portion in the network; and transmit said cryptographic credential for reception by said corresponding access control portion in the network whereby to grant access to said service.

80. A computer program according to claim 78 or claim 79, wherein the identifier (400a) further corresponds to a user of the application.

81. A computer program according to any one of claim 78 to claim 80, wherein the identifier (400a) further corresponds to said device.

82. A computer program according to any one of claim 78 to claim 81, wherein, when executed by the device, the set of instructions causes the device to receive a token granting token, and perform a token generation process so as to generate a token for use by said application in accessing said service.

83. A computer program according to claim 82, wherein, when executed by the device, the set of instructions causes the device to pass the generated token to the application (120) for use in enabling single sign on access to the service (320).

84. A computer program according to any one of claim 78 to claim 83, wherein, when executed by the device and responsive to a token request comprising said identifier (400a) from the application, the set of instructions causes the device to selectively trigger a token retrieval process or a token generation process, selection of a given process being dependent on the presence of a token corresponding to said identifier (400a) being locally accessible to the token based client (115, 105).

85. A computer program according to claim 84, wherein, when executed by the device and responsive to said token request, the set of instructions causes the device to identify a valid token granting token corresponding to said identifier (400a) and to request and store a token corresponding to said identified token granting token received from the network, whereby to perform said token generation process.

86. A computer program according to claim 85, wherein, when executed by the device, the set of instructions causes the device to request and receive a cryptographic key (410a) corresponding to said identifier (400a) from a corresponding network access control portion (360, 370), for use in encrypting the token received therefrom.

87. A computer program according to claim 84, wherein, when executed by the device and responsive to said token request, the set of instructions causes the device to identify and retrieve a valid token corresponding to said identifier (400a), whereby to perform said token retrieval process.

88. A computer program according to claim 86 or claim 87, wherein, when executed by the device, the set of instructions causes the device to securely pass the token to the application (120) for use in single sign on access to the service (320).

89. A computer program, or a suite of computer programs, comprising a set of instructions, which, when executed by a network entity system, causes the network entity system to perform a method for use in enabling single sign on access to services for an application (120) running on a device and a service (320) provided by a computer system, the computer system being located on a network (305a), the method comprising the steps of:

receiving data indicative of an application identifier (400a);

90. A computer program according to claim 89, wherein the received data comprises a cryptographic credential (Ck) corresponding to said application and, when executed by the network entity system, the set of instructions causes the network entity system to validate said received cryptographic credential.

91. A computer program according to claim 89 or claim 90, wherein the identifier (400a) further corresponds to a user of the application.

92. A computer program according to any one of claim 89 to claim

91, wherein the identifier (400a) further corresponds to said device.

93. A computer program according to any one of claim 89 to claim

92, wherein, when executed by the network entity system and responsive to a token request message comprising said identifier (400a) from the application, the set of instructions causes the network entity system to selectively trigger a token retrieval process or a token generation process, selection of a given process being dependent on the presence of a token corresponding to said identifier (400a) within the token request message being stored in the token repository (360, 370).

94. A computer program according to claim 93, wherein, when executed by the network entity system and responsive to said token request message, the set of instructions causes the network entity system to identify a valid token granting token corresponding to said identifier (400a) and to securely transmit the identified token granting token for reception by the device, whereby to perform said token generation process.

95. A computer program according to claim 94, wherein, when executed by the network entity system and responsive to receipt of the token granting token, the set of instructions causes the network entity system to generate a token for issuance to the device and store said generated token in conjunction with said identifier (400a) in a token repository.

96. A computer program according to claim 93, wherein, when executed by the network entity system and responsive to said token request, the set of instructions causes the network entity system to identify and retrieve a valid token corresponding to said identifier (400a) and to securely transmit the retrieved token for reception by the device, whereby to trigger said token retrieval process.

97. A computer program according to any one of claim 90 to claim 96, wherein, when executed by the network entity system, the set of instructions causes the network entity system to cooperate with a network access portion in the network (305a), said network access portion being arranged to cooperate with a corresponding network access portion on the device such that access by said application to said network is granted on the basis of at least said cryptographic credential corresponding to said application.

98. A method for enabling single sign on access to services for an application (120) running on a device and a service (320) provided by a computer system, the computer system being located on a network (305a), the method comprises:

receiving data indicative of an application identifier (400a);

99. A method according to claim 98, wherein the received data comprises a cryptographic credential (Ck) corresponding to said application and the access control portion is arranged to validate the cryptographic credential.

100. A method according to claim 98 or claim 99, wherein the identifier (400a) further corresponds to a user of the application.

101. A method according to any one of claim 98 to claim 100, wherein the identifier (400a) further corresponds to said device.

102. A method according to any one of claim 98 to claim 101, wherein, responsive to a token request message comprising said identifier (400a) from the application, the method comprises selectively triggering a token retrieval process or a token generation process, selection of a given process being dependent on the presence of a token corresponding to said identifier (400a) within the token request message being stored in the token repository (360, 370).

103. A method according to claim 102, wherein, responsive to said token request message, the method comprises identifying a valid token granting token corresponding to said identifier (400a) and securely transmitting the identified token granting token to the device, whereby to perform said token generation process.

104. A method according to claim 102, wherein, responsive to said token request, identifying and retrieving a valid token corresponding to said identifier (400a) and securely transmitting the retrieved token to the device, whereby to trigger said token retrieval process.

105. A method according to any one of claim 99 to claim 104, wherein the method comprises causing a network access portion in the network (305a) to cooperate with a corresponding network access portion on the device such that access by said application to said network is granted on the basis of at least said cryptographic credential corresponding to said application.