|Publication number||US7865959 B1|
|Application number||US 10/084,880|
|Publication date||Jan 4, 2011|
|Filing date||Feb 27, 2002|
|Priority date||Feb 28, 2001|
|Also published as||US7440962|
|Publication number||084880, 10084880, US 7865959 B1, US 7865959B1, US-B1-7865959, US7865959 B1, US7865959B1|
|Original Assignee||Oracle International Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (44), Non-Patent Citations (13), Referenced by (20), Classifications (8), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present application claims the benefit of U.S. Provisional Application No. 60/272,521, filed on Feb. 28, 2001, which is hereby incorporated by reference in its entirety.
The present application is related to the following applications: U.S. application Ser. No. 09/974,085, filed on Oct. 9, 2001, entitled “Method and System for Management of Access Information”, U.S. application Ser. No. 10/084,881, filed on Feb. 27, 2002, entitled “Method and System for Implementing Current User Links”; and U.S. application Ser. No. 10/086,103, filed on Feb. 27, 2002, entitled “Method and System for Implementing Shared Schemas for Users in a Distributed Computer System.” The above identified applications are hereby incorporated by reference in their entireties, as if fully set forth herein.
The invention relates to computer systems, and more particularly, to a method and mechanism for managing access information in a distributed computing environment, such as a distributed database environment. Some of the tasks faced by an enterprise in managing user access and privileges include managing information about users, keeping user information current, and securing access to all the information in an enterprise. These tasks have become complex because of the increased use of technology and high user turnover in many enterprises. In addition, these tasks are also made more complex because each user may have multiple accounts and/or passwords on different network nodes. These numerous accounts are often in addition to any other operating systems based accounts possessed by the user. The effort of managing all this user information in numerous user accounts, which often contains duplicative information, leads to increased maintenance costs and decreased efficiencies.
Furthermore, the distributed nature of managing multiple user accounts leads to increased security risks. For example, whenever a user leaves a company or changes jobs, the user's account status and privileges should be changed the same day in order to guard against misuse of that user's accounts and privileges. However, in a large enterprise with numerous user accounts and passwords distributed over multiple databases, an administrator may not be able to make the timely changes required by good security practices.
Requiring a user to maintain multiple accounts on different network nodes may also create increased security risks. For example, if the user must maintain a password for each account, then the user is likely to use the same password for each of the distributed accounts. This creates a security risk since this same password information now exists in multiple account locations and the breach of that password security at one location creates a security problem at all locations, which is particularly troubling if some of the account locations have lower security precautions in place than other locations.
Accordingly, the present invention provides an improved method and system for managing access information for users and other entities in a distributed computing system. In an embodiment of the present invention, information relating to user access (e.g., name, authentication information, and user roles) is stored in a centralized directory. When the user connects to the database, the database looks up the necessary information about the user in the directory. In an embodiment, the present invention addresses the user, administrative, and security challenges described above by centralizing storage and management of user-related information in an LDAP-compliant directory service. When an employee changes jobs in such an environment, the administrator need only modify information in one location—the directory—to make effective changes in multiple databases and systems. This centralization lowers administrative costs and improves enterprise security. Further details of aspects, objects, and advantages of the invention are described below in the detailed description, drawings, and claims.
The accompanying drawings are included to provide a further understanding of the invention and, together with the Detailed Description, serve to explain the principles of the invention.
The present invention is directed to a method and mechanism for centralized management of access information in a computing system. Specific orderings and combinations of process actions and system components are described herein to illustrate the invention. It will, however, be evident that various modifications and changes may be made without departing from the spirit and scope of the invention. For example, the following explanation of the invention is made with respect to a distributed system comprising database nodes (also referred to as database servers or databases). However, the inventive concepts disclosed herein may be equally applied to other types of computing nodes. Thus, the specification and drawings are to be regarded in an illustrative rather than restrictive sense.
The directory information system 104 also maintains “authorization” information for each user. Authorization generally refers to the scope of privileges and roles assigned to a given user. Once a user has been successfully authenticated that user's authorization information is sent to the database for which access is sought. The authorization information determines the scope of access that is granted to the user.
Authorization and/or authentication information for users in the distributed computer system can be centrally stored and maintained in the directory information system 104. Hence, each individual database 108 and 110 is not required to locally maintain user account and access information. However, the present invention permits each local database to customize and define the exact amount, level, and scope of access that a user has in the local database based upon the centrally stored user authorization information. In effect, the present invention provides a method and mechanism for centralized management of user roles, but allows decentralized definitions of those user roles based upon the specific requirements of the local database systems.
Enterprise Users Roles and Domains
According to an embodiment, the present invention manages user access privileges to databases based upon a hierarchy of assigned “roles.” To illustrate,
The enterprise role hierarchy 300 includes a subtree for each “enterprise role” 304 and 306 defined in the enterprise domain. An enterprise role is a collection of global roles and associated users. As noted above, a global role is a set of defined privileges that is specific to a local database node. A user may be associated with an enterprise role, which assigns to that user the privileges defined by all the global roles contained within that enterprise role. Each enterprise role may be associated with multiple users. A user may be associated with multiple enterprise roles.
In the example enterprise domain 300 of
The second enterprise role 306 includes a single global role 318 for a set of privileges granted at database DB1. Users 314 and 316, Anne Smith and Tom Jones respectively, are associated with enterprise role 306. Thus, when either user Anne Smith 314 or Tom Jones 316 accesses database DB1, the privileges granted by global role 318 are given to that user based upon the user's association with enterprise role 306.
Note that neither enterprise role 304 nor enterprise role 306 provides user Tom Jones 316 with any privileges at database DB2. Enterprise role 304 includes a global role 312 for database DB2, but user Tom Jones 316 has not been associated with this enterprise role 304. User Tom Jones 316 is associated with enterprise role 306, but this enterprise role does not include a global role for database DB2. Thus, even if user Tom Jones 316 is authenticated for access to database DB2, this user does not obtain any privileges or roles at that database unless such privileges and roles are locally defined outside of the enterprise roles.
According to an embodiment of the invention, a database obtains a user's global roles when the user logs in. If a user's global roles change, those changes do not take effect until the next time the user logs in. More details regarding the process for logging in is described below.
Centralized Directory Information System
According to an embodiment of the invention, the relationships between users and their associated roles in an enterprise domain structure are maintained as a hierarchy of objects in a directory information system. A directory in a directory information system can be considered an index to organized information. The directory lists objects, e.g., people and organizations, and gives details about each object. In a computerized environment, a directory is a database that stores collections of information about objects. The information in such a directory might represent any resource that require management—for example, employee names, titles, and security credentials, information about e-commerce partners, or about shared network resources such as conference rooms and printers.
A common directory information system is a directory based on the Lightweight Directory Access Protocol (“LDAP”). LDAP is a directory protocol that was developed at the University of Michigan, originally as a front end to access directory systems organized under the X.500 standard for open electronic directories (which was originally promulgated by the Comite Consultatif International de telephone et Telegraphe “CCITT” in 1988). Standalone LDAP server implementations are now commonly available to store and maintain directory information. Further details of the LDAP directory protocol can be located at the LDAP-devoted website maintained by the University of Michigan at http://www.umich.edu/˜dirsvcs/ldap/, including the following documents (which are hereby incorporated by reference in their entirety): RFC-1777 Lightweight Directory Access Protocol; RFC-1558 A String Representation of LDAP Search Filters; RFC-1778 The String Representation of Standard Attribute Syntaxes; RFC-1779 A String Representation of Distinguished Names; RFC-1798 Connectionless LDAP; RFC-1823 The LDAP Application Program Interface; and, RFC-1959 An LDAP URL Format.
The present invention is described with reference to LDAP directories. LDAP directory systems are normally organized in a hierarchical structure having entries (i.e., objects) organized in the form of a tree, which is referred to as a directory information tree (EDIT”). The DIT is often organized to reflect political, geographic, or organizational boundaries. In an LDAP directory, each collection of information about an object is called an entry. A unique name or ID (which is commonly called a “distinguished name”) identifies each LDAP entry in the DIT. An LDAP entry is a collection of one or more entry attributes. Each entry attribute has a “type” and one or more “values.” Each entry belongs to one or more object classes. Entries that are members of the same object class share a common composition of possible entry attribute types.
Databases (and other LDAP clients) refer to entries in the directory information system to determine enterprise user authorization at login. In an embodiment, the enterprise domain is associated with at least two types of objects: enterprise role objects and mapping objects. Enterprise role objects contain information about roles in the computing system. Mapping object contains mapping information between a full or partial distinguished name (“DN”) in the directory information system and a user/schema name. Mapping objects are normally created for a particular domain. Mapping objects also reside under server objects, and are created for a particular database.
As noted above, each entry in an LDAP directory is uniquely identified by a distinguished name (DN). The distinguished name identifies where the entry resides in the directory's hierarchy. The directory hierarchy can often be represented in a tree structure, referred to as a directory information tree (DIT). An example of a DIT 200 is shown in
In an embodiment of the invention, one or more administrative contexts are created in the directory to store enterprise information. The administrative context is created by an entity having suitable access permissions in the directory on a particular administrative context. For example, the person trying to create a new Context in “c=uk,o=acme” would need suitable permissions on that entry. The administrative context is created directly underneath, so that the root of the administrative context is
Any number of contexts may be suitably employed in the directory. Examples of contexts used in embodiments of the invention are user-defined contexts and root context. The root context sits at the root of the directory tree. In the preferred embodiment, there exists one root context, but there may be any number of user-defined contexts in a directory. A user-defined Context is created by an entity with access permissions in the directory on a particular administrative context. In an embodiment, the context includes the attribute names that will hold a nickname attribute and the user search base. The default for the Nickname Attribute in one approach is CN and the default for User Search Base is the root of the DIT or the parent of the administrative context.
An enterprise domain object, which may also be referred to as a RDBMS (relational database management system) Enterprise Domain object, is an object class that is employed in embodiments of the invention. In an embodiment, objects in this class maintain the enterprise domain name (RDN) and the list of RDBMS servers participating in the enterprise domain. Note that other types of database management systems may also be employed with the present invention (e.g., object-based databases), and thus the invention is not limited to relational databases. Enterprise domain objects may also track the global users participating in the respective domains. The list of users can have either user names or group names. The list of users defines the global users set. This object class may also include a list of accepted authentication types for databases in the domain, such as password, SSL, and/or ALL.
A server object, which can also be referred to as a RDBMS Server Object, is another object class that is employed in embodiments of the invention to identify database servers in the enterprise domain. Objects in this class may include attributes that identify the server name (RDN), server global name, server certificate, directory password, and a list of trusted users permitted for direct links between servers without authentication. According to an embodiment, the server object exists directly under the cn=AdminContext object, but it may also be located elsewhere. The server object may include other attributes, such as additional attributes for storing information regarding network aliases, server certificates, and listener information.
The enterprise role object is another object usable in the invention, which corresponds to the set of global roles that are assigned to an enterprise role. Enterprise roles may also contain other enterprise roles. This object may also contain the list of users to whom these roles are assigned. According to an embodiment, the enterprise role entries exist under the enterprise domain entry. Enterprise roles contain server global roles and may contain enterprise roles in a recursive manner. The enterprise roles can be assigned to users. The role assignees can be user groups also. The user group is useful for mapping defined group concepts for role assignment. The user's X.500 distinguished name, which is used for authentication using SSL, is an item of information used for role assignment in the enterprise role object. In an alternate embodiment, SSL is not employed and this information is not based in the DN.
An enterprise role comprises server global roles in an embodiment, and may contain enterprise roles in a recursive manner. This object class may include another object class for grouping users, so that users allocated this role will be represented as members of the group. The role assignees can be user groups also. The user group is useful for mapping OS defined group concept for role assignment, for example, the NT user groups. The user entry is preferably not modified for assigning roles. The user's X.500 distinguished name, which is used for authentication using SSL, is an item of information used for role assignment in the enterprise role object in one embodiment. In an embodiment, the enterprise role will contain the following information: (a) Zero or more global roles; (b) Zero or more enterprise roles; and (c) List of users to whom the enterprise role has been assigned.
The User Object is another object class that may be employed in embodiments of the invention. In an embodiment, users who intend to make use of the security framework of the invention are associated with a globally unique name, e.g., X.500 Distinguished Name. In one embodiment, this name is used when roles are assigned to these users. As noted above, the user entry is preferably not modified for assigning roles. Other user information, e.g., unique user information such as a global user ID, may also be employed when assigning roles.
Mapping objects comprise another object class useable in the invention. As described in more detail below, these objects are used for schema assignments, to map enterprise users to local database schemas. The mapping object contains the mapping of an enterprise DN and a native database username. According to an embodiment, the mapping object exists as a child of a server object or of an enterprise domain object. In an embodiment, the mapping object is a group object, where the CN attribute reflects the schema name and the members attribute contains all users who map to that schema. In an alternate embodiment, the mapping object is not a group object, where a native user attribute reflects the schema name and a distinguished name attribute contains the user identification that maps to a schema. An entry level mapping object according to an embodiment is an objectclass that contains a single mapping represented as two attributes: a full DN for an Enterprise User and a native username. A subtree-level mapping object is an objectclass that contains a single mapping represented as two attributes, e.g., a DN that does not necessarily represent an Enterprise User, and a native username. Only users under that DN in the directory tree will be mapped to the specified native user. If the DN itself is a user, then that user is not mapped to the native user. A full DN preferably takes precedence over a partial DN, and a mapping under the server takes precedence over one under that server's enterprise domain.
Other and additional object classes or combinations of object classes may be employed within the scope of the invention. For example, an application context is another object that can be used in the invention that contains a value for an application context attribute. This object may include information such user title, job description, task within this application, etc. The application context entry can exist in the subtree of an enterprise domain. Under the application context container object could be another container object representing an application context namespace, and under that another container representing an application context attribute name. At the bottom of these entries could be entries representing application context values. Each of these value entries will include the list of users who have been allocated this value. One reason to use an application context container is to avoid namespace overlap between context names and enterprise role names. Another example object class is for administration groups, which as explained in more detail below, support access control on entries in the directory. An exemplary approach for managing attribute information is disclosed in co-pending U.S. application Ser. No. 09/974,085, filed on Oct. 9, 2001, which is hereby incorporated by reference in its entirety.
One or more naming contexts can be chosen to contain enterprise information. To illustrate, shown in
According to an embodiment, enterprise domain information is represented in the LDAP directory by adding one or more enterprise domain objects 213 in the subtree beneath the security container object 211. For the purposes of illustration, the enterprise domain object 213 in
Any enterprise roles associated with enterprise domain 300 would be represented as enterprise role objects in the subtree beneath enterprise domain object 213. Thus, enterprise role object 219 in the subtree beneath enterprise domain object 213 represents enterprise role 304 of
Any enterprise domain structure can be mapped into an LDAP directory tree by adding one or more entries corresponding to the enterprise entity being mapped. While the above description of the embodiment shown in
The subtree under the administrative context 205 can also include other objects representing other entities in a computer system, such as server and network entities. For example, the administrative context may include a database server object. In the example of
Access to enterprise domain, enterprise role and the RDBMS server object entries should be properly managed for security access reasons. Thus, permission to create, delete or modify enterprise domain and the enterprise role object entries should be granted only to authorized enterprise domain administrators.
Access control lists (“ACLs”) are employed in one embodiment to control access to enterprise objects. When administrative operations are attempted within a directory, the directory server checks the enterprise ACLs to ensure that the user has the required permissions to perform those operations. Otherwise, the operation is disallowed. Thus, ACLs in the directory protect directory data from unauthorized operations by directory users. According to an embodiment, ACLs may be assigned to an entire group of administrators. For an LDAP directory, this is accomplished by defining group objects whose membership will be a list of user DNs. The Enterprise Domain and the subtree under it (for enterprise roles) will use the same ACLs for the enterprise domain entry and the subtree. The server object may also be administered by a group of administrators although the membership of this group may be different from the membership of enterprise domain administrators. Some of the security-related directory objects that may be protected using ACLs are: (a) Databases; (b) Enterprise domains; (c) Default Domain; (d) Enterprise roles; (e) Administrative groups; (f) Database Level Mappings; and (g) Domain Level Mappings. For each object, the ACL limits who can create, modify, or read them. The Default Domain could be created by default at context creation and newly created databases can be automatically placed in this domain.
A variety of access control mechanisms may be employed in the invention to implement ACLs. A first approach uses access control points (“ACP”) to implement ACLs. In this approach, an entry in the directory may include one or more modifiable attributes that list users who have been assigned administrative privileges to that entry or its subtree. The access control attribute identifies the access control policies of its associated object. In addition, the access control attribute can be configured to identify access control policies for the object's subtree, which are descendants of the object, e.g., child entries.
The following are examples of two access control attributes that may be employed in the invention:
Consider if it is desired to grant a user administrative access to any object in the subtree beneath enterprise domain object 213 in the LDAP directory of
An ACI in an entry can reference any suitably recognized user or group in the system. If a given group is listed in an ACI, the privileges granted by that ACI can be associated with additional users by making those users members of the listed group. As such, another approach to implementing ACLs is by creating administrative groups in the LDAP directory that are associated with particular combinations of ACIs in the system. Administrative groups can be associated with ACIs defined at any level of the directory to provide associated members of that administrative group with administrative privileges over a particular subtree or subtree entry. The following are examples of administrative groups that may be employed in an embodiment of the invention:
To illustrate this aspect of the invention, consider again the process for granting a user administrative access to any object in the subtree beneath enterprise domain object 213 in the LDAP directory of
Therefore, it can be seen that access control can be given to a user directly using an ACI that lists the user and indirectly by listing a group for which the user is a member. All groups of users are preferably placed directly beneath the Administrative Context or under a groups container that sits beneath the Administrative Context.
According to an embodiment, ACLs are preferably defined at the following points in the LDAP directory: (a) Administrative Context; (b) Security container; (c) enterprise domain objects; (d) Enterprise Roles objects, although it is noted that enterprise role objects can be configured to inherit the ACL placed in its parent enterprise domain object; (e) Server Objects, which are the object classes to hold server information; (f) in the administrative groups themselves; and (g) root of user subtrees.
If the ACI attributes for the object do not provide sufficient privileges to the user for the desired access, then a determination is made whether there exists any parent entries in the directory that could be reviewed for the required ACI attribute entries (404). If so, then the procedure traverses upward along the directory tree to examine the ACI attributes for the parent entry (406). If the parent entry has an inheritable ACI granting sufficient privileges to the user, then the desired access is granted to the user (410). Otherwise, the determination of 404 is made regarding further parent entries in the directory. This continues until no further candidate ancestor entries exist in the directory (e.g., no further parent entries exists in the relevant administrative context), or until a threshold number of parent entries have been examined for the desired ACI values, or until an inheritable ACI attribute in an ancestor entry provides the desired access.
If there exists no ACI (entry level or inheritable) that provides the user with the desired access privileges, then a determination is made whether the user is a member of an administrative group that confers the requested access privileges (408). If so, then the user is granted the desired administrative access to the enterprise domain object (410). If not, then access is denied (412).
Example ACL Implementation
This section provides syntax examples for ACLs for an installation where the directory context (which in an embodiment is the parent entry of the Administrative Context or “AdminContext”) is represented as <DC>. DC could be any context in the directory; for example, it could be “c=uk,o=acme” in
For the administrative context (CN=AdminContext,<DC>), this first ACI sets the default privileges for the entire context, and it allows members of the Context administrative group full privileges on the context. Others will obtain browse permission only by default on the objects in the context. This ACI preferably resides at the administrative context.
This next ACI allows DB Creator and NetAdmin group members to add objects directly under the context root. DB creators use this set of privileges to create new database objects under the context root. Preferably, only DB creators can add database objects at this location. This ACI is an entry level ACI, so it is not inherited for objects in a subtree; therefore, DB creators cannot add objects lower down in the tree based upon this ACI. Note that it does not specify that others can browse in this ACI, or that DBSecurityAdmin group members have any privileges, because any accesses on this object that are unresolved by this ACI are referred to the inheritable ACI in the same object (listed above).
This next ACI allows Context administrative group members full permissions on all attributes in the context, and others read permissions on all attributes. This read permission is denied for others in places at lower levels.
The following ACIs are not on the administrative context entry. For a server object (shown as entry 291 in
Alternatively, the following ACI can be used to allow members of the DBAdmins group (entry 290 in
The following ACI can be used to provide members of the context admins group with full permissions via ACI inheritance from the Context object; members of the DB Security Admins group obtain full permissions explicitly at this level, and members of the DB creators group obtain browse permission at this level so that DB creators can put the newly registered DBs into the default domain. These ACIs are preferably on the security container entry.
For a default domain object (CN=DefaultDomain, CN=Security, CN=Products, CN=AdminContext, <DC>), the following ACI provides privileges for members of the DB creators group to read and modify the default domain object. Since it is not desired to grant privileges to modify the possible mappings underneath, an entry level ACI is used to grant write permission on this object only. The DB Creators' read permissions are inherited from the Security object above. Restrictions for other users are also inherited from the Security Container ACI. These ACIs are preferably on the default domain entry.
In addition, when a database is registered and becomes a member of this domain, the ACI should not only allow the database read access to the default domain, but also to any roles and mappings that are underneath it. It need not specify that the database cannot modify anything, because that restriction can be inherited from the Security object ACI. The following ACIs can be used when a database becomes a member of a domain and are preferably associated with the enterprise domain entry:
Alternatively, if the domain is defined as a group object, the database members of the domain are members of the group, such that the same security functionality can be obtained by adding that DB as a new uniquemember for the domain, and including the main itself (and therefore its uniquemembers) in its own ACI. The restriction that allows a DB from modifying the domain is inherited from the Security object ACI. The lowing ACIs are preferably associated with a domain entry:
When a new domain administrator is added, the following expanded ACI may be added to provide access:
Alternatively, the following ACI may be used for a domain to take advantage of the existence of a domain admins group:
When a new domain administrator is needed, the new administrator's DN can simply added as a new uniquemember to the Domain Admins group under the domain entry. Thus, the ACI in the domain entry need not be modified to add either new domain admins or new databases.
For members of the DB creators group (CN=DBCreators,CN=AdminContext, <DC>), the following ACI may be used to provide that group members can see all other members in the group, but cannot modify the group in any way. Note that DB creator group members do not need explicit noadd or nodelete settings because they inherit those from the context object ACI.
The DB Security administrative members (CN=DBSecurityAdmins, CN=AdminContext,<DC>) could obtain privileges on their own group using the following ACI:
It is noted that the members of the Context Admins group have all privileges on all the groups inherited from the top administrative context entry ACI for a given context.
Shared User Schema
A benefit of the present invention for managing users in a directory is that the number of user accounts created for the distributed databases can be reduced. For example, suppose users John, Mary, and Jane are all users of an application that accesses a Finance database. In conventional approaches to user management, a separate account or schema would be created on the Finance database for each of these users. If there are additional databases that these users seek to access, then a separate user schema is created at every such database. However, creating individual schemas for each user on each database could be overly expensive and inefficient, particularly if there are a large number of users/thin clients accessing the database and many of those users seek to access the same database applications. This is particularly true if the users do not need to create their own objects in the database. The present invention provides a method and mechanism for allowing users to share schemas on a database such that users do not need their own accounts or schemas.
The present invention supports a method and mechanism for mapping one or more enterprise users to the same “shared schema” on an individual database. A shared schema is a schema that is accessible by more than one enterprise user in the system. Instead of creating a separate user account or schema in each database a user needs to access, as well as creating the user in the directory, the enterprise user identification is created once in the directory and the enterprise user is “pointed” at a shared schema that many other enterprise users can also access. In effect, user-schema separation eliminates the need to have a dedicated database schema on each database for every enterprise user. Each enterprise user can be mapped to a shared schema on each database he needs to access.
The mapping between enterprise users and a schema can be locally performed at the database itself or centrally at the directory. In an embodiment, the mapping is performed in the directory by means of one or more mapping objects. This mapping can be specific to a single entry on a single directory level, or can be a mapping that applies to an entire subtree of entries. The mapping objects can be defined at the database level or at the domain level. According to an embodiment, if the mapping is at the domain level, then this provides a default mapping for the specified users at databases in the domain.
A single-level mapping object is referred to as an “EntryLevelMapping” or “full DN mapping” object. This mapping object maps the full Distinguished Name (DN) of a user, e.g., as contained in a user's X.509 certificate, to a database schema that the user will access. This mapping results in one mapping entry per user for the database. There can be any number of full DN mappings for a database that map multiple users to the same schema. When using full DN mapping, each enterprise user can either be mapped to a unique or private schema or to a shared schema. In an alternate embodiment, a unique user attribute, e.g., a global user ID, is mapped instead of the DN.
A subtree mapping object is referred to herein as a “SubtreelevelMapping” or “partial DN mapping” object. This approach maps enterprise users to schemas using partial DN mapping. A partial DN mapping is particularly useful if multiple enterprise users that have something in common are already grouped under some common root in the directory tree. The subtree corresponding to these users can be mapped to a shared schema on a database. For example, all enterprise users in the directory subtree corresponding to a particular organizational division can be mapped to the same shared schema on commonly accessed database(s). In this way, multiple enterprise users sharing part of their DN can access the same shared schema.
When determining the schema to which a user is connected, the database uses the following precedence rules in an embodiment. The database first looks for the mapped schema locally. If the schema mapping is not found locally, then the directory is searched. Within the directory, the database looks under the server object, first for a full DN mapping, then for a partial DN mapping. If the database does not find a mapping object under the server object, it looks under the domain object, first for a full DN mapping, then for a partial DN mapping. If the database does not find a mapping object in the domain object, then the database refuses the connection.
A subtree-level mapping object (“SubtreelevelMapping”) 502 in the subtree beneath the database server object 505 (database DB3) has been established for users having the partial DN “c=us,o=acme”, which maps these users to the local schema “foo” in the DB3 database. If a subtree-level mapping object is created, then all users beneath the given partial DN will be mapped to the local/native user schema. Multiple users may fall within the scope of a subtree-level mapping object.
A subtree-level mapping object 503 has also been established beneath the enterprise domain object 504 for users having the partial DN “o=acme”, which maps these users to the schema “Anonymous” on the DB2 and DB3 databases.
The user having a full DN “cn=scott,o=acme,c=us” falls within the defined scope of more than one of the mapping objects 501, 502, and 503 in
Several enterprise users are defined in the system. User Jane has a full DN of “cn=Jane,c=uk,o=acme”. User Mary has a full DN of “cn=Mary,c=us,o=acme”. User John has a full DN of “cn=John,c=us,o=acme”. In this example, users John and Mary are both associated with the enterprise role ADMIN. User Jane is associated with enterprise role CLERK. Such associations between users and roles may be implemented, for example, using the methods and mechanisms described with reference to
Consider if it is desired to map enterprise users John, Mary, and Jane to shared schemas on the HR and Payroll databases. In this scenario, one or more shared schemas are created for both the HR and Payroll databases. For example, shared schemas “foo1”, “foo2”, and “foo3” can be created on both databases. Referring to
Mapping object 602 sits in the directory tree beneath the database server object 605, and is an entry-level mapping object that maps the full DN of user Mary to the local schema “foo1” on the Payroll database. Mapping object 604 also lies beneath database server object 605, and is a subtree-level mapping object that maps all users having the partial DN “c=us,o=acme” to the local schema “foo2” on the Payroll database. Mapping object 606 is a domain mapping object, e.g., a subtree-level mapping object defined at the domain level, that maps all users having the partial DN “o=acme” to the local schema “foo3” on either the HR or Payroll databases.
When user Mary logs into the Payroll database, she will be associated with the local schema “foo1” based upon the entry-level mapping object 602. The scope of her privileges on the Payroll database is defined by her membership in the enterprise role ADMIN, i.e., the global role ACCOUNTANT on the Payroll database, as well as any roles and privileges locally defined for the “foo1” schema. Note that there is no entry-level mapping object that maps user Mary to a local schema for the HR database. Instead, a domain mapping object 606 maps all users having the partial DN “o=acme”, which includes user Mary, to the local schema “foo3” on both the HR and Payroll databases. Thus, user Mary will log into the HR database using the “foo3” shared schema. Her privileges on the HR database are defined by her membership in the enterprise role ADMIN, i.e., the global role HRCLERK, as well as any local roles and privileges locally defined for the “foo3” schema.
There is a possible conflict between the entry-level mapping object 602, the database subtree-level mapping object 604, and the domain subtree-level mapping object 606 in mapping user Mary to a schema on the Payroll database (i.e., entry-level mapping object 602 maps user Mary to schema foo1, the database subtree-level mapping object 604 maps users Mary to schema “foo2”, and domain subtree-level mapping object 606 maps user Mary to schema foo3). When there is a conflict between an entry-level mapping object and subtree-level mapping objects, then the entry-level mapping preferably takes precedence over the subtree-level mappings. Thus, the mapping of user Mary for a shared schema on the Payroll database is defined by the entry-level mapping object 602 rather than the subtree-level mapping objects 604 and 606.
When user John logs into the Payroll database, he will be associated with the local schema “foo2” based upon the subtree-level mapping object 604. The scope of this user's privileges on the Payroll database is defined by his membership in the enterprise role ADMIN, i.e., the global role ACCOUNTANT on the Payroll database, as well as any roles and privileges locally defined for the “foo2” schema. A domain mapping object 606 exists that maps all users having the partial DN “o=acme”, which includes user John, to the local schema “foo3” on both the HR and Payroll databases. Thus, user John will log into the HR database using the “foo3” shared schema. His privileges on the HR database are defined by membership in the enterprise role ADMIN, i.e., the global role HRCLERK, as well as any local roles and privileges locally defined for the “foo3” schema.
There is a possible conflict between the database subtree-level mapping object 604 and the domain subtree-level mapping object 606 in mapping user John to a schema on the Payroll database. When this type of conflict occurs, the database subtree-level mapping preferably takes precedence over the domain subtree-level mapping. Thus, the mapping of user John for a shared schema on the Payroll database is defined by the database subtree-level mapping object 604 rather than the domain subtree-level mapping object 606.
When user Jane logs into either the Payroll or HR databases, there are no database-specific mapping objects to map a local shared schema for user Jane. Instead, the domain mapping object 606 maps all users having the partial DN “o=acme”, which includes user Jane, to the local schema “foo3” on the HR and Payroll databases. Thus, user Jane will log into the HR and Payroll databases using the “foo3” shared schema. The scope of this user's privileges on both databases is defined by membership in the enterprise role CLERK, i.e., the global role ANALYST on the Payroll database and the global role HRCLERK on the HR database. This user also gains the roles and privileges associated with the local schema “foo3” on each database.
When any of these users connect to a database, he/she is automatically connected to a schema based upon the relevant mapping object for that user and database. As shown in
In an embodiment, a local database server may “opt out” from the shared schema arrangement described above. For example, this can be accomplished by ensuring that no sharable schemas are created at the local server. Thus, mappings cannot occur between an enterprise user and a shared schema. In addition, the local database server can be configured such that users can use local roles only and do not utilize global roles in the directory. To implement this in an embodiment, global roles are not created by the local server. If this configuration is set, the database uses only local roles to determine the scope of user access.
This allows users and database servers to use the central directory for client authentication, but manage user roles locally.
Current User Links
Users at a first database may perform operations that require access to a second database. For example, the user at the first database may execute a database query operation that selects data from a table or object in the second database. As another example, the user at the first database may create a procedure or function with an embedded linking operation that performs one or more operations at the second database.
To illustrate, consider if a user Scott creates a procedure scott.p on a first database DB1 to maintain and update some tables, but would like to grant another user Jane permission to perform the actual work on his behalf. This can be accomplished by granting user Jane execute privileges for the procedure scott.p in which execution of the procedure by Jane creates a temporary security context switch to Scott's security context, such that Jane has access to Scott's objects. In effect, this approach causes the system to consider the “current” user to be Scott, although Jane (the “connected” user) is actually executing the procedure. This dynamic security context switch can be configured to occur whenever a first user executes another user's procedure or view, which effectively allows users to create procedures and grant privileges in such a way as to allow others controlled access to the first users' objects.
Now consider if the procedure scott.p includes a link to a second database DB2. It is often desirable to provide the user that executes a procedure with a security context consistent with the owner of the procedure, particularly when the procedure includes a network link to a second database. In the present example, when user Jane executes procedure scott.p, then the network link to the second database DB2 should be consistent with the security context of the rest of the procedure; that is, user Jane should connect to DB2 with user Scott's security context, and thus temporarily have the necessary privileges to access the appropriate objects on database DB2.
One approach to providing a user access to a second database from a first database is with “connected-user” links, which are also referred to as “anonymous” links. A connected-user link uses the credentials of the connected user to obtain access to a remote database. In the present example, if user Jane executes the procedure scott.p on a first database DB1, which uses a connected-user link to the second database DB2, then user Jane will be connected to the second database using the security context for user Jane (the connected user) rather than the security context for user Scott (the owner of the procedure). Thus, it is possible that the user executing a procedure owned by another would not obtain the necessary access privileges on the remote database to successfully execute the procedure.
An alternate linking approach is to use “fixed user” or “named” links. Unlike a connected-user link, a named link contains both the connect string and the appropriate user credentials (e.g., username/password or other authentication information) for the relevant account on the remote server. Thus, named links allow a user on a first database to execute a procedure at a second database using the security context of another user. The drawback to this approach is that providing this authentication information in a named link creates a potential security problem, since the authentication information may become available to unauthorized users or administrators that have access to the named link on either the source or target databases. Encrypting the password information is not an optimal solution since management and transmission of encryption keys between databases provides another potential source of security failure.
The present invention provides a method and mechanism (referred to herein as “current user links”) for providing connection links as a current user from a first database to a second database without requiring explicit transmission of authentication credentials in the network link between the databases. According to an embodiment, the link to the remote database is embedded into the stored object that is executed. By embedding the database link in a stored object (such as a procedure, view, or trigger), the owner of the stored object can ensure that connection is made using the owner's security context. When any user runs a stored object, the privilege domain of the object owner is used. In an embodiment, this occurs by passing the DN of the current user from the first database to the second database. The transmitted DN is used to map the connected user to the appropriate schema at the second database and for authorizing privileges. Mapping objects may be used to perform this mapping at remote databases.
When executing a stored object (such as a procedure, view, or trigger) in an embodiment of the invention, the current user is the user that created the stored object, and not the user that called it. For example, if the database link appears inside procedure scott.p, created by user Scott, and user Jane calls procedure scott.p, then the current user will be Scott—not user Jane. However, if user Jane uses the database link directly, and not from within procedure scott.p, then the current user will be Jane. Thus, in the case of a database link being used directly, the current user will be the same as the connected user.
To eliminate the need to pass authentication credentials from one database to another trusted relationships can be implemented between database servers.
Enterprise domain 902 is associated with a domain trust flag 906 that is turned “on”. Since the domain trust flag 906 is turned on, users on a first database 910 in enterprise domain 902 that seek to access a second database 912 within the same enterprise domain will be permitted to do so without providing authentication credentials to the second database 912. The database must be able to trust that the communications are really coming from a trusted database within the same enterprise domain. According to an embodiment, SSL is used to authenticate that a communications link is established from a trusted database within the same enterprise domain. Even if data is sent in only one direction between two trusted database servers, mutual authentication is preferably performed using SSL between the two databases.
Enterprise domain 904 includes a domain trust flag 908 that is turned “off”. Since the domain trust flag is turned off, current user links according to an embodiment of the invention cannot be formed between databases in this enterprise domain 904. Thus, users on a database 914 in enterprise domain 904 cannot use current user links to connect to database 916 within the same enterprise domain unless authentication credentials are supplied to database 916 sufficient to allow the desired access.
According to the present embodiment, current user links (also referred to as trusted links) can be formed only for database servers within the same enterprise domain. Thus, a database 910 in enterprise domain 902 cannot form a current user link to database 914 in enterprise domain 904 unless proper authentication credentials are verified by both databases, even if the domain trust flag in turned on in both domains. According to an alternate embodiment, additional trust flags of varying scope may be employed to permit current user links between database servers in different enterprise domains.
Lists could be established to identify which servers are to be trusted by other servers within the domain. This can be explicitly implemented using a central “trusted servers list” that lists all servers that should be trusted by other servers in the domain when establishing a current user link. Alternatively, this can be implicitly implemented by considering all recognized servers in the domain to be centrally “trusted” if the domain trust flag is turned “on.”
Each database server may also maintain a local trusted servers list that explicitly lists which database servers it will or will not trust, which allows each server to locally decide whether to “opt out” of the trusted server arrangement with respect to one or more of the other database within the domain. In the system shown in
The present invention therefore provides a mechanism that allows databases the flexibility to distrust some, but not necessarily all, members of their distributed enterprise domain. This partial trust of the domain may produce a transitivity problem under certain circumstances. For example, assume that databases A, B, and C are all members of the same domain. A and B trust each other, and B and C trust each other, but C doesn't trust A. Even though C doesn't trust A, a user on A can still execute a procedure on A that via a database link connects to and executes a procedure on B, that in turn connects to C. Database C may not realize that the initiator of these links was on A, an untrusted database.
According to an embodiment, the solution is to propagate information with current user links that indicate all prior <database, user> pairs in the current chain of links, which is used in conjunction with local lists of trusted database servers. In a chain of current user links, each database will need to ensure that there is no member of the link chain that is untrusted. Thus, prior to establishing a current user link, the remote database will examine the entire list of prior databases in the chain to ensure that no databases in the chain are listed as “untrusted” in the local trusted servers list.
In one approach, each database in the chain appends to the chain information with the identity of itself and the current user prior to establishing a current user link to the next database. In an alternate approach, the second database in current user link appends the chain information with the <database,user> information for the initiator of the link. Under either approach, each database along the way adds to the chain information.
By supplying the entire history of <database, user> pairs in the chain of current user links, any database server in the chain can examine that information to determine whether any untrusted servers appear on that list and take actions appropriate for that situation. For example, note that database D in
In addition to untrusted servers, current user links may be rejected based upon untrusted users that appear in the chain of current user links. That a particular <database_n,user_n> pair is trusted means that database_n is trusted to connect to another database via current user link, without the user's credentials, as user_n. One or more lists may be established to indicate that databases in the domain are to trust or not trust certain users when establishing current user links, thereby forming a trusted users list 1030. Note that the trusted users list 1030 may be implemented by adding user information to the trusted servers list(s) (such that the trusted users list is the same list as the trusted servers list, central or local, but with information regarding trusted/untrusted users), or may be implemented as an entirely different list depending upon the particular use to which the invention is directed. In an embodiment, the trusted users list is configured to indicate that servers in the domain are trusted to connect only as particular global users and the member databases can be configured to trust no more than what is indicated by the trusted users list. The trusted users list 1030 may include a central membership list 1032 that is the set of <database, user> pairs that can be trusted by other database members in an enterprise domain. Separate trusted users lists can also be maintained locally at the database servers (either as part of or separate from the local trusted servers list), or a combination of local lists and a centrally maintained list can be used to screen attempts to establish current user links.
If it is desired to only check server identities in the prior chain of links without regard to prior users in the chain, then the trusted servers list(s) are used without listing trusted/untrusted users. If it is desired to check user identities before allowing a current user link, then the trusted users list (whether separate or part of the trusted servers list) is employed to list trusted or untrusted users.
An additional mechanism that a group of databases can use to increase security and to eliminate threats introduced by transitivity is to enforce isolationism. For example, if databases A, B, C, and D wish to ensure that they will not accept any link strings that have passed through other untrusted databases, all these databases can all agree to only accept current user links from each other. Databases A, B, C, and D will, in effect, become isolated from the rest of the enterprise domain, thereby eliminating potential transitivity problems. In a sense, these databases will have formed their own subdomain. Similarly, if all databases in the enterprise domain agree that a particular database X is not to be trusted, then all the databases can designate this in their local trusted servers list. Regardless of what is listed for Database X at the trusted users list, Database X will effectively be isolated from the rest of the domain.
The following are examples of maintenance operations for the trusted servers list:
According to an embodiment, the default trusted servers list includes one entry at database creation to designate all other databases in the domain as trusted (“Allow All”). This default state results in the database trusting exactly those <database, user> pairs listed at the trusted users list, if the trusted users list is being used. If any database performs an Allow All operation, the database reverts to this trust situation. The local database may wish to obtain a list of the current members of the domain, and/or which users they are trusted to connect as.
Each database may modify the trusted servers list to indicate that certain databases are to be trusted or not trusted, or that all or none are to be trusted. If a database sets its local trusted servers list to trust no other databases (“Deny All”), no other databases will be permitted to connect via current user links, regardless of the settings in the trusted users list. If the local database performs a local Deny All operation, and then subsequently wishes to trust a specific database DBx, then the database DBx will be added as a trusted database to the local trusted servers list (“Allow DBx” operation). A later “Deny DBx” operation will simply reverse the effects of a specific “Allow DBx”, and a later “Deny All” operation will reverse all previous “Allow DBxs” operations, e.g., by making the appropriate entries in the trusted servers list. Similarly, if the local database performed an “Allow All” operation, and subsequently wishes to deny current user links from a specific database, the trusted servers list can be modified to do so.
The effect of the trusted servers list is to potentially reduce the list of allowed connections from that permitted by the trusted users list. In the present embodiment, if the trusted servers list includes entries that are not listed at the trusted users list, those entries have no effect. However, a local database may wish to include entries for databases that are considered especially threatening, even if not listed at the trusted users list, to avoid a temporary security risk in the situation where the database suddenly becomes centrally trusted by the trusted users list. This could be done by performing an “Allow All” operation, and then listing that particular database as untrusted. If the local database wishes to be extra careful and prevent access by any database that might be added without its knowledge to the trusted users list, could have to be accomplished by performing a “Deny All” operation, and then Allowing the exact list of databases specifically intended to be trusted.
According to an embodiment, current user links are implemented based upon the current user being a global enterprise user with accounts on both databases involved. The accounts can be either unique or shared accounts. Since the remote database allows a connection for the claimed global user without proof of identity, it must trust that the request is valid—that is, the calling user has been properly authenticated by the first database, the calling user has legitimate access to the link, and that the link itself is legitimate. In an embodiment, the database should therefore verify that the originator of the link is in fact a database server, and not a client. In addition, the originating database should trust the remote database before connecting as the specified user, since commands may be executed back on the originating database by the remote database, via the link. This means that the two databases should mutually authenticate whenever a current user link is opened. In this approach, if mutual authentication fails then the link fails. Alternatively, one-way authentication between database servers may be employed if desired.
In addition to verifying that the other database is a server in the domain, the database receiving the connection request via a current user link ensures that the database originating the current user link is trusted to connect as the particular global user involved. This determination of trust occurs in two steps: first the database ensures that the originating database is listed at the trusted users list as being trusted to connect as that user, and second that the originating database is not listed locally in the trusted servers list as not to be trusted. If the <database,user> pair is determined to be trusted, that implies that the originating database is trusted to locally administer that global user properly.
According to an embodiment, only the last <database,user> entry in the link chain is locally checked for trust-authorization by the trusted users list. This is because all previous entries were presumably checked by previous databases in the string of links. Since no database can trust more than the trusted users list indicates in the present embodiment, it can be assumed that all entries in the chain, except possibly the last, are listed as trusted at the trusted users list. All that remains is to check the last entry.
The present invention also provides sufficient audit information to trace current user links back to the originating connected user. Maintaining a link chain of <database,user> entries facilitates auditing of user activities, since the link information allows actions performed at one database to be traced. In effect, the links are traceable backwards first to the connected user on the destination database (which is the current user on the originating database, and then through the chain of current user links to the connected user on the originating database.
In the above description, the trusted servers list only included a listing of trusted and untrusted database servers. In an alternate embodiment, the local trusted servers list also includes a list of trusted and untrusted <database, user> pairs. In this alternate embodiment, the additional <database, user> pair information allows finer granularity control over the exact current user links that may be established to the database.
According to an embodiment of the invention, authentication to the directory is provided using interoperable X.509 v3 certificates over Secure Sockets Layer (SSL) v3. The following are three examples of different levels of user authentication: anonymous, password-based, and certificate-based, using the Secure Socket Layer (SSL) v3 protocol for authenticated access and data privacy.
In an embodiment, a Wallet Manager is used to manage security credentials for a user. A wallet manager is an application, preferably a standalone Java application, that wallet owners and security administrators use to manage and edit the security credentials in user wallets. The Wallet Manager provides a way to manage (request, store, and view) wallets. It creates keys and manages credential preferences for a user. A wallet contains a certificate, encrypted private key, and trust points for the user, and possibly other combinations of security credentials. The entire wallet should also be encrypted. Examples of Wallet Manager tasks include:
A login interface mechanism is employed to open and close a user wallet in order to enable or disable secure SSL-based communications for an application. The login interface mechanism preferably enables a user to log on to applications automatically. This tool is preferably a functional subset of the Wallet manager. The login interface mechanism preferably masks the complexity of SSL, wallets, enterprise users, and the process of authenticating to multiple databases. The login interface mechanism should let users access multiple databases and applications using a single password, entered only once per session, and provides the subset of the wallet manager functionality for opening a user wallet and enabling applications to use the open wallet to automatically authenticate a user.
The present invention may be employed with any type of LDAP directory. For the purposes of illustration, the present invention is described with respect to an LDAP directory implemented using a relational database management system (“RDBMS”). This section describes methods and mechanisms for integrating a RDBMS with LDAP directory structures.
The LDAP APIs open LDAP connections to the Directory Service to obtain the information. In one embodiment, the LDAP API 1306 uses SSL 1308 instead of TCP/IP 1310 for sending LDAP messages to an enterprise directory service. Alternatively, TCP/IP 1310 is employed instead of SSL 1308. According to an embodiment of the invention, standard LDAP schemas are extended to include additional role and server information. For example, Enterprise roles will be added as objects, along with mechanisms to store the roles allocated to a global user.
For an RDBMS-authenticated connection using a shared server, the RDBMS will open (bind) the RDBMS-LDAP connection the first time it is needed (either authorizing a user or another server), and will leave it open, according to an embodiment. The connection context will be stored in memory buffer that contains data and control information for a server process (“PGA”) for future use by the server. Future calls from the RDBMS to LDAP will use this connection if it still exists. If not, a new connection will be opened. The connection will be closed (unbind) upon shutdown of that server. No LDAP requests from applications will be routed to these RDBMS-LDAP connections. For a dedicated server, an RDBMS-LDAP connection will be opened each time it is needed, and closed immediately thereafter.
For both shared and dedicated servers, anonymous connections will be opened and closed upon request by applications, and the connection context will be in a system memory region that contains data and control information (“UGA”). In this manner, it will be available for use regardless of which shared server the application is routed to.
In an alternate embodiment, connections are shared between servers, similarly to shared database links, with the connection context stored in a shared memory region for a database instance (“SGA”) and connections maintained by a background process such as a dispatcher process. Using shared connections between servers may involve increased overhead, e.g., due to context switches.
In an embodiment, all LDAP calls are made in synchronous (blocking) mode, so the server will block until the LDAP query results are available. Since there are other shared servers which can process other user's requests, the overall system response time will not be adversely affected. LDAP calls in an embodiment are calls to the NNFL layer. NNFL, as mentioned previously, will in turn call the LDAP API. Non-cached information will be requested from NNFL. The NNFL layer handles referrals transparently to the RDBMS.
Steps 1–3 in
The database server 1706 is also registered via the CA 1702 (or Kerberos authority) with an X.509 name at the LDAP directory 1704. The database or DBA obtains a wallet with a certificate as part of this process. Then, there is another login-like exchange via a wallet manager to open a wallet for the server 1706. This wallet contains the server's signed certificate (if certificates are used), trust points, and an encrypted private key. These items will be used in the handshake between the server 1706 and the global user 1708.
Steps A, B, and C in
During the attach phase, before the actual login, the database 1706 obtains the user identity (e.g., from the certificate, if using certificates), and places it into the network context. At login, the RDBMS extracts the user's external username (e.g., the distinguished name) and public key from the network context. The RDBMS looks up the global user locally and in the directory to find an associated schema name. The database 1706 then retrieves the user's global roles from the LDAP directory. The database 1706 also performs schema mappings for the user 1708.
An embodiment of the invention utilizes a LDAP Directory Service Monitor process (LDMON), which is an RDBMS server process. In an embodiment, the LDMON opens two connections via the LDAP API to the LDAP server at database startup, and maintains and manages a pool of open connections for use by the RDBMS and applications/users. LDMON opens connections by making an LDAP API call to send a standard LDAPv3 BindRequest call to the LDAP server, authenticating as the database or as the application or user that requested it. LDMON closes connections by making an UnbindRequest API call.
In an embodiment, the calling stack is as follows: the API or RDBMS internals indirectly or directly call LDMON, which pools connections and calls the LDAP API through the NNFL, which produces LDAPv3 requests and sends them via SSL. Alternatively, the calls to the LDAP API are not made through an NNFL. In an embodiment, the LDAP API has no knowledge of the underlying schema at LDAP, and just sends the requested LDAP messages. However, the RDBMS does know about the schema, and thus can determine what sort of LDAP search requests to send.
LDMON functionality depends on the type of connection requested. For internal RDBMS calls to LDMON, the request will preferably be put on a queue of requests waiting for an RDBMS-authenticated connection. The requests on the queue are processed in a FIFO manner, with time-outs to determine if a connection is no longer needed. If the queue gets too long, and the number of open connections will be at or below a maximum limit, a new RDBMS-authenticated LDAP connection can be opened. Note that internal RDBMS calls to LDMON and should not include the bindRequest and unbindRequest calls, since it can be assumed that LDMON is managing the opening and closing of properly authenticated connections.
For calls from applications or users requesting anonymous connections, the request will preferably be put on a second queue of requests waiting for an anonymous connection. As above, the requests on the queue are processed in a FIFO manner, with time-outs to determine if a connection is no longer needed. If this queue gets too long, and the number of open connections will be at or below a maximum limit, a new anonymous LDAP connection can be opened. Note that anonymous connection bind request calls to LDMON may not actually result in an LDAP bindRequest call, since there may be available anonymous connections already open. Similarly, unbind request calls may not actually drop the anonymous connection.
In an embodiment, the difference between anonymous connections and the RDBMS-authenticated connections are that anonymous connections are only created as needed, whereas two RDBMS-authenticated connections are always kept open. Also, these anonymous connections are available to any caller, whereas the RDBMS-authenticated connections are only available internally to the RDBMS. The main similarity is that both types of connections are shared between callers, and are not locked for any caller. LDMON routes the LDAP responses to the relevant requestor.
For requests from applications or users for a specially authenticated LDAP connection, the user requests a connection to the LDAP server by calling a bind to LPMON. If the number of open connections will be at or below a maximum limit, LDMON attempts to open an appropriately authenticated connection to the LDAP server for that user. If successful, LDMON assigns the connection to the user, and returns a connection identifier. Future LDAP requests from this user refer to this connection identifier. If the number of open connections would be above the maximum limit, the request is put in the request queue. When an entity drops a LDMON connection, or an anonymous or RDBMS-authenticated connection (other than any mandatory connections that must remain open) times out, the connection request queue is checked, and a new connection is opened and authenticated appropriately for the first entry in the queue.
According to an embodiment, the LDMON process includes the following characteristics: LDMON maintains at least two open connections from the RDBMS to the LDAP server; LDMON uses the LDAP API to communicate with the LDAP server; the LDAP API communicates to LDAP via standard LDAPv3 calls; the LDAP API communicates to LDAP in a secure fashion via SSL; LDMON ensures that no non-RDBMS process (such as an application or database user) places information on RDBMS-authenticated connections; if requested, LDMON opens an authenticated connection in the name provided by an application, and ensure that no other process places information on that connection; if the RDBMS requests a connection, and no RDBMS-authenticated connection is currently available (i.e., less than X entries in the queue for that connection), LDMON attempts to open a new appropriately authenticated connection, up to a maximum specified number; if an application requests a connection, LDMON attempts to open a new appropriately authenticated connection, up to a specified maximum number; If the maximum number of connections has been reached, so that bind requests have to wait, those callers specifying WAIT will be queued up and allocated connections as they become available on a first-come, first-served basis; LDMON returns an error to the caller if the caller has specified NOWAIT, if the maximum number of connections has been reached and no appropriately authentication connection is currently available; LDMON ensures that connections bound by applications or users are actually being used, possibly via a time-out mechanism; LDMON cleans up dropped connections; LDMON attempts to reopen at least two RDBMS connections if the LDAP server crashes and/or reboots; LDMON will preferably return error messages to clients or applications that had a connection locked at the time of the crash.
The following are additional functional characteristics according to an embodiment for the LDAP server. When opening a new connection to the LDAP server as the RDBMS, the RDBMS preferably mutually authenticates with the LDAP server in a secure way such that another entity cannot masquerade as that Oracle database server, or as the LDAP server. When opening a new connection to the LDAP server as an application/user entity, the RDBMS relays the entity name and password to the LDAP server. LDAP responses are reliably associated with the correct LDAP requests for that LDAP connection, even if requests and/or responses are processed asynchronously. LDAP requests and responses are reliably stored by the RDBMS until they can be sent to LDAP or back to the requesting entity. User and server authorization information retrieved from LDAP are cached at the RDBMS up to a specified time limit. LDMON retrieves fresh information directly from LDAP, and not from the cache, if requested by the calling process. In this case, the cache is updated with non-cached information.
The following are characteristics of the LDAP API according to an embodiment of the invention: JAVA and PL/SQL LDAP APIs are available to RDBMS users and applications, and provide access to all standard LDAP functionality. APIs work with any suitable implementation of LDAP. The LDAP APIs should attempt to open an LDAP connection as anonymous or as an entity specified by the application, using the application-provided password. This may be accomplished by the application imbedding an LDAP password in a trusted stored procedure. There should be an initialization parameter that specifies the maximum allowed number of concurrent LDAP connections per application/user. The LDAP APIs should include a mechanism for the user to specify that non-cached information is to be obtained from LDAP; i.e., to indicate that cached, previously-retrieved information is not acceptable. The RDBMS should return the response from LDAP to the application that made the corresponding request. Finally, requests can specify synchronous or asynchronous responses.
System Architecture Overview
In an embodiment, the host computer 1822 operates in conjunction with a data storage system 1831, wherein the data storage system 1831 contains a database 1832 that is readily accessible by the host computer 1822. Note that a multiple tier architecture can be employed to connect user stations 1824 to a database 1832, utilizing for example, a middle application tier (not shown). In alternative embodiments, the database 1832 may be resident on the host computer, stored, e.g., in the host computer's ROM, PROM, EPROM, or any other memory chip, and/or its hard disk. In yet alternative embodiments, the database 1832 may be read by the host computer 1822 from one or more floppy disks, flexible disks, magnetic tapes, any other magnetic medium, CD-ROMs, any other optical medium, punchcards, papertape, or any other physical medium with patterns of holes, or any other medium from which a computer can read. In an alternative embodiment, the host computer 1822 can access two or more databases 1832, stored in a variety of mediums, as previously discussed.
A processing unit may be coupled via the bus 1906 to a display device 1911, such as, but not limited to, a cathode ray tube (CRT), for displaying information to a user. An input device 1912, including alphanumeric and other columns, is coupled to the bus 1906 for communicating information and command selections to the processor(s) 1907. Another type of user input device may include a cursor control 1913, such as, but not limited to, a mouse, a trackball, a fingerpad, or cursor direction columns, for communicating direction information and command selections to the processor(s) 1907 and for controlling cursor movement on the display 1911.
According to one embodiment of the invention, the individual processing units perform specific operations by their respective processor(s) 1907 executing one or more sequences of one or more instructions contained in the main memory 1908. Such instructions may be read into the main memory 1908 from another computer-usable medium, such as the ROM 1909 or the storage device 1910. Execution of the sequences of instructions contained in the main memory 1908 causes the processor(s) 1907 to perform the processes described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and/or software.
The term “computer-usable medium,” as used herein, refers to any medium that provides information or is usable by the processor(s) 1907. Such a medium may take many forms, including, but not limited to, non-volatile, volatile and transmission media. Non-volatile media, i.e., media that can retain information in the absence of power, includes the ROM 1909. Volatile media, i.e., media that can not retain information in the absence of power, includes the main memory 1908. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 1906. Transmission media can also take the form of carrier waves; i.e., electromagnetic waves that can be modulated, as in frequency, amplitude or phase, to transmit information signals. Additionally, transmission media can take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
Common forms of computer-usable media include, for example: a floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, RAM, ROM, PROM (i.e., programmable read only memory), EPROM (i.e., erasable programmable read only memory), including FLASH-EPROM, any other memory chip or cartridge, carrier waves, or any other medium from which a processor 1907 can retrieve information. Various forms of computer-usable media may be involved in providing one or more sequences of one or more instructions to the processor(s) 1907 for execution. The instructions received by the main memory 1908 may optionally be stored on the storage device 1910, either before or after their execution by the processor(s) 1907.
Each processing unit may also include a communication interface 1914 coupled to the bus 1906. The communication interface 1914 provides two-way communication between the respective user stations 1924 and the host computer 1922. The communication interface 1914 of a respective processing unit transmits and receives electrical, electromagnetic or optical signals that include data streams representing various types of information, including instructions, messages and data. A communication link 1915 links a respective user station 1924 and a host computer 1922. The communication link 1915 may be a LAN 1826, in which case the communication interface 1914 may be a LAN card. Alternatively, the communication link 1915 may be a PSTN 1828, in which case the communication interface 1914 may be an integrated services digital network (ISDN) card or a modem. Also, as a further alternative, the communication link 1915 may be a wireless network 1830. A processing unit may transmit and receive messages, data, and instructions, including program, i.e., application, code, through its respective communication link 1915 and communication interface 1914. Received program code may be executed by the respective processor(s) 1907 as it is received, and/or stored in the storage device 1910, or other associated non-volatile media, for later execution. In this manner, a processing unit may receive messages, data and/or program code in the form of a carrier wave.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. For example, the reader is to understand that the specific ordering and combination of process actions shown in the process flow diagrams described herein is merely illustrative, and the invention can be performed using different or additional process actions, or a different combination or ordering of process actions. The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5386557||Nov 12, 1992||Jan 31, 1995||International Business Machines Corporation||Enforcement of referential constraints in a database system|
|US5450581||Oct 11, 1994||Sep 12, 1995||International Business Machines Corporation||System for copying from one database management system to another by translating authorization statements|
|US5497463||Sep 25, 1992||Mar 5, 1996||Bull Hn Information Systems Inc.||Ally mechanism for interconnecting non-distributed computing environment (DCE) and DCE systems to operate in a network system|
|US5579222 *||Dec 14, 1992||Nov 26, 1996||Intergraph Corporation||Distributed license administration system using a local policy server to communicate with a license server and control execution of computer programs|
|US5684951||Mar 20, 1996||Nov 4, 1997||Synopsys, Inc.||Method and system for user authorization over a multi-user computer system|
|US5708812||Jan 18, 1996||Jan 13, 1998||Microsoft Corporation||Method and apparatus for Migrating from a source domain network controller to a target domain network controller|
|US5768519||Jan 18, 1996||Jun 16, 1998||Microsoft Corporation||Method and apparatus for merging user accounts from a source security domain into a target security domain|
|US5884316||Nov 19, 1996||Mar 16, 1999||Microsoft Corporation||Implicit session context system with object state cache|
|US5899987||Oct 3, 1995||May 4, 1999||Memco Software Ltd.||Apparatus for and method of providing user exits on an operating system platform|
|US5983350||Sep 18, 1996||Nov 9, 1999||Secure Computing Corporation||Secure firewall supporting different levels of authentication based on address or encryption status|
|US6092189||Apr 30, 1998||Jul 18, 2000||Compaq Computer Corporation||Channel configuration program server architecture|
|US6119230||Oct 1, 1997||Sep 12, 2000||Novell, Inc.||Distributed dynamic security capabilities|
|US6126328||Feb 28, 1997||Oct 3, 2000||Oracle Corporation||Controlled execution of partitioned code|
|US6145086||Apr 26, 1999||Nov 7, 2000||Oracle Corporation||Security and password mechanisms in a database system|
|US6158007||Sep 17, 1997||Dec 5, 2000||Jahanshah Moreh||Security system for event based middleware|
|US6158010 *||Feb 12, 1999||Dec 5, 2000||Crosslogix, Inc.||System and method for maintaining security in a distributed computer network|
|US6178511 *||Apr 30, 1998||Jan 23, 2001||International Business Machines Corporation||Coordinating user target logons in a single sign-on (SSO) environment|
|US6192130||Jun 30, 1999||Feb 20, 2001||Entrust Technologies Limited||Information security subscriber trust authority transfer system with private key history transfer|
|US6240512||Apr 30, 1998||May 29, 2001||International Business Machines Corporation||Single sign-on (SSO) mechanism having master key synchronization|
|US6243816||Apr 30, 1998||Jun 5, 2001||International Business Machines Corporation||Single sign-on (SSO) mechanism personal key manager|
|US6253216||Jun 13, 1997||Jun 26, 2001||Tele-Publishing, Inc.||Method and apparatus for providing a personal page|
|US6260039||Dec 15, 1997||Jul 10, 2001||International Business Machines Corporation||Web interface and method for accessing directory information|
|US6275944||Apr 30, 1998||Aug 14, 2001||International Business Machines Corporation||Method and system for single sign on using configuration directives with respect to target types|
|US6289462||Sep 28, 1999||Sep 11, 2001||Argus Systems Group, Inc.||Trusted compartmentalized computer operating system|
|US6321259||Oct 2, 1998||Nov 20, 2001||Nortel Networks Limited||Attribute inheritance schema for network switches|
|US6339423||Mar 23, 2000||Jan 15, 2002||Entrust, Inc.||Multi-domain access control|
|US6377950||Oct 9, 1998||Apr 23, 2002||Mitel Corporation||Integrated directory services|
|US6385724||Nov 30, 1998||May 7, 2002||Microsoft Corporation||Automatic object caller chain with declarative impersonation and transitive trust|
|US6487552||Oct 5, 1998||Nov 26, 2002||Oracle Corporation||Database fine-grained access control|
|US6490591||Mar 13, 2000||Dec 3, 2002||Cisco Technology, Inc.||Apparatus and method for storing complex structures by conversion of arrays to strings|
|US6507817||Jun 27, 2000||Jan 14, 2003||Cisco Technology, Inc.||Voice IP approval system using voice-enabled web based application server|
|US6535879||Feb 18, 2000||Mar 18, 2003||Netscape Communications Corporation||Access control via properties system|
|US6556995||Nov 18, 1999||Apr 29, 2003||International Business Machines Corporation||Method to provide global sign-on for ODBC-based database applications|
|US6651168||Jan 29, 1999||Nov 18, 2003||International Business Machines, Corp.||Authentication framework for multiple authentication processes and mechanisms|
|US6678682||Nov 28, 2000||Jan 13, 2004||G.E. Information Services, Inc.||Method, system, and software for enterprise access management control|
|US6768988||May 29, 2001||Jul 27, 2004||Sun Microsystems, Inc.||Method and system for incorporating filtered roles in a directory system|
|US20010023440 *||Sep 30, 1997||Sep 20, 2001||Nicholas H. Franklin||Directory-services-based launcher for load-balanced, fault-tolerant, access to closest resources|
|US20020007346||Jun 6, 2001||Jan 17, 2002||Xin Qiu||Method and apparatus for establishing global trust bridge for multiple trust authorities|
|US20020026592 *||Jun 14, 2001||Feb 28, 2002||Vdg, Inc.||Method for automatic permission management in role-based access control systems|
|US20020069223||Oct 3, 2001||Jun 6, 2002||Goodisman Aaron A.||Methods and systems to link data|
|US20020078004||Dec 18, 2000||Jun 20, 2002||International Business Machines Corporation||Extendible access control for lightweight directory access protocol|
|US20020082818 *||Jan 23, 2001||Jun 27, 2002||Glenn Ferguson||Data model for automated server configuration|
|US20020083073||Dec 22, 2000||Jun 27, 2002||Vaidya Neelam N.||Managing a layered hierarchical data set|
|US20030195888||Apr 29, 2003||Oct 16, 2003||Lion Bioscience Ag||Database linking method and apparatus|
|1||"Configuring LDAP", The Apache Software Foundation 2003-2009.|
|2||Bertino, E. et al. "Controlled Access and Dissemination of XML Documents" Proceedings of the 2nd International Workshop on Web Information and Data Management (Nov. 1999) pp. 22-27.|
|3||Bertino, E. et al. "On Specifying Security Policies for Web Documents with an XML-Based Language" Proceedings of the 6th ACM Symposium on Access Control Models and Technologies (May 2001) pp. 57-65.|
|4||Bonczek, R.H. et al. "A Transformational Grammar-Based Query Processor for Access Control in a Planning System" ACM Transactions on Database Systems (TODS) (Dec. 1977) 2(4):326-338.|
|5||Castano, S. et al. "A New Approach to Security System Development" Proceedings of the 1994 Workshop on New Security Paradigms (Aug. 1994) pp. 82-88.|
|6||Gladney, H.M. "Access Control for Large Collections" ACM Transactions on Information Systems (TOIS) (Apr. 1997) 15(2):154-194.|
|7||How to: "Use ADSI to Set LDAP Directory Attributes", Microsoft 2000 Edition, Sep. 28, 2007, Revision: 3.3.|
|8||Hsiao, D.K. "A Software Engineering Experience in the Management, Design and Implementation of a Data Secure System" Proceedings of the 2nd International Conference on Software Engineering (Oct. 1976) pp. 532-538.|
|9||Myers, A.C. and B. Liskov "Protecting Privacy Using the Decentralized Label Model" ACM Transactions on Software Engineering and Methodology (Oct. 2000) 9(4):410-442.|
|10||Oracle8 Server Concepts, "Privileges and Roles", Release 8.0, vol. 2, Jun. 1997, pp. 25-1 through 25-15.|
|11||Sandhu, R.S. "The Schematic Protection Model: Its Definition and Analysis for Acyclic Attenuating Schemes" Journal of the Association of Computing Machinery (JACM) (Apr. 1988) 35(2):404-432.|
|12||Sion, R. et al. "Data Security and Protection: Rights Protection for Relational Data" Proceedings of the 2003 ACM SIGMOD International Conference on Management of Data (Jun. 2003) pp. 98-109.|
|13||Weede, H.F. and M. Lischka "Role-Based Access Control in Ambient and Remote Space" Proceedings of the 9th ACM Symposium on Access Control Models and Technologies (Jun. 2004) pp. 21-30.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8271528 *||Jul 25, 2008||Sep 18, 2012||United Services Automobile Association (Usaa)||Database for access control center|
|US8360887 *||Feb 9, 2007||Jan 29, 2013||Wms Gaming Inc.||Wagering game server availability broadcast message system|
|US8464313||Nov 10, 2008||Jun 11, 2013||Jeff STOLLMAN||Methods and apparatus related to transmission of confidential information to a relying entity|
|US8549589 *||Nov 10, 2008||Oct 1, 2013||Jeff STOLLMAN||Methods and apparatus for transacting with multiple domains based on a credential|
|US8595113||Jan 11, 2008||Nov 26, 2013||Venkataraman Chittoor||Facility for the finding, acquisition, and maintenance of intellectual property assets|
|US8631504 *||Jun 17, 2008||Jan 14, 2014||Jayant Joshi||Document security within a business enterprise|
|US8650616 *||Dec 18, 2007||Feb 11, 2014||Oracle International Corporation||User definable policy for graduated authentication based on the partial orderings of principals|
|US8707397||Sep 10, 2008||Apr 22, 2014||United Services Automobile Association||Access control center auto launch|
|US8850525||Sep 17, 2008||Sep 30, 2014||United Services Automobile Association (Usaa)||Access control center auto configuration|
|US8863276||Jan 31, 2013||Oct 14, 2014||International Business Machines Corporation||Automated role adjustment in a computer system|
|US8909916 *||Nov 30, 2009||Dec 9, 2014||Red Hat, Inc.||Using a PKCS module for opening multiple databases|
|US8978104||Jul 23, 2008||Mar 10, 2015||United Services Automobile Association (Usaa)||Access control center workflow and approval|
|US9087148||Aug 19, 2013||Jul 21, 2015||International Business Machines Corporation||Automated role adjustment in a computer system|
|US9124649||Apr 21, 2014||Sep 1, 2015||United Services Automobile Associate (USAA)||Access control center auto launch|
|US20080294478 *||Jun 17, 2008||Nov 27, 2008||Iris Interactive Pty Ltd||Document security within a business enterprise|
|US20090158425 *||Dec 18, 2007||Jun 18, 2009||Oracle International Corporation||User definable policy for graduated authentication based on the partial orderings of principals|
|US20100116880 *||Nov 10, 2008||May 13, 2010||Stollman Jeff||Methods and apparatus for transacting with multiple domains based on a credential|
|US20100241668 *||Sep 23, 2010||Microsoft Corporation||Local Computer Account Management at Domain Level|
|US20110131407 *||Jun 2, 2011||Robert Relyea||Using a pkcs module for opening multiple databases|
|US20140196132 *||Nov 11, 2013||Jul 10, 2014||Quest Software, Inc.||Disconnected credential validation using pre-fetched service tickets|
|U.S. Classification||726/26, 726/17|
|International Classification||G06F21/20, G06F21/02|
|Cooperative Classification||Y10S707/99943, G06F21/6218, Y10S707/99942|
|Feb 27, 2002||AS||Assignment|
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LEWIS, NINA;REEL/FRAME:012662/0924
Owner name: ORACLE CORPORATION, CALIFORNIA
Effective date: 20020226
|Mar 11, 2003||AS||Assignment|
Owner name: ORACLE INTERNATIONAL CORPORATION (OIC), CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ORACLE CORPORATION;REEL/FRAME:013797/0613
Effective date: 20030221
|Sep 13, 2011||CC||Certificate of correction|
|Jun 4, 2014||FPAY||Fee payment|
Year of fee payment: 4