GB2487533A

GB2487533A - Access control with application specific rules and access requests including application identifiers

Info

Publication number: GB2487533A
Application number: GB1101073.3A
Authority: GB
Inventors: Lionel Wolovitz
Original assignee: Individual
Current assignee: Individual
Priority date: 2011-01-21
Filing date: 2011-01-21
Publication date: 2012-08-01
Also published as: GB201314269D0; GB2501653A; GB201101073D0; WO2012098265A1

Abstract

Embodiments of the invention are concerned with an access control system. In known access control systems user and device IDs are typically used. However, if a device is host to malware this may gain unauthorised access once the device has been authenticated (see Fig. 1). The invention proposes including an Identifier 400a-d corresponding to a particular application 120,130 (and possibly user 600a,b and device 100a) in an authorisation request. Thus, each application is authenticated individually and any malware present would need to obtain its own authorisation. This identifier is known to the client device and to (a) device(s) configured within the network by means of an application provisioning process. The invention may be utilised with single sign on technology such as Kerberos(TM).

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 modem 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.1 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 anti-virus 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 (VPN5) 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 unseeure 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 apphcationl 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 application2 130 makes a request to the Kerberos service 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 S in place, Malware 140 has full access to the Kerberos service 110. Kerberos 110 has a valid service ticket for Servicel 320 in the keystore 105 and returns this to Malware 140, which presents this service ticket to Servicel 330. As VPN client has no access control in place beyond initial user authentication, Malware 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 an access control system according to the appended claims.

More specifically, in accordance with a first aspect of the present invention there is provided a network access control system for controlling access by an application running on a client device to a network, the network access control system comprising: 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 at least an identifier corresponding to a said application.

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 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 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 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 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 application activation request message may additionally include 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 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 succesfully 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 muhiple 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.

Aspects of the invention also provide software that, when executed on the client device and a server system in the network, causes the client device and server system to perform the activation and network access processes; further there is provided a client device configured with the first network access portion and a server system configured with the second network access system.

According to a second aspect of the present invention there is provided 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, the application access control system comprising: 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.

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.

Aspects of the invention also provide software that, when executed on the client device and server system in the network, causes the client device and server system to perform the aforementioned processes; further there is provided a client device configured with the first access control portion and a server system configured with the second access control system.

Token based systems are commonly referred to as "single sign on" (SSO) systems, and examples include the KerberosTM 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 afready 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 ahernative 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 ahernative embodiment of the invention; Figure 12 is a schematic block diagram illusfrating the storage of token granting tokens, tokens, application, user and device identifiers according to an embodiment of the invention; Figure 1 3a is a schematic block diagram showing an ahemative 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 KerberosTM 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 SSOa, 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 31 Oa (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 httpapple.com/library/ios/#featuredarticles/FA Wireless_Enterprise S _App_Distributionllntroductionllntroduction.html, users can initiate application provisioning via the (trusted) browser SSOa, SSOb by downloading a file that triggers download of a selected application and installation on the client device 1 OOa. 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 31 Oa, 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 3 lOa, 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 3 lOa.

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 3 lOa, 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 S 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 sewer 520 to validate network access requests by the application. The AAA sewer 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 lOOa is configured with an activation component 200a and a data communications client 1 80a. 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. Altematively 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 lOOa 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 3 lOa and optionally the UDID 300a and the user ID 600a. 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 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 lOOa. 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 (if it was generated) to the VPN client 1 80a (step 4.3), which transmits an application activation request to the VPN server 350 comprising these data therein (step 4.4). In response to receiving the application activation message at step 4.5 the AAA server 520 performs an application activation process.

This is triggered by the \TPN server 350 transmitting an access request message comprising the received UID 400a, the encrypted token granting token authenticator and the application authentication credential Ck (if it was generated) 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, if included in the application activation request (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 (e.g. checksum processing of the application executable code).

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 1 80a 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 41 Oa 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 41 Oa and transmits it to the activation component 200a via the VPN client 1 80a (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 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 lOOa 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 KerberosTM' technology, the specific mechanism by which the TGT is generated is as specified in the published KerberosTM 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 1 OOa 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 3 lOa, 3 lOb and 31 Oc on the client device 1 OOa, whereas a user B has access to applications corresponding to IDs 310a and 310c on the same client device lOOa and user C has access to S applications corresponding to ID 31 0b, again, the same client device 1 OOa. 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 1 80a and a data communications server 350. In an arrangement in which the client device 1 OOa 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 thcrebetween. In this case the first and second network access portions may be a VPN client 1 80a 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 lOOa.

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 1 80a 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 41 Oa, 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 1 80a. 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 1 80a 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 41 Oa, 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 41 Oa 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 1 80a (steps 7.19-7.2 1). 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 Applicationi 120 that connects to Servicel 320a on intranet 305a via \TPN clienti 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 Applicationi 120 that connects to Servicel 320a on intranet 305a via \TPN clienti 180a and VPN serverl 350.

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

Maiware 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 altematively 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 lOOa 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 1 90a decrypts the encrypted TGT using the key 410a associated with the application (step 10.5, this key being stored locally as a result of step 4.14). The Kerberos client 1 90a 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 veriing 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 1 90b decrypts the token using the key 41 Oa, and passes the unencrypted token to the application 120 for use in accessing the service 320 (step 11.6). The application then accesses the service 320 by presenting the token to the service (steps 11.7andll.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 lOOa. 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 430.. .43 On 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 lOOa, and the first network access control portion comprises a data communications client 155 configured as a service on the client device lOOa.

As described above, the second access control portion may comprise the ICDC 315 and the ticket server 360. In such an arrangement the ticket server 360 maintains the cryptographic key 41 Oa 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 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 lOOa, 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 S 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 41 Oa, 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 lOOa (shown as \TPN 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 MicrosoftTM, as described in e.g. "Introduction to Network Access Protection" in a white paper published June 2004. The client device lOOa 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 lOOa 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 lOOa, 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 lOOa 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.1 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 extemal 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 single signa 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 S 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 S 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 1 80a 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 enables these applications to benefit from secure network access, VPN, Kerberos, password and encryption key management in the manner described above.

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 network access control system for controlling access by an application (120) running on a client device (bOa) to a network (305a), the network access control system comprising: a first network access portion (180a; 155) configured on the client device (bOa); and a second network access portion (350, 520) configured within the network (305a), wherein the first network access portion (180a; 155) and the second network access portion (350, 520) cooperate such that access to the network is granted on the basis of at least an identifier (400a) corresponding to a said application.
2. A network access control system according to claim 1, wherein the identifier (400a) further corresponds to a user of the application.
3. A network access control system according to claim 2, wherein the identifier (400a) further corresponds to said client device.
4. A network access control system according to any one of the preceding claims, wherein said first network access portion comprises an activation component (200a), the activation component being responsive to an activation request received from the application to prompt a user of the client device for credential data associated with the application (502a) and credential data associated with the user (600a), and to send an application activation message to the second network access portion.
5. A network access control system according to claim 4, wherein the activation component (200a) is arranged to selectively combine the received user credential data (600a) with data (300a) identifying the application and data identifying the client device (300a), whereby to generate said identifier (400a) corresponding to the application, the activation component being further arranged to encapsulate said identifier (400a) within the application activation message.
6. A network access control system according to claim 5, wherein the activation component is arranged to use the received application credential data (502a) associated with the application to generate an authentication credential associated therewith and to encapsulate the application authentication credential within the application activation message.
7. A network access control system according to claim S or claim 6, 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 credential data (502a), and to encapsulate the secure token granting token authenticator and the identifier corresponding to the application (400a) within the application activation message
8. A network access control system according to claim 7, wherein said second network access portion (350, 520) is responsive to the application activation message received from the first network access portion to perform an application activation process, the application activation process comprising: using the identifier (400a) corresponding to the application to retrieve an application credential from a repository (510) within the network in order to verify the token granting token authenticator; responsive to verification of the token granting authenticator, requesting a token granting token from a token-issuer (315), said request comprising the token granting token authenticator.
9. A network access control system according to claim 8, wherein the second 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).
10. A network access control system according to claim 8 or claim 9, wherein the application activation process further comprises using the identifier (400a) corresponding to the application to retrieve an application credential from a repository (510) within the network in order to veri& said application authentication credential within the application activation message.
11. A network access control system according to claim 9 or claim 10 dependent on claim 9, wherein the application activation process comprises, responsive to at least receipt of the token granting token (420a), generating a cryptographic key (410a); sending an activation instruction message comprising the generated cryptographic key (410a) to the first network access portion; and storing the generated cryptographic key (41 Oa) in a repository (370) within the network.
12. A network access control system according to claim 11, wherein the second network access portion is arranged to encrypt the generated cryptographic key (410a) using the application credential (502a) prior to transmitting said generated cryptographic key (41 Oa) within the activation instruction message.
13. A network access control system according to claim 12, wherein the first network access portion is responsive to receipt of said activation instruction message to decrypt the cryptographic key (410a) using the application credential received from the user and to store same in a local store in association with the identifier (400a) corresponding to the application.
14. A network access control system according to any one of claim 4 to claim 13, wherein said second network access portion (350, 520) is responsive to a network access request message received from the first network access portion and comprising said identifier (400a) corresponding to the application to perform a network access granting process, said network access granting process comprising: identifying a token granting token (420a) held within the network (305a) corresponding to said identifier (400a); and responsive to identification of a valid said token granting token (420a), sending a message to the first network access portion (1 80a), whereby to grant the application (120) access to connect to the network.
15. A network access control system according to claim 14 dependent on any one of claim 11 to claim 13, wherein the activation component (200a) is arranged to generate a secure token granting token authenticator from the user credential by means of the cryptographic key (410a), and to encapsulate the secure token granting token and the identifier corresponding to the application (400a) within said network access request message.
16. A network access control system according to claim 14, wherein the second network access portion has access to a repository (510) arranged to store application credential data (502a) and identifiers corresponding to applications that have been installed on a client device, and is arranged to recover said token granting token authenticator from the network access request message on the basis of corresponding application credential data (502a) stored in the repository.
17. A network access control system according to claim 16, wherein the second network access portion is arranged to send a request for a token granting token to a token-issuer (315), said request comprising the token granting token authenticator.
18. A network access control system according to claim 17, wherein the second network access portion is responsive to receipt of said requested token granting token (420a) to store the token granting token in a token repository (360) in association with said identifier (400a) corresponding to the application (120).
19. A network access control system according to any one of the preceding claims, wherein said first network access portion comprises a data communications client (180a; 155) capable of controlling a communications interface on the client device (bOa) so as to configure a connection with said second network access portion (350, 520).
20. A network access control system according to claim 19, wherein the data communications client (180a) is integrated with the application (120).
21. A network access control system according to claim 19, in which the client device (bOa) 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 client device (100) and accessible by said plurality of applications (120).
22. A network access control system according to claim 20 or claim 21, wherein the first network access portion comprises a plurality of said data communications clients (1 80a; 185 a), each said data communications client being configured to configure connections with different said second network access portions (540; 545).
23. A network access control system according to claim 22, wherein each said different said second network access portions is located in a different network.
24. A network access control system according to any one of the preceding claims, 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 client device.
25. A network access control system according to any one of the preceding claims, 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 client device.
26. A network access control system according to any one of the preceding claims, 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 client device.
27. A network access control system according to any one of the preceding claims, wherein said first network access portion (180a; 155) and said second network access portion (350, 520) implement any one of Wi-Fi, VPN and Ethernet technologies.
28. A network access control system according to claim 27, wherein the network comprises a Local Area Network (LAN) and the client device is directly connected to the LAN, wherein the data communications client (155) is a client service provided on the client device (100) which implements an access control mechanism particular to the type of connection to the LAN.
29. A network access control system according to claim 27, wherein the data communications client (180a, 155) cooperates with the second network access portion (350, 520) to create a secured connection that is independent of the S connection to the network.
30. An application access control system for use in enabling single sign on access to services for at least one application (120) running on a client device (100) and a service (320) provided by a computer, the computer being located on a network (300), the application access control system comprising: a first access control portion (190a; 115, 105) configured on the client device; and a second access control portion (360, 370, 310) 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 (400a) corresponding to a said application.
31. An application access control system according to claim 30, wherein the identifier (400a) further corresponds to a user of the application.
32. An application access control system according to claim 31, wherein the identifier (400a) further corresponds to said client device.
33. An application access control system according to any one of claim 30 to claim 32, wherein the first access control portion comprises a token based client (190a) and the second access control portion comprises a token-issuer (310) and a token repository (360, 370), wherein the token repository is arranged to store issued tokens in association with an identifier (400a) corresponding to a said application to which a given said token has been issued.
34. An application access control system according to claim 33, wherein the token based client (190a) is integrated with said at least one application.
35. An application access control system according to claim 33 or claim 34, 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).
36. An application access control system according to claim 35, 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 token based client (190a), whereby to perform said token generation process.
37. An application access control system according to claim 36, wherein the token-issuer (310) is responsive to receipt of the token granting token to generate a token for issuance to the token based client (1 90a) and wherein the token repository (360, 370) is responsive to receipt of said generated token from the token based client (190a) in conjunction with said identifier (400a) to store the generated token in dependence on the identifier (400a).
38. An application access control system according to claim 35, 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 token based client (1 90a), whereby to perform said token retrieval process.
39. An application access control system according to claim 37 or claim 38, wherein the token based client (190a) passes the token to the application (120) to enable single sign on access to the service (320).
40. An application access control system according to claim 30, wherein the first access control portion comprises a token based client (115, 105) as a service on the client device, said token based client (115, 105) being accessible by a plurality of said applications, and the second access control portion comprises a token-issuer (310) and a repository (360, 370), wherein the repository is arranged to store a cryptographic key (410a) in association with an identifier (400a) corresponding to a said application.
41. An application access control system according to claim 40, 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).
42. An application access control system according to claim 41, 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 from the second access control portion (310), whereby to perform said token generation process.
43. An application access control system according to claim 42, wherein the token based client (115, 105) is arranged to request and receive a cryptographic key (410a) corresponding to said identifier (400a) from the second network access control portion (360, 370), for use in encrypting the token received from the second access control portion.
44. An application access control system according to claim 43 dependent on claim 41, 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.
45. An application access control system according to claim 43 or claim 44, wherein the token based client (115, 105), using the received cryptographic key (410a), securely passes the token to the application (120) for use in single sign on access to the service (320).
46. An application access control system according to any one of claim 30 to claim 45, further comprising a first network access portion (180a; 155) on the client device and a second network access portion (350, 520) configured within the network, wherein the first network access portion and the second network access portion cooperate such that access to said network is granted on the basis of at least said identifier (400a) corresponding to a said application.
47. An application access control system according to claim 46, wherein the first network access portion (180a) is integrated with said at least one application (120).