System and method for rule-based entitlements

Abstract

A system and method of authorization comprising associating at least one role with a resource, associating at least one capability with the at least one role, and determining whether to permit a resource operation based on the at least one capability.

Description

COPYRIGHT NOTICE

[0004] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE DISCLOSURE

[0005] The present invention disclosure relates to the field of user authorization and in particular, role-based entitlements.

BACKGROUND

[0006] Computer authorization systems are typically permission-based. Once a user is authorized, usually by entering a password, the user is assigned a fixed set of permissions that govern the user's access to resources in an enterprise application. For example, a user may have permission to modify computer files belonging to the accounting department, but not the human resources department. A user's role in an organization will change over time, however, as the user acquires new skills and responsibilities. Access to resources should be tailored to each user's particular circumstances. Accordingly, a user's permissions need to be modified in order to reflect new privileges. When the number of users is great, administering fine-grained details of each individual user's permissions can create significant administrative overhead. As a result, a user's static permissions may not change in step with the user's role in an organization. This problem is exacerbated if privileges are dependent on less tangible factors, such as the time of day or prevailing conditions of a computer network. What is needed is a flexible, rules-based approach to authorization that allows users to dynamically acquire different privileges as their roles change over time.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 is an illustration of a static authorization scheme.

[0008] FIG. 2 a is an illustration of a dynamic authorization scheme in accordance to one embodiment of the invention.

[0009] FIG. 2 b is the dynamic authorization scheme of FIG. 2a in a different state.

[0010] FIG. 3 is a system in accordance to one embodiment of the invention.

DETAILED DESCRIPTION

[0011] The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.

[0012] In one embodiment, a resource operation request is sent from a client process (or client) to resource process (or resource). A client can be a task or process through which a user interacts with a resource (e.g., a web browser), or it may simply be an autonomous task or process. A resource is any part of a computer network that can be assigned permissions. For example, a resource can be data, a file, a database, a portion of a database, an object, an operating system resource, an administrative task, a graphical user interface, a process, a thread, a Java™ application, a Java™ applet, a Java™ servlet, or a Java™ Enterprise Bean. Java™ is an objected-oriented programming language and run-time environment available from Sun Microsystems, Inc. of Palo Alto, Calif. An access control mechanism intercepts the resource operation sent by the client to the resource and determines if it is permitted based on the client's entitlements. An entitlement is a business rule that grants or denies access to a resource. In one embodiment, determination of entitlements consists of dynamically associating roles with the client based on rules that take into account information about the client, information about the client's communication session, or the current state of the system. Roles are used to determine which operations the client is permitted to perform on a resource. In one embodiment, if one of the permitted operations matches the requested operation, the client is entitled to perform that operation.

[0013] In another embodiment, resources can be associated with portals. A portal is a feature-rich web site. It provides a point of access to enterprise data and applications, presenting a unified and personalized view of that information to employees, customers and business partners. Portals allow multiple web applications within a single web interface. In addition to regular web content that appears in a portal (e.g., text or graphics), portals provide the ability to display portlets—self-contained applications or content—all in a single web interface. Portals also support multiple pages with tab-based navigation, with each page containing its own content and portlets. One such system is the WebLogic Portal™, available from BEA Systems, Inc. of San Jose, Calif.

[0014] In one embodiment, clients can belong to one or more portal groups. Roles are used to dynamically determine which portal groups a client belongs to. Portal groups provide a means for organizing users with common characteristics into a single category. Portal groups also allow for the definition of different views of a portal for different portal groups, making it seem as if users in each group are looking at completely different web sites.

[0015] FIG. 1 is an illustration of an authorization scheme which utilizes static permissions. Client 1 can access resources A-C according to a fixed set of permissions. For example, resources A-C could be individual portlets on a single portal page. As illustrated in FIG. 1, client 1 can edit resource A, but can only view resource B, and has no access to resource C.

[0016] FIG. 2 a is an illustration of an authorization scheme in accordance with one embodiment of the invention. In FIG. 2a, client 1 attempts to edit resource C. The edit operation is intercepted by process 2 which dynamically determines, at that point in time, what resources client 1 may edit. Client 1 is then given permission to edit only those resources. In the current state of the system, client 1 can only edit resource A. Therefore, the edit operation fails.

[0017] FIG. 2 b is the authorization scheme of FIG. 2a in a different state. Again, client 1 attempts to edit resource C. The system is now in a different state and process 2 dynamically determines that client 1 can edit resources A and C, but not B. Therefore, the edit operation succeeds.

[0018] In one embodiment, to perform an operation on a resource, a client must be entitled to do so. An entitlement in one embodiment is a set of attributes: resource, role, capability, and permission. Given a resource, a role and a capability, a client can perform an operation on the resource corresponding to the capability if the permission allows it. Entitlements can be stored in database and retrieved or queried based on any of their attributes. In one embodiment, an administrative task can involve creating, removing, or modifying information pertaining to users in a system; creating, removing, or modifying attributes of portlets and portal pages; or altering the appearance and behavior of portlets and portal pages. In another embodiment, resource names can be organized in a taxonomy. A taxonomy provides a means of categorizing and uniquely identifying a resource and is hierarchical in nature. For example, a stock quote portlet “Quote” on the “web” portal page could be:

[0019] (1) myPortal/stockBroker/quotePortlet

[0020] In example (1), “myPortal” is the top level taxonomy name and serves to indicate that the resource is a portal named “myPortal”. The next part of the resource name, “stockBroker”, identifies a portal group within the portal “myPortal” consisting of stockbrokers. The third part of the resource name indicates a portlet “quotePortlet” for the portal group “stockBroker”. Thus, the resource name in (1) identifies a portlet “quotePortlet” within the portal group “stockbroker” and within portal “myPortal”.

[0021] In yet another embodiment, resources can be organized into resource groups wherein a single resource group name can represent a collection of resources. An entitlement specifying a resource group, rather than a single resource, can be extended such that the capability and permission attributes would apply to all resources referred to by the resource group name. If a resource operation specifies a resource rather than a resource group, the resource can be mapped to a resource group before determining which entitlements are applicable to the operation. Resource group names could likewise be organized in a taxonomy.

[0022] In one embodiment, a role is defined in terms of a rule comprised of one or more logical expressions. In another embodiment, a role rule can be based on evaluation of predicates. A predicate is a rule that evaluates to true or false. By way of a non-limiting example, predicates may include other predicates, logical operators (e.g., AND, NOT and OR), mathematical operations, method calls, calls to external systems, function calls, etc. In another embodiment, rules can be specified in plain English. For example:

[0023] (2) When all of these conditions apply, the client is an

[0024] ExperiencedJavaDeveloper:

[0025] Developer is equal to true

[0026] Skill level is equal to ‘High’

[0027] Preferred language is equal to ‘Java’

[0028] In example (2) above, the role that is being determined is “ExperiencedJavaDeveloper”. The predicate “Developer” may evaluate to true when, for instance, information contained in a user profile indicates that the client is a user in the software development department of an organization. Likewise, the other predicates (“Skill level”, “Preferred language”) could similarly be evaluated using information from the user profile. In another embodiment, the predicate can be based on the evaluation of information about a client's session (e.g., the state of communication between the client and other processes in the system). In yet another embodiment, session information can include information about a client's pattern of interaction with a graphical user interface, such as a portlet. It will be apparent to those skilled in the art that a predicate can be based on any information, whether the information is associated with a particular client or not. For example:

[0029] (3) When all of these conditions apply, the client is a SystemAdministrator:

[0030] TimeofDay is between 12:00 am and 7:00 am

[0031] SystemLoad is ‘Low’

[0032] AdminSkillLevel is at least 5

[0033] In example (3), two predicates (“TimeofDay” and “SystemLoad”) are based on information unrelated to a particular client. In this example, a client is allowed to be a system administrator if it is the middle of the night, the system is not busy, and the client has level 5 administration skills.

[0034] In one embodiment, an entitlement's capability is a operation that can be performed for a given role and on a given resource. For example, if the resource is a portlet, the capability can be “show”, “edit”, or “remove”. These operations control whether the portlet is initially displayed for the client (“show”), whether the client can edit information displayed in the portlet (“edit”), and whether the client can hide a portlet window (“remove”). It will be apparent to one skilled in the art that the capability can be any that is feasible for a given resource. An entitlement's permission corresponds to the capability and indicates whether the capability for the given resource and role is granted, denied or abstained. If the permission is granted, the operation should be permitted on the resource. If the permission is denied, the operation should not be permitted. Finally, if the permission is abstain, then the operation is not explicitly granted or denied. It will be apparent to one skilled in the art that other permissions are possible.

[0035] FIG. 3 is a system in accordance with one embodiment of the invention. Client 1 initiates a resource operation directed to resource 3. Client 1 could be, for example, a user interacting with a portal in an attempt to edit information displayed in a portlet named “accountProfilePortlet”. This assumes that client 1 had permission to view the profile portlet in the first place. The resource operation is intercepted by access controller 2. In one embodiment, the resource operation can contain information about a user (e.g., a user identifier or a user profile, characteristics such as gender and age, etc.). In another embodiment, the resource operation can contain information about the session or a hypertext transfer protocol (“HTTP”) request. HTTP request information can pertain to character encoding, remote user, authorization scheme, content length, server port, context path, request URI, request method, scheme, servlet path, content type, remote host, request protocol, locale, server name, remote address, query string, path information, etc. In yet another embodiment, the resource operation can contain any other kind of information relevant to evaluating role rule predicates. Access controller 2 directs role mapper 5 to determine which roles correspond to client 1 at that point in time. Role mapper 5 uses role rules database 6 to dynamically determine which roles apply to the client. If no role is found, a default role of “everyone” is assumed. Suppose, for example, the following roles applied:

[0036] optionTrader

[0037] registeredUser

[0038] Access controller 2 would then direct the decision module 4 to find entitlements matching the roles and the resource. If one or more entitlements are found, decision module 4 uses the entitlements to determine if the operation is permitted for client 1. For example, assume the decision module found the following entitlements as shown in Table 1:

TABLE 1
Entitlements
Resource	Role	Capability	Permission
accountProfilePortlet	optionTrader	show	grant
accountProfilePortlet	optionTrader	edit	grant
accountProfilePortlet	registeredUser	edit	deny
accountProfilePortlet	optionTrader	show	grant
accountProfilePortlet	optionTrader	edit	grant
accountProfilePortlet	registeredUser	edit	deny
accountProfilePortlet	everyone	show	deny
accountProfilePortlet	everyone	edit	deny

[0039] In one embodiment, entitlements that have capabilities compatible with the requested operation are considered. In this case, there is a conflict between two roles. The role optionTrader allows editing of the accountProfilePortlet whereas the role registeredUser does not. (The default “everyone” roles are ignored in this case since other roles have been established.) In one embodiment, decision module 4 employs an optimistic access scheme by logically OR'ing the entitlements and would thus grant permission to edit the portlet. In another embodiment, decision module 4 logically AND's the entitlements and thus would deny permission to edit the portlet. In yet another embodiment, decision module 4 can use heuristics to determine the permission or rely on other modules to make the decision on its behalf.

[0040] In one embodiment, performance can be improved through caching techniques. For example, access controller 2 can cache recently determined roles for clients and thereby forgo utilization of role mapper 5. Of course, roles that are dependent on time-sensitive predicates would have to be reevaluated. Alternatively, role mapper 5 can do the same. Cached roles can automatically be removed from the cache through an aging process or when the cache is full. In another embodiment, access controller 2 or decision module 4 can cache recently determined entitlements. In this way, access controller 2 can forego utilizing role mapper 5 and decision module 4 when cached information is considered consistent with role rules and entitlements.

[0041] One embodiment maybe implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.

[0042] One embodiment includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the features presented herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

[0043] Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and user applications.

[0044] The foregoing description of the preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. Embodiments were chosen and described in order to best describe the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention, the various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.

Claims

1. A method of authorization, comprising: associating at least one role with a resource; associating at least one capability with the at least one role; and determining whether to permit a resource operation based on the at least one capability.

2. The method of claim 1 wherein: associating the at least one role is based on evaluating at least one role rule.

3. The method of claim 2 wherein: the at least one role rule is specified in plain language.

4. The method of claim 2 wherein: the at least one role rule includes at least one logical expression.

5. The method of claim 2 wherein: evaluating the at least one role rule utilizes at least one of user information, session information, and system information.

6. The method of claim 1 wherein: the at least one role is everyone.

7. The method of claim 1 wherein: the resource is one of a portal page, a portlet, and an administrative task.

8. The method of claim 1 wherein: the resource operation is one of show, edit and remove.

9. The method of claim 1 wherein: the resource is a resource group.

10. The method of claim 1 wherein: determining whether to permit the resource operation is based on an optimistic access scheme.

11. The method of claim 1 wherein: associating the at least one capability with the at least one role requires the capability and the resource operation to be compatible.

12. The method of claim 1 wherein: associating the at least one role with the resource includes retrieving the at least one role from a cache.

13. The method of claim 1 wherein: associating the at least one capability with the at least one role includes retrieving the at least one capability from a cache.

14. A method of authorization, comprising: intercepting a resource operation, the resource operation identifying a resource; associating at least one role with the resource; associating at least one capability with the at least one role; and allowing the resource operation if the resource operation is permitted based on the at least one capability.

15. The method of claim 14 wherein: associating the at least one role is based on evaluating at least one role rule.

16. The method of claim 15 wherein: the at least one role rule is specified in plain language.

17. The method of claim 15 wherein: the at least one role rule includes at least one logical expression.

18. The method of claim 15 wherein: evaluating the at least one role rule utilizes at least one of user information, session information, and system information.

19. The method of claim 14 wherein: the at least one role is everyone.

20. The method of claim 14 wherein: the resource is one of a portal page, a portlet, and an administrative task.

21. The method of claim 14 wherein: the resource operation is one of show, edit and remove.

22. The method of claim 14 wherein: the resource is a resource group.

23. The method of claim 14 wherein: determining whether to permit the resource operation is based on an optimistic access scheme.

24. The method of claim 14 wherein: associating the at least one capability with the at least one role requires the at least one capability and the resource operation to be compatible.

25. The method of claim 14 wherein: associating the at least one role with the resource includes retrieving the at least one role from a cache.

26. The method of claim 14 wherein: associating the at least one capability with the at least one role includes retrieving the at least one capability from a cache.

27. A method of authorization, comprising: sending a resource request from a client to an access controller, wherein the access controller associates at least one capability with the resource request; and sending an indication of whether the resource request is permitted from the access controller to the client based on the at least one capability; and wherein associating the at least one capability with the resource request includes associating at least one role with a resource identified in the resource request.

28. The method of claim 27 wherein: associating the at least one role is based on evaluating at least one role rule.

29. The method of claim 28 wherein: the at least one role rule is specified in plain language.

30. The method of claim 28 wherein: the at least one role rule includes at least one logical expression.

31. The method of claim 28 wherein: evaluating the at least one role rule utilizes at least one of user information, session information, and system information.

32. The method of claim 27 wherein: the at least one role is everyone.

33. The method of claim 27 wherein: the resource is one of a portal page, a portlet, and an administrative task.

34. The method of claim 27 wherein: the resource request includes a resource operation, wherein the resource operation is one of show, edit and remove.

35. The method of claim 27 wherein: the resource is a resource group.

36. The method of claim 27 wherein: determining whether to permit the resource request is based on an optimistic access scheme.

37. The method of claim 27 wherein: associating the at least one capability with the resource request requires the capability and the resource request to be compatible.

38. The method of claim 27 wherein: associating the at least one role with the resource includes retrieving the at least one role from a cache.

39. The method of claim 27 wherein: associating the at least one capability with the resource request includes retrieving the at least one capability from a cache.

40. A system for authorization, comprising: an access controller adapted to accept a resource operation from a client; a role mapper coupled to the access controller, the role mapper to associate at least one role with the client; and a decision module coupled to the access controller, to determine whether access to a resource specified in the resource operation is permitted based upon the at least one role.

41. The system of claim 40 wherein: associating the at least one role is based on evaluating at least one role rule.

42. The system of claim 41 wherein: the at least one role rule is specified in plain language.

43. The system of claim 41 wherein: the at least one role rule includes at least one logical expression.

44. The system of claim 41 wherein: evaluating the at least one role rule utilizes at least one of user information, session information, and system information.

45. The system of claim 40 wherein: the at least one role is everyone.

46. The system of claim 40 wherein: the resource is one of a portal page, a portlet, and an administrative task.

47. The system of claim 40 wherein: the resource operation is one of show, edit and remove.

48. The system of claim 40 wherein: the resource is a resource group.

49. The system of claim 40 wherein: determining whether to permit a resource operation is based on an optimistic access scheme.

50. The system of claim 40, further comprising: associating at least one capability with the at least one role; and wherein associating the at least one capability with the at least one role requires the capability and the resource operation to be compatible.

51. The system of claim 40 wherein: associating the at least one role with the client includes retrieving the at least one role from a cache.

52. The system of claim 50 wherein: associating the at least one capability with the at least one role includes retrieving the at least one capability from a cache.

53. A system for authorization, comprising: a client adapted to send a resource operation to an access controller; wherein the access controller is coupled to a role mapper, the role mapper to associate at least one role with a client; and wherein the access controller is coupled to an access decision module, the access decision module to determine whether access to a resource specified in the resource operation is permitted based upon the role at least one role.

54. The system of claim 53 wherein: associating the at least one role is based on evaluating at least one role rule.

55. The system of claim 54 wherein: the at least one role rule is specified in plain language.

56. The system of claim 54 wherein: the at least one role rule includes at least one logical expression.

57. The system of claim 54 wherein: evaluating the at least one role rule utilizes at least one of user information, session information, and system information.

58. The system of claim 53 wherein: the at least one role is everyone.

59. The system of claim 53 wherein: the resource is one of a portal page, a portlet, and an administrative task.

60. The system of claim 53 wherein: the resource operation is one of show, edit and remove.

61. The system of claim 53 wherein: the resource is a resource group.

62. The system of claim 53 wherein: determining whether to permit access to the resource is based on an optimistic access scheme.

63. The system of claim 53 further comprising: associating at least one capability with the at least one role; and wherein associating the at least one capability with the at least one role requires the capability and the resource operation to be compatible.

64. The system of claim 53 wherein: associating the at least one role with the client includes retrieving the at least one role from a cache.

65. The system of claim 63 wherein: associating the at least one capability with the at least one role includes retrieving the at least one capability from a cache.

66. A system for authorization, comprising: a client; an access controller to accept a resource operation from the client, wherein the resource operation identifies a resource; a role mapper coupled to the access controller, to associate at least one role with a client; and an access decision module coupled to the access controller, to determine whether access to a resource specified in the resource operation is permitted based upon the role at least one role.

67. The system of claim 66 wherein: associating the at least one role is based on evaluating at least one role rule.

68. The system of claim 67 wherein: the at least one role rule is specified in plain language.

69. The system of claim 67 wherein: the at least one role rule includes at least one logical expression.

70. The system of claim 67 wherein: evaluating the at least one role rule utilizes at least one of user information, session information, and system information.

71. The system of claim 66 wherein: the at least one role is everyone.

72. The system of claim 66 wherein: the resource is one of a portal page, a portlet, and an administrative task.

73. The system of claim 66 wherein: the resource operation is one of show, edit and remove.

74. The system of claim 66 wherein: the resource is a resource group.

75. The system of claim 66 wherein: determining whether to permit access to the resource is based on an optimistic access scheme.

76. The system of claim 40 further comprising: associating at least one capability with the at least one role; and wherein associating the at least one capability with the at least one role requires the capability and the resource operation to be compatible.

77. The system of claim 66 wherein: associating the at least one role with the client includes retrieving the at least one role from a cache.

78. The system of claim 76 wherein: associating the at least one capability with the at least one role includes retrieving the at least one capability from a cache.

79. A system for authorization, comprising: a means for associating at least one role with a resource; a means for associating at least one capability with the at least one role; and a means for determining whether to permit a resource operation based on the at least one capability.

80. The system of claim 79 wherein: associating the at least one role is based on evaluating at least one role rule.

81. The system of claim 80 wherein: the at least one role rule is specified in plain language.

82. The system of claim 80 wherein: the at least one role rule includes at least one logical expression.

83. The system of claim 80 wherein: evaluating the at least one role rule utilizes at least one of user information, session information, and system information.

84. The system of claim 79 wherein: the at least one role is everyone.

85. The system of claim 79 wherein: the resource is one of a portal page, a portlet, and an administrative task.

86. The system of claim 79 wherein: the resource operation is one of show, edit and remove.

87. The system of claim 79 wherein: the resource is a resource group.

88. The system of claim 79 wherein: determining whether to permit a resource operation is based on an optimistic access scheme.

89. The system of claim 79 wherein: associating the at least one capability with the at least one role requires the capability and the resource operation to be compatible.

90. The system of claim 79 wherein: associating the at least one role with the resource includes retrieving the at least one role from a cache.

91. The system of claim 79 wherein: associating the at least one capability with the at least one role includes retrieving the at least one capability from a cache.

92. A machine readable medium having instructions stored thereon that when executed by a processor cause a system to: associate at least one role with a resource; associate at least one capability with the at least one role; and determine whether to permit a resource operation based on the at least one capability.

93. The machine readable medium of claim 92 wherein: associating the at least one role is based on evaluating at least one role rule.

94. The machine readable medium of claim 93 wherein: the at least one role rule is specified in plain language.

95. The machine readable medium of claim 93 wherein: the at least one role rule includes at least one logical expression.

96. The machine readable medium of claim 93 wherein: evaluating the at least one role rule utilizes at least one of user information, session information, and system information.

97. The machine readable medium of claim 92 wherein: the at least one role is everyone.

98. The machine readable medium of claim 92 wherein: the resource is one of a portal page, a portlet, and an administrative task.

99. The machine readable medium of claim 92 wherein: the resource operation is one of show, edit and remove.

100. The machine readable medium of claim 92 wherein: the resource is a resource group.

101. The machine readable medium of claim 92 wherein: determining whether to permit the resource operation is based on an optimistic access scheme.

102. The machine readable medium of claim 92 wherein: associating the at least one capability with the at least one role requires the capability and the resource operation to be compatible.

103. The machine readable medium of claim 92 wherein: associating the at least one role with the resource includes retrieving the at least one role from a cache.

104. The machine readable medium of claim 92 wherein: associating the at least one capability with the at least one role includes retrieving the at least one capability from a cache.