WO2010133908A1

WO2010133908A1 - Authorization system and methods

Info

Publication number: WO2010133908A1
Application number: PCT/IB2009/005653
Authority: WO
Inventors: Tibor Benyi; Peter Svensson; Andreas Cleverdal
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2009-05-19
Filing date: 2009-05-19
Publication date: 2010-11-25

Abstract

The present application discloses authorization systems and methods. In some embodiments, an authorization method includes the steps of: (1) transmitting to an LDAP server one or more search requests that cause the LDAP server to retrieve from a directory (i) the value of at least one authorization attribute of a user object stored in the directory that represents a user who desires to utilize a resource and (b) the value of at least one authorization attribute of a resource object stored in the directory that represents the resource; and (2) determining whether to allow the user to utilize the resource based on a response from the LDAP server to the one or more requests.

Description

AUTHORIZATION SYSTEM AND METHODS

TECHNICAL FIELD

[001] The present invention relates to systems and method for determining whether a user is authorized to utilize a resource (e.g., computer resource, communication resource, a person, or any other resource). In one aspect, an authorization system according to some embodiments of the invention utilizes an information directory to store authorization information for users and resources and a lightweight directory access protocol (LDAP) server with access to the information directory.

BACKGROUND

[002] Information directories are ideal repositories of information that does not need to be updated frequently. As such, authentication and authorization information are good candidates to store in an information directory. While authentication functions can be centralized relatively easily using LDAP, the same is not true for authorization functions because authorization is broader and more granular than authentication functions. Some proposals suggest employing the authorization mechanisms within LDAP to also authorize a user (a person or a device) to utilize (e.g., use, access, modify, communicate with) non-LDAP resources (e.g., a computer, a file, a database, a printer, a person). This is achieved by assigning a suitable LDAP Access Control List (ACL) to an LDAP object that represents the non- LDAP resource. For example, in order for a user to be able to utilize the non-LDAP resource, the ACL of the object that represents the non-LDAP resource must give the user the authorization to perform some action (e.g., read or write action) on the object. There are several problems to this approach of using LDAP as an authorization system. For instance, the authorization conditions are limited by the expressiveness of the ACLs offered by the particular LDAP server in use. Additionally, each administrator of a resource that is to be protected using the LDAP server must be granted the privilege to manage the ACL of the object that represents the resource. [003] What is desired are improved authorization systems and methods.

SUMMARY

[004] Aspects of the present invention provide for the central and generic representation, storage, management and distribution of authorization information using an LDAP server system (e.g., one or more LDAP servers) and an information directory. A system according to some embodiments of the invention includes an information directory that stores a set of user objects and a set of resource objects. Each user object represents a particular user and each resource object represents a particular resource (e.g., a laptop computer, a computer program, a file system, a computer file, a peripheral device). Additionally, each user object and each resource object includes at least one authorization attribute for storing authorization information. As used herein, "authorization information" includes any information that is used to determine whether a user is authorized to utilize a resource. Systems according to some embodiments also include an LDAP server system having access to the information directory and a set of authorization entities (AEs) capable of communicating with the LDAP server system, where each AE functions to protect one or more resources. That is, each AE is responsible for determining whether a user has the authority to utilize a resource protected by the AE. In some embodiments, the AE determines whether a user has the authority to utilize a resource by (1) transmitting to the LDAP server system one or more search requests that cause the LDAP server system to retrieve from the directory (a) the value of at least one authorization attribute of the user object representing the user and (b) the value of at least one authorization attribute of the resource object representing the resource and (2) using the one or more responses from the LDAP server system to determine whether the user has the authority to utilize the resource.

[005] There are several advantages provided by embodiments of the invention. For example, some embodiments of the invention provide a scalable, manageable and extensible authorization system.

[006] In one particular aspect, the invention provides an authorization method, hi some embodiments, this method is performed by an authorization entity (AE). The method may being with the AE receiving an indication that a user desires to utilize a resource, hi response to receiving the indication, the AE transmits to an LDAP server system one or more search requests that cause the LDAP server system to retrieve from an information directory (1) the value of at least one authorization attribute of a user object stored in the directory that represents the user and (2) the value of at least one authorization attribute of a resource object stored in the directory that represents the resource. After transmitting the one or more search requests to the LDAP server system, the AE determines whether to allow the user to utilize the resource based on a response received from the LDAP server system to the one or more requests. In this manner, a scalable, manageable and extensible authorization system can be implemented.

[007] Li some embodiments, the user is authenticated prior to the AE transmitting the one or more search requests to the LDAP server system. In other embodiments, the step of transmitting the one or more search requests includes transmitting, from the AE, a first search request to the LDAP server system to retrieve, at the least, the value of a password attribute of the user object representing the user. After transmitting the first search request, the AE receives from the LDAP server system a response that contains the value of the password attribute. Next, the AE authenticates the user based on the received value of the password attribute.

[ 008 ] In some embodiments, the step of transmitting the one or more search requests includes transmitting to the LDAP server system (1) a first search request that causes the LDAP server system to retrieve from the directory the value of at least one authorization attribute of the resource object that represents the resource and (2) a second search request that causes the LDAP server system to retrieve from the directory the value of at least one authorization attribute of the user object that represents the user. The AE will receive from the LDAP server system the retrieved values. The AE may be configured to compare the received values to see if there is a match.

[009] In other embodiments, the step of transmitting the one or more search requests includes transmitting to the LDAP server system (1) a first search request that causes the LDAP server system to retrieve from the directory the value an authorization attribute of the resource object that represents the resource and (2) a second search request. The second search request may include a filter comprising the value of the authorization attribute of the resource object that represents the resource. The second search request may also cause the LDAP server system to i) retrieve from the directory the value of an authorization attribute of the user object representing the user and ii) compare the value included in the filter of the second search request with the retrieved value of the authorization attribute of the user object representing the user to determine whether the user object representing the user matches the filter.

[0010] In some embodiments, the AE determines wither to allow the user to utilize the resource by determining whether the user object representing the user matched the filter. Preferably, the AE allows the user to utilize the resource if and only if the AE determines that the user object representing the user matched the filter. [0011] In another aspect, the present invention provides an improvded client processing device. In some embodiments, the improved client processing device includes transmit/receive (Tx/Rx) circuitry for transmitting data to and receiving data from an LDAP server system operable to retrieve data stored in a directory. The client processing device also includes a data processing system coupled to the Tx/Rx circuitry. Advantageously, the data processing system is configured such that, in response to receiving an indication that a user desires to utilize a resource, the data processing system performs at least two steps. First, the data processing system utilizes the Tx/Rx circuitry to transmit to the LDAP server system one or more search requests that cause the LDAP server system to retrieve from the directory the value of at least one authorization attribute of a user object stored in the directory that represents the user and the value of at least one authorization attribute of a resource object stored in the directory that represents the resource. Second, the data processing system determines whether to allow the user to utilize the resource based on a response from the LDAP server system to the one or more requests. [0012] The above and other aspects and embodiments are described below with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments of the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention, hi the drawings, like reference numbers indicate identical or functionally similar elements.

[0014] FIG. 1 illustrates a system according to some embodiments of the invention.

[ 0015 ] FIG. 2 is a flow chart illustrating a process according to some embodiments of the invention.

[0016] FIG. 3 is a flow chart illustrating a process according to some embodiments of the invention.

[0017] FIG. 4 is a flow chart illustrating a process according to some embodiments of the invention.

[0018] FIG. 5 is a functional block diagram of a processing device according to some embodiments of the invention. DETAILED DESCRIPTION

[0019] Referring now to FIG. 1 , FIG. 1 illustrates a system 100 according to some embodiments of the invention. As shown in FIG. 1, system 100 includes an information directory 116 storing a set of one or more user objects 122 and a set of one or more resource objects 124. Directory 116 may be a distributed directory. Each user object 122 represents a particular user (e.g., a particular person, device, application, or other resource), and each resource object 124 represents a particular resource (e.g., a laptop computer, a computer program, a file system, a computer file, a peripheral device, a person, a group, or other resource). Additionally, each user object 122 and each resource object 124 includes at least one authorization attribute for storing authorization information. As used herein, "authorization information" includes any information that is used by an authorization entity 104 ("AE") to determine whether a user is authorized to utilize (e.g., use, access, modify, communicate with) a resource. Table 1 below illustrates an exemplary user object 122.

TABLE l

Exemplary User Object dn: cn=Alice Cooper, ou=accounting, dc=company, dc=com en: Alice Cooper ou: accounting gn: Alice sn: Cooper uid: alice pwd: eiNTSEF3ck98349090sskfi899KK authz-hosts: Iaptop357 authz-hosts: Iaptop007 authz-hg: accounting [0020] As shown in Table 1 , the user object has a number of attributes. Of interest are the "authz-hosts" attribute and "authz-hg" attribute, hi this example, the "authz-hosts" attribute stores one or more values, where each value identifies a host that the user represented by this object has authorization to utilize, and the "authz-hg" attribute stores one or more values, where each value identifies group of hosts that the user represented by this object has authorization to utilize, hi this example, the user represented by the object shown in Table 1 is not only authorized to utilize hosts Iaptop357 and Iaptop007, but also any host that is a member of the "accounting" host group. This information in the authz-hg attribute could also be stored in the authz- hosts attribute so that the authz-hg attribute is not needed. [0021] Table 2 below illustrates an exemplary resource obj ect 124.

TABLE 2

Exemplary Resource Object dn: cn=laptopl2, ou=resource, dσ=company, dc=com en: laptop 12 ou: resource rt: host authz-hg: accounting

[ 0022 ] As shown in Table 2, the resource object has a number of attributes.

Of interest are the "en" attribute and "authz-hg" attribute. In this example, the "en" attribute stores a value identifying the name of the resource, and the "authz-hg" attribute store one or more values, where each value identifies a group to which the resource represented by this object belongs, hi this example, the resource represented by the object shown in Table 2 named "laptop 12" and is a member of the "accounting" host group.

[0023] Referring back to FIG. 1 , system 100 further includes a processing device 112 (e.g. computer server) and an LDAP server system 114 (i.e. one or more LDAP servers) running on one or more processing devices 112. For the sake of brevity, we shall refer to the "LDAP server system" simply as an "LDAP server." As shown, LDAP server 114 has access (e.g., read access) to information directory 116.

[0024] System 100 also includes one or more client processing devices 102a-

102n. A processing device 102 may be a computer (e.g., a laptop), printer (or other peripheral), a network node (e.g., a router, a gateway, a base station) or any other device that processes, receives or transmits data. Each client processing device 102 may include a set of one or more resources 106. A resource 106 may be a file, a file system, a database, a data record, an application, an operating system, a shell, a port, a processor or any other resource that a user may wish to utilize. A processing device 102 itself may be a resource 106. A person or group of people could also be a resource.

[0025] As also shown, each processing device 102 may include an AE 104 capable of communicating with LDAP server 114. AE 104 is an application that enforces authorization policies (e.g. it functions to protect one or more resources 106). For example, an AE 104 may receive an indication that a user would like to utilize a resource and then allows or does not allow the user to utilize the resource depending on whether the user is authorized to utilize the resource. As used herein, the term user is used broadly to include not only human users but also non-human users such as computer programs.

[0026] Advantageously, the AE 104 is configured to determine whether a user is authorized to utilize a resource by transmitting one or more search requests to LDAP server 114 and evaluating the response(s) from LDAP server 114 to the search request(s). A search request is request that causes LDAP server 114 to perform a search operation. More specifically, in some embodiments, AE 104 determines whether a user has the authority to utilize a resource by (1) transmitting to LDAP server 114 one or more search requests that cause LDAP server 114 retrieve from the directory 116 (a) the value of at least one authorization attribute of the user object 122 representing the user and (b) the value of at least one authorization attribute of the resource object 124 representing the resource and (2) using the one or more responses from LDAP server 114 to the one or more requests to determine whether the user has the authority to utilize the resource.

[0027] Referring now to FIG. 2, FIG. 2 is a flow chart illustrating a process

200 according to embodiments of the invention. Process 200 may begin in step 202, where, for each of a plurality of users, a directory administrator stores in directory 116 an object representing the user, where the object contains at least one authorization attribute storing authorization information. In step 204, for each of a plurality of resources, the directory administrator stores in directory 116 an object representing the resource, where the object contains at least one authorization attribute storing authorization information.

[0028] In step 206, an AE 104 receives an indication that one of the plurality of users desires to utilize one of the plurality of resources. This step may occur days or weeks after steps 202 and 204. For the sake of example, we will assume the user desires to utilize a particular computer. In step 208, after receiving the notification, the AE 104 transmits to LDAP server 114 a search request that identifies the object that represents the user. For example, the search request may include the directory name ("dn") of the object. In step 210, AE 104 receives a response from LDAP server 114. hi some embodiments, the response includes the value or values of an authorization attribute of the object that represents the user. Using the exemplary user object shown in Table 1, the response received in step 210 may include the values of the "authz-hosts" attribute, hi step 212, AE 104 uses the response received (e.g, the value of the hosts attribute) to allow or not allow the user to utilize the resource. For example, in step 212, AE 104 may compare the name of the resource that the user wishes to utilize to a value received from LDAP server 114 to determine if there is a match. If there is a match, then AE 104 should allow the user to utilize the resource. However, if the name of the resource does not match any value from the authorization attribute, then AE 104 should not allow the user to access the resource. It should be noted that steps 208-212 may occur before, during, or after authentication of the user and may be performed multiple times (e.g., periodically in case the user's authorization level changes after the user has been authorized initially.). [0029] Referring now to FIG. 3, FIG. 3 is a flow chart illustrating a process

300 according to embodiments of the invention. Steps 302-306 are the same as steps 202-206, respectively. In step 308, which may occur in response to receiving the indication that the user desires to utilize the resource, AE 104 determines whether the user is authenticated. For example, in step 308, AE 104 may request the user to input a password or other data (e.g., thumbprint) and then check whether the inputted data matches data stored in an authentication attribute (e.g., a password attribute) of the object that represents the user. IfAE 104 determines that the user is not authenticated, then AE 104 should not allow the user to utilize the resource. IfAE 104 determines that the user is authenticated, then AE 104 should take steps to determine whether the user is authorized to utilize the resource. [0030] In step 310, AE 104 transmits to LDAP server 114 a search request that identifies the object representing the user and receives a response. The search request causes LDAP server 114 to retrieve, at the least, a value of an authorization attribute of the object and provide the value to AE 104 in the response. In step 312, AE 104 transmits to LDAP server 114 a search request that identifies the object representing the resource and receives a response. The search request causes LDAP server 114 to retrieve, at the least, a value of an authorization attribute of the object and provide the value to AE 104 in the response. In some embodiments, steps 310 and 312 may occur before step 308.

[0031] In step 314, AE 104 uses the values received in steps 310 and 312 to determine whether the user is authorized to utilize the resource. For example, AE 104 may, among other things, compare a value received in step 310 with a value received in step 312 to determine whether there is a match.

[ 0032 ] Referring now to FIG. 4, FIG. 4 is a flow chart illustrating a process

400 according to embodiments of the invention. Steps 402-410 are the same as steps 302-310, respectively. In step 412, AE 104 transmits to LDAP server 114 a search request that identifies the object representing the user and contains a filter that identifies an authorization attribute of the object representing the user and includes, for example, a value received in step 410 (i.e., a value from an authorization attribute of the object representing the resource). The filter might be as simple as "authz- hosts=accounting" or it may be more complex, where the attribute "authz-hosts" is an authorization attribute of the object representing the user and the value "accounting" is a value of an authorization attribute of the object representing the resource. The LDAP server 114, in response to the search request, retrieves data from the object representing the user and compares the data to a value specified in the filter to see if the filter is satisfied. That is, using the above as an example, the LDAP server 114 determines whether the attribute "hosts" in the object representing the user contains the value "accounting." If the filter is satisfied, then the response to the search request from the LDAP server 114 will contain a value from an attribute, otherwise it will not contain any data from the object representing the user (i.e., it will be a "null" response). In step 414, AE 104 receives the response from LDAP server 114. If the response is a null response, then AE 104 will not allow the user to utilize the resource, otherwise it will allow the user to utilize the resource. [0033] Example 1

[0034] In this example, a user, Alice, is authorized to access the host named

"Iaptop357" (Alice's laptop) as well as all hosts belonging to the accounting department. Upon these hosts she is granted the role of a typical user, hi this simple example, the extent of authorization is based only on hosts, either a specific host or a member of a specific set of hosts, and the role granted to Alice upon those hosts, hi order for an AE 104 to allow Alice to utilize a host protected by the AE 104, the AE 104 must have access to a directory object that represents Alice and that contains the necessary authorization information. In this case, an administrator would need to add to directory 116 an object that represents Alice, and include in the object the appropriate authorization information, which in this case consists of information identifying the hosts that Alice is authorized to utilize and the role assigned to Alice on these hosts. Accordingly, in this example, the administrator adds two attributes to Alice's object: a "hosts" attribute and a "role" attribute. (Any choice meaningful to the administrators would do as long as it does not conflict with existing attribute names). The host attribute's type shall be a muti-valued string (e.g. IA5). For Alice it shall be assigned the values "Iaptop357" (representing Alice's laptop) and "accounting" (representing the set of hosts within the accounting department). For the role attribute it may be a single valued string and may be set to a value of "user". Using the Lightweight Directory Interchange Format (LDIF) the LDAP object representing Alice may be expressed as shown in Table 3 below.

TABLE 3

Alice's LDAP Object dn: cn=Alice Cooper, ou=accounting, dc=company, dc=com en: Alice Cooper ou: accounting gn: Alice sn: Cooper uid: alice pwd: eiNTSEF3ck98349090sskfi899KK hosts: Iaptop357 hosts: accounting role: user

[0035] It is the duty of a management system under the control of the administrator to add to Alice's object or remove from Alice's object values that appropriately symbolize Alice's authorizations. The degree of complexity is at the discretion of the system owners to decide.

[0036] During and/or after authentication of Alice, one or more AEs 104 will be called upon to enforce the authorizations granted to Alice. To do so, the AE 104 will need to retrieve the appropriate attributes from the appropriate object (i.e., an object representing Alice) stored in directory 116 using one or more LDAP queries. For example, an AE 104 that is responsible for authorizing logins to a host would, in this case, be configured to request to retrieve the values for the attribute "hosts". Likewise, the AE 104 responsible for granting authorizations based on Alice's role would inturn retrieve the role attribute value. In this case, the login AE 104 and the role enforcer AE 104 would most likely be one and the same and would retrieve the values for both attributes.

[0037] After retrieving the appropriate values from the appropriate obj ect in directory 116, the next step is for the AE 104 to enforce an authorization policy based on the values retrieved from directory 116. In this example, we will adopt the interpretation that Alice is considered to be authorized to login to a particular host if any value in the host attribute of Alice's directory object matches a pre-determined host identifier or group identifier associated with the particular host. Thus, a login AE 104 for a host named Iaptop357 would allow a user to login to the host if the value "Iaptop357" is found in the hosts attribute of the object corresponding to the user. Similarly, a login AE 104 for a host that is a member of the "accounting" group would allow a user to login to the host if the value "accounting" is found in the hosts attribute of the object corresponding to the user. [0038] The value "user" of the role attribute is a representation of the authorizations a typical user needs while logged in. The role AE initializes the appropriate data for it to enforce the appropriate more granular authorizations upon Alice. The role AE is an example where the set of acceptable values is decided by the designers of the AE and their meaning hard coded. The semantics of the login AE on the other hand must be configurable by the system owners depending on both their organizational structure and security policy for each host.

[0039] A crude implementation of the login AE might store locally the predetermined host identifier or pre-determined group identifier(s) associated with the particular host that the login AE is configured to protect. An alternative, as discussed above, is that the each resource (e.g., host) is also represented within LDAP by an object that includes one or more authorization attributes for storing the predetermined host identifier and pre-determined group identifier(s). As an example, the resource object for a host named "Iaptop357" that is a member of the "accounting" group may include the following: hn=laptop357 and hg=accounting. As also discussed above, the login AE may employ LDAP filters to refine LDAP searches. In the case of our login AE, the AE can offload the decision process onto LDAP by submitting to LDAP server 114 an LDAP query having a filter that instructs server 114 to compare the values of hosts attribute of Alice to values specified in the filter (e.g. the values stored in the "en" and "hg" attributes of the object corresponding to the host that Alice is attempting to login to). The query may request that no attributes are returned, merely whether a match was found or not. [0040] Example 2.

[0041] hi this example, Alice is a part time employee and is authorized to utilize her authorized hosts only during working hours (e.g. 9:00 to 17:00) on Mondays, Wednesdays and Fridays. One way to implement this security policy is to add additional authorization attributes to Alice's directory object. One possible implementation is the addition of the following three attributes: (1) authorizationLoginTimeOfDayStart,

(2) authorizationLoginTimeOfDayEnd, and (3) authorizationLoginDaysOfWeek. In this example, authorizationLoginTimeOfDayStart and authorizationLoginTimeOfDayEnd may be of type integer and represent the number of seconds since midnight with 0 = midnight. The attribute authorizationLoginDaysOfWeek may be a multi-valued string with the possible values of mon, tue, wed, thu, fri, sat and sun. For simplicity we will assume that logins are verified only at the time of login attempt and that users who remain logged in after 5pm are not logged out. In response to Alice attempting to login to a particular host, the login AE for the particular host may simply retrieve the values for these additional three attributes, determine the time of day, determined the day of the week, and then make a determination as to whether it should allow Alice to login or not. Alternatively, the AE it may formulate a more detailed query including the following filter: authorizationLoginDaysOfWeek = [today's day] && authorizationLoginTimeOfDayStart <= [num sec past midnight] && authorizationLoginDaysOfWeek <= [num sec past midnight], thereby off-loading the comparison tasks to the LDAP server 114. A successful match will result in the LDAP server 114 determining if the entity is authorized to login at this time.

[0042] Example 3

[0043] In this example, Alice' s company is introducing a finer grained security policy for application X (e.g., a word processing application) and Alice only has the authority to use application X to read documents up to Confidential, and print only Unclassified documents. The classifications adopted are the typical security classifications of Top Secret, Secret, Confidential, Restricted and Unclassified. One approach to implement such a security policy with the aid of LDAP would be the introduction of an extra attribute called authorizationsApplicationX. This attribute may be of type multi valued string. These attributes in the Alice's directory object would be assigned the values: authorizationApplicationX: read-confidential and authorizationApplicationX: print-unclassified. Another approach might be to have several attributes including authorizationApplicationXRead and authorizationApplicationXPrint. Each would be single values strings. In this alternative, Alice would be assigned: authorizationApplicationXRead: confidential authorizationApplicationXPrint: unclassified.

[0044] Example 4

[ 0045 ] In this example, Alice is allowed to send e-mails to only other members of the accounting organizational unit. One approach to implement such a security policy with the aid of LDAP would be to add to each person's object an authorization attribute that lists the organizational units to which that person may send an e-mail. Such an attribute may be called "authz-e-mailgroups". In this example, such an attribute in Alice's object would have the value "accounting". If Alice desired to send an e-mail to person X, the appropriate AE could use the LDAP server to determine the organizational unit to which person X belongs by, for example, retrieving the "ou" attribute from the object for person X, and then compare that value to the value(s) stored in the authz-e-mailgroups attribute of Alice's object. In this example, Alice is the "user" and "person X" is the resource. [0046] Referring now to FIG. 5, FIG. 5 is a functional block diagram of a client processing device 102 according to some embodiments of the invention. As shown, client processing device 102 may comprise a data processing system 502 (e.g., one or more microprocessors, one or more integrated circuits, such as application specific integrated circuits, one or more controllers, etc. and any combination thereof), a data storage system 506 (e.g., one or more non- volatile storage devices) and computer software 508 stored on the storage system 506 for implementing an AE 104. Configuration parameters 510 may also be stored in storage system 506. Client processing device 102 also includes transmit/receive (Tx/Rx) circuitry 504 for transmitting data to and receiving data from LDAP server 114. Software 508 is configured such that when processor 502 executes software 508, client processing device 102 performs steps described above (e.g. step described above with reference to the flow charts of figures 2-4). For example, software 508 may include: (1) computer instructions for transmitting to the LDAP server 114 one or more search requests that cause the LDAP server to retrieve from the directory (a) the value of at least one authorization attribute of a user object stored in the directory that represents a user who desires to utilize a resource and (b) the value of at least one authorization attribute of a resource object stored in the directory that represents the resource; and (2) computer instructions for determining whether to allow the user to utilize the resource based on the response(s) from the LDAP server to the one or more requests. [0047] While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments.

[0048] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

Claims

1. In an environment comprising a first processing device (102a) comprising an authorization entity (AE) (104a) and an LDAP server system (114) for providing access to a directory (116), a method comprising:

A) receiving, at the AE, an indication that a user desires to utilize a resource (106); and

B) in response to receiving the indication, performing the steps of:

Bl) transmitting, from the AE, to the LDAP server system one or more search requests that cause the LDAP server system to retrieve from the directory 1) the value of at least one authorization attribute of a user object (122) stored in the directory that represents the user and 2) the value of at least one authorization attribute of a resource object (124) stored in the directory that represents the resource; and

B2) determining, by the AE, whether to allow the user to utilize the resource, wherein the determination is based on a response from the LDAP server system to the one or more requests.

2. The method of claim 1 , wherein the user is authenticated prior to the AE performing steps Bl and B2.

3. The method of claim 1 , wherein step B 1 further comprises: prior to transmitting said one or more search requests, transmitting, from the AE, a first search request to the LDAP server system to retrieve, at the least, the value of a password attribute of the user object representing the user; receiving, at the AE, from the LDAP server system a response to the first search request, wherein the response contains the value of the password attribute; and authenticating, by the AE, the user based on the received value of the password attribute.

4. The method of any one of claims 1-3, wherein step Bl comprises: BIa) transmitting, from the AE, to the LDAP server system a search request that causes the LDAP server system to retrieve from the directory the value of at least one authorization attribute of the resource object that represents the resource;

BIb) receiving, at the AE, the value of the authorization attribute representing the resource;

BIc) transmitting, from the AE, to the LDAP server system a search request that causes the LDAP server system to retrieve from the directory the value of at least one authorization attribute of the user object that represents the user; and

Bid) receiving, at the AE, the value of the authorization attribute representing the user.

5. The method of claim 4, wherein step B2 comprises comparing the value received in step BIb with the value received in step Bid.

6. The method of any one of claims 1 -3 , wherein step B 1 comprises: BIa) transmitting, from the AE, to the LDAP server system a search request that causes the LDAP server system to retrieve from the directory the value of at least one authorization attribute of the resource object that represents the resource;

BIc) transmitting, from the AE, to the LDAP server system a search request that includes a filter comprising the value received in step BIb and causes the LDAP server system to i) retrieve from the directory the value of an authorization attribute of the user object representing the user and ii) compare the value included in the filter of the search request with the retrieved value of the authorization attribute of the user object representing the user to determine whether the user object representing the user matches the filter.

7. The method of claim 6, wherein step B2 comprises determining whether the user object representing the user matched the filter, and the AE allows the user to utilize the resource if and only if the AE determines that the user object representing the user matched the filter.

8. The method of any one of claims 1 -7, wherein the environment comprises a third processing device (102b) comprising a second authorization entity (AE) (104b), the third processing device is located remotely from the first processing device (102a) and the method further comprises:

A) receiving, at the second AE, an indication that a second user desires to utilize a second resource; and

B) in response to receiving the indication, performing the steps of:

Bl) transmitting, from the second AE, to the LDAP server system one or more search requests that cause the LDAP server system to retrieve from the directory 1) the value of at least one authorization attribute of a user object stored in the directory that represents the second user and 2) the value of at least one authorization attribute of a resource object stored in the directory that represents the second resource; and

B2) based on the responses from the LDAP server system to the one or more requests determining by the second AE whether to allow the second user to utilize the second resource.

9. The method of any one of claims 1-8, further comprising adding a second authorization attribute to the user object representing the user.

10. The method of any one of claims 1 -9, wherein the LDAP server system comprises at least one LDAP sever.

11. A client processing device (102), comprising: transmit/receive (Tx/Rx) circuitry (504) for transmitting data to and receiving data from an LDAP server system (114) operable to retrieve data stored in a directory (116); and a data processing system (502) coupled to the Tx/Rx circuitry, wherein the data processing system is configured such that, in response to receiving an indication that a user desires to utilize a resource (106), the data processing system:

A) utilizes the Tx/Rx circuitry to transmit to the LDAP server system one or more search requests that cause the LDAP server system to retrieve from the directory the value of at least one authorization attribute of a user object (122) stored in the directory that represents the user and the value of at least one authorization attribute of a resource object (124) stored in the directory that represents the resource; and B) determines whether to allow the user to utilize the resource based on a response from the LDAP server system to the one or more requests.

12. The client processing device of claim 11 , wherein the data processing system is configured to authenticate the user prior to performing steps A and B.

13. The client processing device of claim 1 , wherein the data processing system is configured such that, prior to transmitting said one or more search requests to the LDAP server system, the data processing system a) transmits a first search request to the LDAP server system to retrieve, at the least, the value of a password attribute of the user object representing the user and b) authenticates the user based on the data received from the LDAP server system as a result of the first search request.

14. The client processing device of any one of claims 11-13, wherein the data processing system is configured such that, in response to receiving the indication that the user desires to utilize the resource, the data processing system:

Al) transmits to the LDAP server system a search request that causes the LDAP server system to retrieve from the directory the value of at least one authorization attribute of the resource object that represents the resource; and

A2) transmits to the LDAP server system a search request that causes the LDAP server system to retrieve from the directory the value of at least one authorization attribute of the user object that represents the user.

15. The client processing device of claim 14, wherein the data processing system is configured to determine whether to allow the user to utilize the resource by comparing the value of said at least one authorization attribute of the resource object that represents the resource with the value of said at least one authorization attribute of the user object that represents the user.

16. The client processing device of any one of claims 11-13, wherein the data processing system is configured such that, in response to receiving the indication that the user desires to utilize the resource, the data processing system:

Al) transmits to the LDAP server system a first search request that causes the LDAP server system to retrieve from the directory the value of at least one authorization attribute of the resource object that represents the resource; and

A2) transmits to the LDAP server system a second search request, wherein the search request: includes a filter comprising the value of said at least one authorization attribute of the resource object that represents the resource, and causes the LDAP server system to i) retrieve from the directory the value of an authorization attribute of the user object representing the user and ii) compare the value included in the filter of the search request with the retrieved value of the authorization attribute of the user object representing the user to determine whether the user object representing the user matches the filter.

17. The client processing device of claim 16, wherein the data processing system is configured to determine whether to allow the user to utilize the resource by examining the response from the LDAP server system to the second search request to determine whether the user object representing the user matched the filter.