WO2007069207A2

WO2007069207A2 - Access control in a network

Info

Publication number: WO2007069207A2
Application number: PCT/IB2006/054819
Authority: WO
Inventors: Wilhelmus P. M. Van Der Linden; Engel J . Kranenborg; Wouter Baks; Maarten P. Bodlaender
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-12-16
Filing date: 2006-12-13
Publication date: 2007-06-21
Also published as: WO2007069207A3

Abstract

A network (100) comprises a control device (107) having an authorization group processor (301) which determines permission settings for authorization groups for a plurality of devices. A receive processor (309) receives an access permission request for a first device (109) accessing a second device (101) and a group processor (311) associates the first device (109) with a first group of the authorization groups in response to a user input from a user interface (303). A permission processor (313) retrieves the permission settings for the first group and these are communicated to the second device (101) by a transmit processor (315). The second device (101) then controls access by the first device (109) in accordance with the first permission settings. The invention provides improved and facilitated access control in networks such as Universal Plug and Play (UPnP) networks.

Description

Access control in a network

The invention relates to access control in a network and in particular, but not exclusively, to access control in a Universal Plug and Play network.

In recent years, data networks have become increasingly ubiquitous and are now employed in many diverse scenarios. For example, private and public wireless local area networks have become widespread and a number of standards have been developed for flexible and dynamic ad-hoc networks.

However, in line with the increased popularity of such networks, security issues have become increasingly important. For example, the underlying technology (e.g. wireless access) and services (e.g. remote access, communities, etc.) have resulted in a greater vulnerability of such networks to undesired access by unauthorized persons than is typically the case for conventional, closed networks. Although typical consumers are generally considered to take security issues seriously, the tasks and interactions required by consumers in order to achieve secure operation tend to be very complex, cumbersome and impractical. The required configuration effort thus tends to result in the risk of the user losing his overview and understanding of what and how to configure. As a result, typical consumers today tend to be incapable of creating a trusted home network.

Moreover, a number of network standards which do not provide optimal security support have been defined. For example, the standard Universal Plug and Play (UPnP) is currently emerging. UPnP enables much functionality in heterogeneous home networks but generally tends to have sub-optimal security support.

Consequently, existing solutions for security support in networks have a number of associated disadvantages. They tend to be complex and require substantial, complex and cumbersome configuration by the user.

Furthermore, some systems are based on the use and exchange of security certificates which can be impractical, as it is necessary that the certification authority is always on and accessible (basically requiring a network infrastructure to be always present to renew certificates and to verify their validity). Security certificates also tend to have revocation problems (e.g. long certificate lifetimes can result in revocation taking substantial time (e.g. days) before being effective).

Hence, an improved system for controlling access to devices of a network would be advantageous, in particular a system allowing increased flexibility, improved security, facilitated operation, reduced availability requirements for security elements, reduced complexity, reduced user interaction requirements and/or improved performance.

Accordingly, the invention seeks to preferably mitigate, alleviate or eliminate one or more of the above-mentioned disadvantages singly or in any combination.

In accordance with a first aspect of the invention, an apparatus for controlling access to devices of a network comprises: group means for determining permission settings for at least one authorization group of a plurality of authorization groups for a plurality of devices; storage means for storing the permission settings; means for receiving an access permission request for a first device accessing a second device; means for associating the first device with a first group of the at least one authorization group in response to a user input; means for determining first permission settings for the first device accessing the second device by retrieving the permission settings for the first group from the storage means; and communicating means for communicating the first permission settings to the second device.

The invention may allow improved security performance in a network. An improved user interface and/or user experience may be provided. Security configuration may be substantially facilitated and/or the requirements for user configuration can be substantially reduced. A flexible security configuration can be achieved and/or the expertise on knowledge requirements for a user configuring the system can be reduced substantially. The invention may allow facilitated and/or faster revocation of permissions, for example, by changing the permission settings for a device and/or changing the association between a device and the authorization group.

In accordance with an optional feature of the invention, the group means is arranged to determine the permission settings in response to a user input.

This may allow improved and/or facilitated user configuration of security settings in a network. In particular, it may provide a low complexity and user- friendly means of configuring access permissions to devices of the network. In accordance with an optional feature of the invention, the group means is arranged to determine the permission settings in response to a permission profile received from the second device.

This may allow improved interoperability and/or facilitated configuration of access permissions. In particular, it may allow facilitated determination of appropriate permission settings suitable for the specific device characteristics.

In accordance with an optional feature of the invention, the communicating means is arranged to generate an entry for the first device for an access control list of the second device in response to the first permission settings and to communicate the entry to the second device.

This may provide a practical implementation and/or efficient access control. It may furthermore provide compatibility with existing security systems. The feature may allow a simple, yet efficient way of controlling access to the second device.

In accordance with an optional feature of the invention, the apparatus further comprises means for dividing the at least one authorization group into a plurality of authorization groups in response to a user input.

This may provide improved flexibility and/or adaptability to changing conditions. In particular, it may provide a practical and low-complexity way for the user to change existing security settings. The authorization groups generated by dividing may inherit some or all of the characteristics of the parent authorization group.

In accordance with an optional feature of the invention, the communicating means is arranged to determine if the second device is available and, if not, to delay communication of the first permission settings until the second device is available.

This may provide improved flexibility, operation and/or facilitate implementation. In particular, it may obviate or reduce the requirement for the devices to be always online. The feature may facilitate upgrading of security settings in a dynamic network environment.

In accordance with an optional feature of the invention, the apparatus comprises means for storing a synchronization state for each device associated with the apparatus, the synchronization state being indicative of whether any communications of permission settings are pending.

In accordance with an optional feature of the invention, the apparatus comprises means for indicating to a user of the apparatus that the communication of the first permission settings to the second device is pending.

This may provide an improved user experience.

In accordance with an optional feature of the invention, the access permission request is a group access permission request for a plurality of devices for which permission is to be determined, and wherein the apparatus is arranged to generate an entry of an access control list of the second device corresponding to the first permission settings for each of the plurality of devices.

This may facilitate and/or improve security operation in a network wherein group-based access permission techniques are used. In particular, it can allow group-based access security to be implemented without the use of explicit group certificates.

In accordance with an optional feature of the invention, the network is a Universal Plug and Play (UPnP) network, the first device is a Control Point, the second device is a Device and the apparatus is a Security Console.

The invention may allow particularly advantageous security performance and/or implementation for a UPnP network.

In accordance with another aspect of the invention, a network comprises: at least a first and a second device; a control device comprising: group means for determining permission settings for at least one authorization group of a plurality of authorization groups for a plurality of devices, storage means for storing the permission settings, means for receiving an access permission request for a first device accessing a second device, means for associating the first device with a first group of the at least one authorization group in response to a user input, means for determining first permission settings for the first device accessing the second device by retrieving the permission settings for the first group from the storage means, and communicating means for communicating the first permission settings to the second device, and wherein the second device comprises means for controlling access from the first device in accordance with the first permission settings.

In accordance with another aspect of the invention, a method of controlling access to devices of a network comprises the steps of: determining permission settings for at least one authorization group of a plurality of authorization groups for a plurality of devices; storing the permission settings; receiving an access permission request for a first device accessing a second device; associating the first device with a first group of the at least one authorization group in response to a user input; determining first permission settings for the first device accessing the second device by retrieving the stored permission settings for the first group; and communicating the first permission settings to the second device.

These and other aspects, features and advantages of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter.

Embodiments of the invention will be described, by way of example only, with reference to the drawings, in which

Fig. 1 illustrates an example of a UPnP network in accordance with some embodiments of the invention;

Fig. 2 illustrates an example of an access configuration model for a UPnP network;

Fig. 3 illustrates an example of a Security Console in accordance with some embodiments of the invention;

Fig. 4 illustrates an example of an access configuration model in accordance with some embodiments of the invention.

The following description focuses on embodiments of the invention that are applicable to a wireless local area network and in particular to a Universal Plug and Play (UPnP) network. However, it will be appreciated that the invention is not limited to this application but may be applied to many other networks.

Fig. 1 illustrates an example of a UPnP network 100 in accordance with some embodiments of the invention. In the example of Fig. 1, three Devices 101, 103, 105 are controlled by security console 107. A different device (a control point CP) 109 is seeking to access the first Device 101.

A UPnP network generally comprises a number of different devices which can communicate with each other, for example, via a radio air interface. In a UPnP network, security configurations are provided in order to allow some devices to access other devices. This access may be gained, for example, in order to retrieve data from the other device or to execute commands on the accessed device. In UPnP systems, a client/server approach is used and the entity providing a service is known as a Device, while the entity accessing the Device is known as a Control Point (CP).

The UPnP standards furthermore provide the existence of a device referred to as Security Console (SC). A Security Console can be a separate device or may be implemented together with functionality acting as a Device or a Control Point but is logically considered to be a separate entity. The purpose of a Security Console is to take security ownership of Devices and to control and manage the access permissions to the owned Devices. Specifically, the Security Console is responsible for authorizing Control Points and for determining the access rights of various Control Points to the Devices controlled by the specific Security Console.

It will be appreciated that, for the sake of brevity and clarity, only the elements of the UPnP network necessary for the following description are shown in Fig. 1, and that a typical UPnP network may comprise a large number of Devices, Control Points and Security Consoles.

A Security Console can own one or more Devices, which means that the Security console has a right to edit and modify the access permissions for the Control Point to the Device.

Specifically, a Device comprises an Access Control List (ACL) which comprises a number of entries. Each entry specifies a Control Point identity or Control Point group identity and contains the access permissions for that identity. Thus, when a Control Point accesses the Device, the Device looks for the corresponding Control Point identity in its access control list. If the identity is found, the requested access is compared with the access permissions for that entry and if a match is found, the Control Point is allowed access to the Device.

A Security Console which owns a Device is allowed to modify and edit the ACL of the owned Device. A Security Console generally has a user interface enabling a user to express his wishes regarding security definitions, including authorization/permission settings.

Thus, in UPnP, Control Points and Devices are components that can communicate via the network. Devices typically do not need to have their own user interface for the definition of authorization/permission. Authorization/permission settings are based on a positive granting model, meaning that permission cannot be denied explicitly; the only situation in which permission is not effective is when it is not granted. The user's wishes regarding the definition of authorization/permission in a conventional UPnP system can be represented in a user model as shown in Fig. 2. This model shows relevant entity types for which information is to be kept and manipulated. For brevity and clarity, the model does not illustrate all possible entity types.

A CP has a CP SecurityID that is globally unique. The CP provides this security ID to the SC when it contacts the SC. In UPnP, when a CP contacts a SC for the first time, the user of the SC investigates the authentication of the new CP. When accepted, trust is established and the user is offered the possibility to name the new CP giving it a CP Name. The CP Name given to a CP is only unique within the scope of one SC. The name is only used in the user interface so as to provide a more meaningful and user- friendly identification; however, the real authorization identification is based on the CP SecurityID.

The Device SecurityID and Device Name serve the same purpose for a Device as the CP SecurityID and the CP Name do for a CP. During the trust establishment phase, a SC might take ownership of a Device that is not yet owned by any SC. In this case, the SC must provide proof that it is allowed to become an owner of the Device. Once owner of a Device, a SC can grant co-ownership to other SCs.

Each Device keeps a set of permissions that are specific for the Device. These are stored in the ACL stored locally at the Device.

Apart from specific permission settings which are explicitly set for the Device, there is a generic access permission "ALL" that, when granted to a CP, represents all defined permissions. Specifically, the device manufacturer can decide what permission should be defined for the "ALL" category. This does not necessarily need to correspond to providing full access rights to the device. For example, the right to edit the ACL (which is an implicit right given to the Security Console that owns the device) does not necessarily need to be defined as permission and thus the 'ALL' permission typically does not include 'edit ACL' rights (and therefore does not imply full access). For each Device, a CP can be granted the "ALL" permission and zero or more Device-specific permissions. Device-specific permissions and the "ALL" permission can be granted to zero or more CPs.

In a UPnP system, the tasks of the user controlling security settings using a SC include:

1. Establishing trust for a CP;

2. Establishing trust for a Device;

3. Establishing trust of the Device for the SC in the case of taking ownership;

4. Defining authorization/permissions for CP and Device combinations. For security reasons, the first three tasks are generally based on explicit user interaction but tend to be not very cumbersome or complex. However, for conventional UPnP systems, the definition of permissions for individual CP and Device combinations tends to require significant effort and expertise by the user and is very complex and cumbersome., Typical users therefore tend to use default settings resulting in a reduced security of the system.

Fig. 3 illustrates an example of an SC 107 in accordance with some embodiments of the invention. The SC 107 provides a much facilitated security configuration by the users by allowing a group-based definition of permissions and allocation of permissions to individual CP and Device combinations.

Specifically, the SC 107 provides functionality for reducing configuration complexity and effort for a user by introducing the concept of authorization groups as illustrated in the authorization group model entity relationship diagram of Fig. 4.

In this model, one or more authorization groups can be defined by the user or are already predefined by the supplier of the SC 107. The group name of an authorization group uniquely identifies the authorization group within one SC 107.

In the basic concept model, permissions for Devices are granted to individual CPs. In contrast, for the authorization group approach, permissions are granted, in the user's view, to authorization groups. CPs can be made members of one or more authorization groups and an authorization group can contain multiple CPs.

In the system of Fig. 1, the SC 107 can thus detect a new CP 109 and, in response, it can request the user to associate this CP with one or more already existing authorization groups. When assigning the CP 109 to an authorization group, the SC 107 determines the permission settings for the CP 109 by retrieving already created permission settings for this authorization group. The permission settings for a CP can thus be determined merely by indicating an authorization group to which the CP belongs.

When the permission settings have been determined by the SC 107, it can proceed to download this information to the individual Device for which the permission settings are applicable. Indeed, the permission settings are applicable to a plurality of Devices 101-105 and can specifically be downloaded to all the Devices 101-105 that are controlled by the SC 107.

The permission settings can be downloaded by the SC 107 editing the ACL of the appropriate Devices 101-105 so as to include an entry for the CP 109 indicating the permissions determined for the CP 109. The CP 109 can then directly access the Device 101 and will be granted the access rights defined in the ACL entry.

The security console 107 comprises an authorization group processor 301 which is arranged to determine permission settings for an authorization group. The authorization group processor 301 is coupled to a user interface 303 which is arranged to interface with the user of the SC 107. The user interface 303 can display information to the user and receive selections from the user.

As a specific example of a possible user interface for defining authorization group permissions, the following Table may be presented to a user for a specific device (the Device may be, for example, a Television or sound system):

The user may define the authorization group permissions simply by ticking the appropriate boxes.

In this particular example, the user has previously defined the three authorization groups "Guests", "Family" and "Administrator". In addition, the pseudo-group "Any" is shown as a representative of any CP, trusted by the SC or not. A permission which is not granted and not effective is indicated by the absence of an "X". A permission which is granted explicitly by the user is indicated by an "X". Granting "All Permissions" ("ALL") for a group will effectively grant all the permissions for that group. Granting permission for the "Any" group will effectively grant the same permission for all the other groups, overruling user settings for the permission made for the other groups.

In the specific example, the authorization group "any" is thus only allowed to perform channel selection, the authorization group "Guests" can only change the volume, the authorization group "Family" can change both channels and volume, whereas the authorization group "Administrator" has "ALL" permission and can perform any operation including channel programming.

The user interface 303 thus provides the user input to the authorization group processor 301 which then sets the permissions for a given authorization group as requested by the user via the user interface 303.

The authorization group processor 301 is coupled to a storage 305 wherein the permission settings for the different authorization groups are stored. Specifically, data representing the settings indicated in the above Table is stored in the storage 305.

The SC 107 thus provides a very simple, efficient and user- friendly way of defining access permissions to Devices for different authorization groups.

It will be appreciated that the permission settings for the authorization groups can be determined additionally or alternatively by inputs other than user inputs. For example, in some embodiments, the permission settings for various authorization groups can be predefined alternatively or additionally by the manufacturer at the point of manufacture. As another example, in some embodiments, the Devices owned by a SC can upload a number of permission settings corresponding to different profiles. These profiles may be used to determine the corresponding authorization groups which inherit the permission settings indicated in the profiles.

The SC 107 furthermore comprises a transceiver 307 which is arranged to communicate with other devices via the radio air interface of the network.

The transceiver 307 is coupled to a receive processor 309 which is arranged to detect if an access permission request is received from another device. In the example, the CP 109 may thus transmit an access permission request to the SC 107 in order to gain access to the first Device 101. It will be appreciated that such an access permission request does not need to be transmitted for every access to the first Device 101 by the CP 109. Rather, the described system allows access permission to be determined once for the CP 109 and then downloaded to the first Device 101. Consequently, the CP 109 can access the first device 101 directly and the first device 101 can evaluate if the access by the CP 109 should be allowed or not. Thus, the system does not require the SC 107 to be continuously online. It will also be appreciated that the access permission request does not need to be received directly from the CP 109. For example, the access permission request for the CP 109 can be generated by the first Device 101 and transmitted from this Device to the SC 107. For example, the first time the CP 109 attempts to access the first Device 101, this Device can determine that it does not have an entry in the ACL for the CP 109 and it may accordingly proceed to generate an access permission request which identifies the CP 109. This request is then transmitted to the SC 107 which proceeds to determine the permission settings for the CP 109 and download these to the first Device 101. The first Device 101 can then apply these permission settings to the current access by the CP 109 as well as to any future accesses by the CP 109.

It will also be appreciated that the access permission request does not need to be an explicit request for access but may be an indication of a possibility of a future access. For example, the SC 107 can merely receive an indication that a new CP has joined the network and, in response to this detection of the new CP, it may proceed to determine permission settings and download these to Devices.

For example, in a UPnP system, a control point can simply make itself known to a security console by transmitting a message to the security console. This message will indicate to the security console that it is possible that the control point may desire to access a Device in the future. Accordingly, the security console may instigate the process of determining permissions for the Devices owned by it. In other words, the access permission request, specifically in a UPnP system, may be a message informing a security console of the existence or presence of a control point.

The receive processor 309 is coupled to a group processor 311 which proceeds to associate the CP 109 with at least one of the authorization groups. The group processor 311 is coupled to the user interface 303 and is arranged to associate the access-requesting device (in the specific example the CP 109) to a suitable authorization group depending on a user input.

Specifically, the user interface can simply present a list of previously defined authorization groups and the user can simply select one or more of these authorization groups for the CP 109 to belong to (or can decide not to grant membership to an authorization group). In the specific example, the user interface 303 can display a simple selection box such as:

The user can then simply select the authorization group by ticking the appropriate box. In the specific example above, the CP 109 is thus associated with both of the authorization groups "Guests" and "Family".

The group processor 311 is coupled to a permission processor 313 which is arranged to determine permission settings for the CP 109 in response to the selected authorization groups.

The permission processor 313 is coupled to the storage 305 and retrieves the stored permission settings for the selected authorization groups. In the specific example, the permission processor 313 thus retrieves the permission settings for the authorization groups "Guests" and "Family".

The permission processor 313 then proceeds to determine the appropriate permission settings for the CP 109. It will be appreciated that any suitable algorithm or criteria for determining the permission settings in response to the individual permission settings defined for the individual authorization groups can be used. As a simple example, the permission processor 313 can simply include all the permissions which are allocated to the individual authorization groups (e.g. it can perform an "or" operation on the individual permissions). In the specific example, the CP 109 will thus be granted permission to change the channels and the volume.

The permission processor 313 then proceeds to generate a message which represents the determined permission settings for the CP 109. Specifically, the permission processor 313 can generate an entry for an ACL (Access Control List). The entry will have the device identity of the CP 109 and will specify the permission settings determined by the permission processor 313.

The permission processor is coupled to a transmit processor 315 which is further coupled to the transceiver 307. The transmit processor 315 receives the message comprising the ACL entry and controls the transceiver 307 to transmit this message to the first Device 101. When the first Device 101 receives the permission settings for the CP 109, it proceeds to enter the ACL entry into its ACL. In this way, the first Device is configured in such a way that it can allow or deny future accesses from the CP 109. Subsequently, the interaction between the CP 109 and the first Device 101 can thus proceed without involvement of the SC 107.

Specifically, in the system, a security console can own a set of devices D_owned for which it manages permissions. Furthermore, a set of control points C_reg can register with the security console. The security console also administrates a set of authorization groups Grps. For each device D in D_owned and for each group G in Grps, the permissions P(D, G) are assigned. Each Control Point C in C_reg is assigned to a set of groups: A_SS(C).

The security console can specifically update the ACLs of the devices it manages in the following way:

1. For each device D in D_owned do

2. For each Control Point C in C_reg do

3. PermC = empty

4 For each group G in A_SS(C) do

PermC = PermC + P(D,G)

5 add (QPermC) to ACL of D

If a device is not online during this action, the communication can be delayed until the device comes online. In this case, the security console can remain online (or periodically come online) to set permissions.

It will be appreciated that, although the authorization group concept provides a very practical and user- friendly interface to the user, the access control authorization as administrated in a Device is still based on the SecurityID of the CP 109 or of the SC 107.

The described grouping concept ensures a high level of flexibility and efficient operation in many different scenarios.

For example, in a situation in which all trusted CPs are to be treated identically, only a single authorization group is required. This group does not need to be explicitly visible to the user. After trust for a new CP is established, it can automatically be added to the group without additional user intervention. Note that this is different from granting permission to the generic "ANY" access subject.

The authorization group processor 301 may also be arranged to divide an existing authorization group into different authorization groups. For example, if further differentiation is required between different control points belonging to the same authorization group, this group can be separated into two different groups. Each of these groups can initially have the same permission settings which can then be manually changed by the user to reflect the specific requirements for each group. Each control point of the original group can then be assigned to one of the two new groups.

In some embodiments, the authorization group processor 301 can also determine the permission settings for the authorization groups in response to a permission profile received from the controlled Devices 101-105. Specifically, a Device can provide a number of named profiles to a SC where the profile is a logical set of permissions that can be regarded as a role definition.

Matching can be done when authorization groups are classified and the profiles supplied by a Device are classified in a similar way, and permissions defined for a profile are automatically added to the authorization group having a classification that matches the classification of the profile.

In some embodiments, the SC 107 can be arranged to process group access permission requests which represent a group of device identities, i.e. a group access permission request relates to a plurality of control points for which access permissions are determined by the security console. In such embodiments, the security console can generate an entry of the ACL for each device identity. These ACL entries can then be downloaded to the Devices, resulting in the appropriate permissions for the authorization group associated with the devices that are configured in the Devices.

The authorization group definitions can be used specifically for Devices that support authorization based on group-type subjects. In this case, certificates claiming group membership can be routed via the involved CP to the Device. The permission-granting access control definition for the group is written directly into the device ACL or is routed in an authorization certificate via the involved CPs to the Device.

When group-type subjects and certificates are supported by a Device (and involved CPs), a choice can be made to realize the user's wishes using certificates via the CP route or to directly amend the ACL of the Device. In the former situation, the CPs and the SC must be online at the same time before the authorization settings become effective. In the latter situation, the Device and the CPs must be online at the same time before the authorization settings become effective.

In some embodiments, the SC 107 comprises functionality for determining if the Device 101 to which the permission settings are to be downloaded is online. If not, the transmission of the permission settings can be delayed until the Device 101 comes online. More specifically, when a Device is not online, the SC 107 cannot update the ACL in the Device directly. Although this can be overcome by requiring all involved Devices to be online when the user changes authorization settings, this is not practical for systems with many Devices. For example, changes to an authorization group permission setting can affect a large number of Devices belonging to the authorization group, and requiring all of these to be online simultaneously is undesirable.

To prevent this, the CP can comprise a mechanism which postpones updates to the offline Devices until both the Device and the SC are online. In the meantime, the effective permissions on the Device do not conform to the user's preferences. This effect of being out of synchronization can be presented to the user of the SC (for example, by suggesting that the user switches on the Device).

To support this mechanism, the SC maintains a record of the synchronization state for involved Devices. Specifically, for every trusted Device, the SC stores a copy of the resulting state of authorization settings made on the Device by the SC itself.

When permission is to be added or removed, the change is applied to the Device and to the internal synchronization state administration in the SC. When the Device is not online, the task of updating the Device is stored in a ToDo list. When the Device comes online, the entries in the ToDo list are handled in the order of the entry creation time.

It will be appreciated that the described system can provide a number of advantages, including e.g.

Ease of Use: Whenever a CP joins the network (for example, owned by a visiting friend or relative), only one user action is required (e.g. simple selection or "dragging") to enable the CP for secure access to any home network device.

Instantaneous revocation of CPs when the security console so desires.

The security console is not required to be online for normal operation of CPs and Devices, it rather only needs to be online when permissions need to change.

Low user interface complexity because the number of authorization groups can be much lower than the number of CPs and devices.

Information hiding: Whenever a new CP joins the network and is made part of one or more authorization groups, the mapping of the group permissions to ACL entries on Devices (which is necessary as the permissions are checked at the Device using the ACL) happens automatically and is invisible to the user.

It will be appreciated that embodiments of the invention have been described hereinbefore with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units or processors may be used without detracting from the invention. For example, illustrated functionality to be performed by separate processors or controllers may be performed by the same processor or controllers. Hence, references to specific functional units are only to be considered as references to suitable means for providing the described functionality rather than being indicative of a strict logical or physical structure or organization.

The invention can be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may be optionally implemented at least partly as computer software running on one or more data processors and/or digital signal processors. The elements and components of embodiments of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the invention may be implemented in a single unit or may be physically and functionally distributed between different units and processors.

Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art will recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, use of the verb "comprise" and its conjugations does not exclude the presence of other elements or steps.

Furthermore, although individually mentioned, a plurality of means, elements or method steps may be implemented by e.g. a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be combined advantageously, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also the inclusion of a feature in one category of claims does not imply a limitation to this category but rather indicates that the feature is equally applicable to other claim categories as appropriate. Furthermore, the order of features in the claims does not imply any specific order in which the features must be worked, and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to "a", "an", "first", "second", etc. do not preclude a plurality. Reference signs in the claims are provided merely as a clarifying example and shall not be construed as limiting the scope of the claims in any way.

Claims

CLAIMS:

1. An apparatus for controlling access to devices of a network, the apparatus comprising: group means (301) for determining permission settings for at least one authorization group of a plurality of authorization groups for a plurality of devices; storage means (305) for storing the permission settings; means (309) for receiving an access permission request for a first device (109) accessing a second device (101); means (311) for associating the first device (109) with a first group of the at least one authorization group in response to a user input; means (313) for determining first permission settings for the first device (109) accessing the second device (101) by retrieving the permission settings for the first group from the storage means; and communicating means (315) for communicating the first permission settings to the second device.

2. The apparatus of claim 1, wherein the group means (301) is arranged to determine the permission settings in response to a user input.

3. The apparatus of claim 1, wherein the group means (301) is arranged to determine the permission settings in response to a permission profile received from the second device (101).

4. The apparatus of claim 1, wherein the communicating means (315) is arranged to generate an entry for the first device (109) for an access control list of the second device (101) in response to the first permission settings and to communicate the entry to the second device (101).

5. The apparatus of claim 1, further comprising means for dividing the at least one authorization group into a plurality of authorization groups in response to a user input.

6. The apparatus of claim 1, wherein the communicating means (315) is arranged to determine if the second device (101) is available and, if not, to delay communication of the first permission settings until the second device (101) is available.

7. The apparatus of claim 6, wherein the apparatus comprises means for storing a synchronization state for each device associated with the apparatus, the synchronization state being indicative of whether any communications of permission settings are pending.

8. The apparatus of claim 6, comprising means for indicating to a user of the apparatus that the communication of the first permission settings to the second device is pending.

9. The apparatus of claim 1, wherein the access permission request is a group access permission request for a plurality of devices for which permission is to be determined, and wherein the apparatus is arranged to generate an entry of an access control list of the second device (101) corresponding to the first permission settings for each of the plurality of devices.

10. An apparatus as claimed in claim 1, wherein the network is a Universal Plug and Play (UPnP) network, the first device (109) is a Control Point, the second device (101) is a Device and the apparatus is a Security Console.

11. A network comprising: at least a first and a second device (109, 101); and a control device (107) comprising: group means (301) for determining permission settings for at least one authorization group of a plurality of authorization groups for a plurality of devices, storage means (305) for storing the permission settings, means (309) for receiving an access permission request for a first device (109) accessing a second device (101), means (311) for associating the first device (109) with a first group of the at least one authorization group in response to a user input, means (313) for determining first permission settings for the first device (109) accessing the second device (101) by retrieving the permission settings for the first group from the storage means (305), and communicating means (315) for communicating the first permission settings to the second device (101), wherein the second device (101) comprises means for controlling access from the first device (109) in accordance with the first permission settings.

12. A method of controlling access to devices of a network, the method comprising the steps of: determining permission settings for at least one authorization group of a plurality of authorization groups for a plurality of devices; storing the permission settings; receiving an access permission request for a first device (109) accessing a second device (101); associating the first device (109) with a first group of the at least one authorization group in response to a user input; determining first permission settings for the first device (109) accessing the second device (101) by retrieving the stored permission settings for the first group; and communicating the first permission settings to the second device (101).