Dynamic group generation and management6671695Abstract An apparatus, program product, and method utilize "dynamic" groups to represent collections of individuals in a computer environment. With a dynamic group, a group membership criterion and a set of member identifiers are associated with one another within a dynamic group data structure, such that the set of member identifiers identifies those users from a plurality of users that meet the group membership criterion for the dynamic group. Dynamic updates are performed periodically and/or in response to predetermined events, such that the set of member identifiers for a dynamic group are updated to reflect modifications to the plurality of users, and thereby maintain the identification of members in the dynamic group current. Dynamic group data structures may be utilized in connection with multiple networked target computer environments having users that span multiple computer domains and/or enterprises, wherein the target computer environments are networked with a hub computer upon which is resident a database that maintains a dynamic group data structure. Within at least a portion of such target computer environments, mirrored group data structures are distributed and maintained, with each including at least a subset of member identifiers from the set of member identifiers associated with the dynamic group data structure. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE I
EXTENDED LDAP OBJECT ATTRIBUTES
LDAP ATTRIBUTE DEFINITION OF ATTRIBUTE
commonName or cn User/employee full name
ExtPrefix User/employee naming prefix (Mrs, Ms, Mr, Dr etc.)
givenName User/employee first name
initials User/employee initials
ExtMiddleName User/employee middle name
ExtInitials Extended initials (if duplicated initials exist)
surName or sn User/employee last name
uid Unique ID
EmployeeType Description of user/employee's status
ExtStatus Extension to status (0 = Active, 2 = Inactive)
ExtCompany Company name of contractors
ExtHireDate Date user/employee most recently began work @
company
ExtNotesMail Internal email address used by user/employee to send
internal
messages
mail Internet-standard format email address used by
user/employee.
telephoneNumber User/employee telephone number
ExtExtension Extension of User/employee work phone number
ExtAltPhone Alternate phone number
ExtStarnet Internal company phone number
fascimileTelephoneNumber Fax number
ExtFaxServer Fax server
ExtStarnetFax Internal company fax number
ExtTelephony Telephony Information
mobile Mobile phone number
pager Pager phone number
secretary Name of the user/employee's administrative assistant
seeAlso Name of the user/employee's alternate or backup
manager Name of the user/employee's manager
ExtPhotoURL A ".gif" or ".jpeg" file containing user/employee's
picture
ExtOrgType User/employee's business unit type
ExtOrgName User/employee's business unit name
departmentNumber User/employee department number
ExtDepartmentName User/employee department name
businessCategory Grouping of products with related uses
ExtSubCategory Product family
ExtSegment Grouping of products with single intended use by
consumer
ExtCostCode User/employee cost center code
ExtFunction User/employee company division
title Description of the user/employee's job
ExtRole User/employee "role" in business unit
ExtRegion Location of user/employee, based on a Global
standard
ExtCountry Location of user/employee, based on country
st Location of user/employee, based on divisions within
country
ExtCity Location of user/employee based on divisions within
state
PostalCode Postal code of area in which user/employee works
street External mailing address
ExtBuilding Company-owned building in which user/employee works
ExtSite Company site
ExtFloor Floor on which user/employee works
roomNumber User/employee room number
ExtIntMailBox Company "internal" mailing box
postalAddress Full postal address used to route mail externally to
user/employee
ExtProject Description of user/employee's past/present project
assignments
ExtExpertise Description of business-related skills or areas of
expertise
ExtLanguage Languages spoken by user/employee
ExtInterest Description of business-related skills or areas of
interest
ExtTeam Past and present teams that user/employee has been a
member
ExtInitiative Past and present initiatives that user/employee has
been a member
ExtHomeTown User/employee home town
ExtSecondary User/employee high school
ExtPostSecondary User/employee secondary school, and degree earned
ExtDegree Degree earned at each level of schooling
ExtSignOther Name of spouse/significant other
ExtChildren Names of Children
ExtHobby Activities or sports
ExtAffliation Organizations user/employee is involved with outside
company
ExtUpdateBy Automatic or manual update flag
ExtUpdateTime Time in which entry was updated
ExtSource Source for entry
ExtPlatform Platform/System identifiers
ExtShortName Intranet short name
ExtGloPN Global Personnel Number
employeeNumber Local employee ID
ExtAltID Alternate computing ID's
ExtHandle Extranet user login name
ExtMailServer Email server name
ExtMailDomain Email Domain
ExtPrefLanguage Preferred Language
ExtReqPlatform Requested platforms
ExtApproverfor Platform Approval
ExtNtDomain NT Domain
ExtMailFile E-mail File name
ExtApplication Application object class for non-people account
information.
ExtSession Object class to hold login session information.
ExtSecurityObject Object class to hold password security information.
ExtDisabled Disabled flag
ExtPassword Current password
ExtMaxDays Length of time in days that passwords are valid
ExtPwdLastChangeDate Date of last password change
ExtPwdExpirationDate Date password expires
ExtPriorPwd1 1st previous password
ExtPriorPwd2 2nd previous password
ExtPriorPwd3 3rd previous password
ExtPriorPwd4 4th previous password
ExtPriorPwd5 5th previous password
ExtChallengeQuestion Password question
ExtChallengeAnswer Password question answer
ExtChallengePwd Challenge password
extpwFailCount Number of failed login attempts since last
successful login
extpwFailTime Timestamp of last failed login attempt
extLastLoginTime Timestamp of last successful login attempt
Given the LDAP object class structure shown in Table I, any number and combination of the listed attributes may be utilized in defining the membership criterion for a dynamic group, including attributes in areas such as location, user employment status, user interests, user capabilities, user education, etc. Moreover, it will be appreciated that other combinations of attributes may be added to an LDAP object depending upon the desired application and bases for selecting users into dynamic groups. It will also be appreciated that other, non-LDAP user records may be used in the alternative. Thus, the invention is not limited to the specific LDAP object implementation discussed herein. In the exemplary security management implementation discussed hereinafter, the user and group databases are integrated into a common LDAP-based directory database. To support dynamic groups consistent with the invention, a database schema should be designed to support the concepts of users and groups. One such suitable database schema 100, suitable for use in the security management application described hereinafter, is illustrated in FIG. 7, and includes a plurality of tables 102-134. Descriptions of the fields in each of tables 102-134 are presented below in Tables II-XVIII: Table 102 stores user information, and is formatted as shown in Table II:
TABLE II
gds_t_User
Column Name Description
User_Id Internal field for linking user to other database
objects.
Login_Name Login Name of a user.
Last_Name User's last name.
First_Name User's first name.
Initial User's middle initial.
Security_Admin Indicates whether user has Security Administrator's
privileges.
Directory_Admin Indicates whether user has Directory Administrator's
privileges.
Employee Whether user is an employee.
Status Indicates whether user is active or deleted.
Transaction_Date Date when the last transaction was committed by a
user.
Transaction_Owner_Id User_Id that committed the last transaction.
<additional fields> <additional fields as described above>
Table 104 stores information about which users are in which security groups, and is formatted as shown in Table III:
TABLE III
gds_t_Group_Memberships
Column Name Description
User_Id Internal field for associating user to a security group.
Group_Id Internal field for associating user to a security group.
Sub_Group The subgroup number of which the user is member of.
Status Determines whether member needs to added to a group
on the domains.
Table 106 stores information about security groups, and is formatted as shown in Table IV:
TABLE IV
gds_t_Group
Column Name Description
Group_Id Internal field for linking groups to other database
objects.
Group_Name Name of the security group.
Group_Description Description of the security group.
Group_Owner_Id Security group owner.
Total_Sub_Groups Total number of subgroups in which the security
group is divided into.
Membership_Classification Flag for classifying who can view group
memberships.
Rule_Classification Flag for classifying who can view group definition
criteria.
Membership_Type Flag to indicate whether group membership changes
automatically based
on attribute type, attribute value and user
associated attribute changes.
Group_Type Type of the group (global/local).
Group_Status Used for batch processing of group and membership
maintenance.
Membership_Status Flag to indicate whether group membership needs to
be adjusted.
Transaction_Date Date when the last transaction was committed by a
user.
Transaction_Owner_Id User_Id that committed the last transaction.
Table 108 stores information about which users are delegates of which security groups, and is formatted as shown in Table V:
TABLE V
gds_t_Group_Delegates
Column Name Description
Group_Id Group that the user is a delegate of.
Delegate_Id User that is delegate of the security group.
Table 110 stores information about which global groups are in which local groups, and is formatted as shown in Table VI:
TABLE VI
gds_t_Group_Hierarchy
Column Name Description
Local_Group_Id Local group that contains the global group.
Global_Group_Id Global group that is in the local group.
Hierarchy_Status Used for batch processing of group
maintenance.
Transaction_Date Date when the last transaction was committed
by a user.
Transaction_Owner_Id User_Id that committed the last transaction.
Table 112 stores information about domains, and is formatted as shown in Table VII:
TABLE VII
gds_t_Domain
Column Name Description
Domain_Id Internal field specifying a domain.
Domain_Name Domain name.
Domain_Type Domain type, e.g., NT or Notes.
Master_Domain Indicates whether this is the master (hub) domain.
Domain_Status Used for batch processing of group and membership
maintenance.
Transaction_Date Date when the last transaction was committed by a
user.
Transaction_Owner_Id User_Id that committed the last transaction.
Table 114 stores information about which security groups exist on which domains, and is formatted as shown in Table VIII:
TABLE VIII
gds_t_Group_Domains
Column Name Description
Group_Id Internal field for mapping security group to a
domain.
Domain_Id Internal field for mapping security group to a
domain.
GD_Status Used for batch processing of group
maintenance.
Transaction_Date Date when the last transaction was committed
by a user.
Transaction_Owner_Id User_Id that committed the last transaction.
Table 116 stores information about security group definition criteria, and is formatted as shown in Table IX:
TABLE IX
gds_t_Group_Definition
Column Name Description
Group_Id Group to which the definition belongs to.
Group_Condition_No Internal number as part of the primary key.
Attribute_Type_Id Attribute type that is used in defining criterion.
Attribute_Condition Comparison operator in group definition criteria.
(IS/IS NOT)
Attribute_Value_Id Attribute value used in group definition criterion.
Logic_operator Logical operator combining various attribute types to
form a group definition
criterion. (AND/OR)
Sort_Order Order in which attribute type criteria will be
displayed on security group
definition screen.
Transaction_Date Date when the last transaction was committed by a
user.
Transaction_Owner_Id User_Id that committed the last transaction.
Table 118 stores information about attribute types, e.g., "Organization," and is formatted as shown in Table X:
Table X
gds_t_Attribute_Type
Column Name Description
Attribute_Type_Id Internal field for associating attribute type with
users, security group
definitions and other database objects.
Attribute_Type_Name Name of attribute type, e.g., "Organization,
Function, etc."
Attribute_Type_desc Description of the attribute type.
Attribute_Data_Type Data type of the attribute.
Data_Length Maximum permissible length of the attribute value.
Control_Type Type of control that needs to be used to display
attribute value, e.g.,
"Text Box," "Check Box," etc.
Default_Value Default attribute value that will be displayed on
control.
Attribute_Type_Owner_Id Owner of the attribute type.
Attribute_Type_Status Used for batch processing of group and membership
maintenance.
Transaction_Date Date when the last transaction was committed by a
user.
Transaction_Owner_Id User_Id that committed the last transaction.
Table 120 stores information about which users can maintain attribute pick lists, and is formatted as shown in Table XI:
TABLE XI
gds_t_Attrribute_Delegates
Column Name Description
Attribute_Type_Id Attribute type that can be maintained by a user.
Delegate_Id User that can maintain the attribute type.
Table 122 stores information about which attribute values are associated with which user, and is formatted as shown in Table XII:
TABLE XII
gds_t_User_Attributes
Column Name Description
User_Attribute_Id Internal field to associate attribute value with user.
User_Id Internal field to associate attribute value with user.
Attribute_Type_Id Internal field to associate attribute value with user.
Attribute_Value_Id Internal field to associate attribute value with user.
User_Attribute_Status Used for batch processing of group and membership
maintenance.
Transaction_Date Date when the last transaction was committed by a
user.
Transaction_Owner_Id User_Id that committed the last transaction.
Table 124 stores information about valid attribute values associated with attribute type, and is formatted as shown in Table XIII:
TABLE XIII
gds_t_Valid_Attr_Values
Column Name Description
Valid_Attribute_Id Internal field to associate attribute value with
attribute type.
Attribute_Type_Id Internal field to associate attribute type with
attribute type.
Attribute_Value_Char String value for the attribute.
Attribute_Value_Date Date value for the attribute.
Attribute_Value_Number Integer value for the attribute.
Vaild_Attribute_Status Used for batch processing of group and membership
maintenance.
Transaction_Date Date when the last transaction was committed by a
user.
Transaction_Owner_Id User_Id that committed the last transaction.
Table 126 stores audit information about which users/global group is added and deleted from which security group, and is formatted as shown in Table XIV:
TABLE XIV
gds_t_Group_Memberships_Log
Column Name Description
Group_Id Internal field for associating user to a security
group.
Group_Name Name of the group for which membership was changed.
Member_Id User Id or Group Id for which membership was changed.
Member_Name Name of the member.
Member_Type Type of a member.
Sub_Group The subgroup number of which the membership was
altered.
Domain_Id Domain id on which the membership was altered.
Domain_Name Domain name on which the membership was altered.
Transaction_Status Membership added/deleted
Transaction_Date Date on which membership was changed.
Transaction_Owner_Id Id of the user that caused the membership changes.
Trigger_Flag Process that triggered membership changes, e.g.:.
0 - Member added because of new criterion added to a
group definition.
1 - Member added because of attribute association with
user.
2 - Member added because of global group added to a
local group.
3 - Member added because of existing group being
associated with new
domain in directory.
4 - Member deleted because deleted group definition
criterion.
5 - Member deleted because of attribute dissociated
from user.
6 - Member deleted because the user was deleted from
directory.
7 - Member deleted because the global group was
deleted from directory.
8 - Member deleted because the attribute type was
deleted from directory.
9 - Member deleted because the attribute value is
deleted from directory.
Table 128 stores auditing information about the creation and deletion of security groups on different domains, and is formatted as shown in Table XV:
TABLE XV
gds_t_Group_Log
Column Name Description
Group_Id Internal field for linking groups to other database
objects.
Group_Name Name of the security group
Domain_Id Domain Id on which the group was created or deleted
from.
Domain_Name Name of the domain on which the group was created or
deleted from.
Domain_Type Domain type, e.g., NT or Notes.
Master_Domain Indicates whether this is the master (hub) domain.
Group_Description Description of the security group.
Group_Owner_Id Security group owner
Group_Owner_Name Owner name for the group.
Membership_Classification Flag for classifying who can view group
memberships.
Rule_Classification Flag for classifying who can view group definition
criteria.
Membership_Type Flag to indicate whether group membership changes
automatically based
on attribute type, attribute value and user
associated attribute changes.
Group_Type Type of the group.
Group_Status Used for batch processing of group and membership
maintenance.
Transaction_Date Date when the last transaction was committed by a
user.
Transaction_Owner_Id User_Id that committed the last transaction.
Success_Flag Flag to identify whether the transaction was partial
or complete success.
Trigger_Flag Process that triggered the batch process for
maintenance of the groups
on domains, e..g:
0 - Group Added to domain because a new group was
created in
directory.
1 - Group Added to domain because an existing group
in directory was
associated with a domain.
2 - Group deleted from domain because a group was
deleted from
directory.
3 - Group deleted from domain because a group was
removed from a
domain in directory.
4 - Group was deleted from domain because the domain
was deleted
from directory.
Table 130 stores information about error messages that need to be displayed by the application for different errors, and is formatted as shown in Table XVI:
TABLE XVI
gds_t_Error_Code
Column Name Description
Error_Code Error Code.
Error_Message Error Message that needs to be displayed.
Table 132 stores system parameters that are used by the application, and is formatted as shown in Table XVII:
TABLE XVII
gds_t_Configuration
Column Name Description
Param_Key Key for the parameter.
Param_Value Value of the system parameter
Table 134 stores information on reports and reporting access, and is formatted as shown in Table XVIII:
TABLE XVIII
gds_t_Reports
Column Name Description
Report_Id Internal field specifying a report.
Description Report Description.
It will be appreciated that the definition of a suitable database schema for any specific application will be highly application dependent. Therefore, the invention is not limited to the particular schema disclosed herein. Utilization of the aforementioned dynamic group management system in a security management application 200 is illustrated in greater detail in FIG. 8. As shown in the figure, an LDAP hub directory 202, organized as discussed above in connection with FIG. 7, is populated with one or more group policies 204, representing the group configuration information described above, e.g., group membership criterion, domain selection criterion, distribution and synchronization rules, group ID, etc. Each group policy also includes security authorization information representative of the permitted and/or prohibited activities to be associated with the members of each group. In addition, user data 206 corresponding to one or more users is entered into the LDAP directory to create one or more user records representative of users capable of being authorized via security management. As shown in block 208, one or more groups are created based upon desired group policies, and selected users are dynamically added to the new groups based upon the membership criteria associated with the various new groups (as described above in connection with FIG. 6). The result of block 208 is the addition of new groups to the LDAP directory, now represented at 210. Next, as shown at block 212, the dynamic groups maintained in directory 210 may be pushed to one or more application-specific directories, and/or to one or more spoke directories. In the alternative, direct lookups to the hub directory 210 may simply be supported, e.g., via remote procedure calls or remote object invocations. Also provided to the end-use directory 212 (i.e., the hub directory, a spoke directory or an application-specific directory) is a security management process 214, represented by one or more Access Control Lists (ACL's). Each ACL typically includes a resource identifier, representing the resource(s) begin protected; a privilege identifier, representing what actions are permitted on the specified resource(s); and a list of authorized entities capable of accessing the specified resource(s) with the specified permitted actions. In the case of dynamic groups, the list includes a group ID for the dynamic group(s) to be associated with the ACL. Other entities, such as individuals and enumerated groups, may also be associated with an ACL as well. As shown in block 216, whenever an application needs to make a security check before performing a particular action, the application accesses the security management system to retrieve the ACL associated with that action. As is well known in the art of security management, the requested action will be permitted if the user is authenticated as having the appropriate rights based upon the appropriate ACL. In the case of a user that is a member of a dynamic group, therefore, the rights will be based upon a determination that the user is a member of a dynamic group having the appropriate authorization on an associated ACL. Otherwise, permission for the requested action is denied. FIG. 9 next illustrates another exemplary implementation of the invention in a content management system 220, i.e., to control the distribution of content to a user based upon the user's membership within a dynamic group. As shown in the figure, an LDAP hub directory 222 is populated with one or more group policies 224, representing the group configuration information described above, e.g., group membership criterion, domain selection criterion, distribution and synchronization rules, group ID, etc. In addition, user data 226 corresponding to one or more users is entered into the LDAP directory to create one or more user records representative of users capable of being authorized via content management. As shown in block 228, one or more groups are created based upon desired group policies, and selected users are dynamically added to the new groups based upon the membership criteria associated with the various new groups. The result of block 228 is the addition of new groups to the LDAP directory, now represented at 230. Next, as shown at block 232, the dynamic groups maintained in directory 230 may be pushed to one or more spoke directories. In the alternative, direct lookups to the hub directory 230 may simply be supported, e.g., via remote procedure calls or remote object invocations. Also provided to the end-use directory 232 is a content subscription process 234 that maps various content items to various dynamic groups. Each mapping may also include the specified permitted and restricted actions for the content. Thus, as shown in block 236, whenever an application needs to make a subscription check before pushing content to a particular user, the application accesses the content management system to determine whether the specified user is a member of a dynamic group mapping to the specified content. If so, the content is distributed. Otherwise, distribution is prohibited. FIG. 10 next illustrates yet another exemplary implementation of the invention in an electronic messaging or groupware system 240, i.e., to address messages to multiple users based upon those users' membership within a dynamic group. As shown in the figure, an LDAP hub directory 242 is populated with one or more group policies 244, representing the group configuration information described above, e.g., group membership criterion, domain selection criterion, distribution and synchronization rules, group ID, etc. In addition, user data 246 corresponding to one or more users is entered into the LDAP directory to create one or more user records representative of users capable of being authorized via content management. As shown in block 248, one or more groups are created based upon desired group policies, and selected users are dynamically added to the new groups based upon the membership criteria associated with the various new groups. The result of block 248 is the addition of new groups to the LDAP directory, now represented at 250. Next, as shown at block 252, the dynamic groups maintained in directory 250 may be pushed to one or more spoke or e-mail directories. In the alternative, direct lookups to the hub directory 250 may simply be supported, e.g., via remote procedure calls or remote object invocations. With the above-described directory structure, an e-mail tool 254 may select one or more groups and/or users from the directory for inclusion in an electronic message, in a manner generally known in the art. In addition, as shown at 254, the e-mail administrator may also configure the dynamic group management system to do direct LDAP lookups or have the dynamic groups pushed into the email directory. FIG. 11 next illustrates another exemplary implementation of the invention in a software distribution system 260, i.e., to control the distribution of software to a user based upon the user's membership within a dynamic group. As shown in the figure, an LDAP hub directory 262 is populated with one or more group policies 264, representing the group configuration information described above, e.g., group membership criterion, domain selection criterion, distribution and synchronization rules, group ID, etc. In addition, user data 266 corresponding to one or more users is entered into the LDAP directory to create one or more user records representative of users capable of being authorized via content management. As shown in block 268, one or more groups are created based upon desired group policies, and selected users are dynamically added to the new groups based upon the membership criteria associated with the various new groups. The result of block 268 is the addition of new groups to the LDAP directory, now represented at 270. Next, as shown at block 272, the dynamic groups maintained in directory 270 may be pushed to one or more spoke directories. In the alternative, direct lookups to the hub directory 270 may simply be supported, e.g., via remote procedure calls or remote object invocations. Also provided is a software distribution management process 274 that stores mappings between software products and groups. Each mapping may also include the specified permitted and restricted actions for the software product. The mappings are provided to an electronic software distribution database 276, which is accessible by software distribution logic 278 that distributes software to individuals by resolving group memberships through directory group lookups via directory 272. Yet another end-use application of dynamic groups is in business-to-business groups. Through the aforementioned distribution and synchronization functionality, multiple users that span multiple enterprises may participate in dynamic groups. Dynamic groups may therefore comprise extended bases of users, e.g., to link together various users such as buyers, purchasing agents, distributors, manufacturers, retailers, business partners, competitors, etc. to facilitate different business processes. Other end-use applications of dynamic groups will be apparent to one of ordinary skill in the art having the benefit of the instant disclosure. Therefore, the invention is not limited to the particular applications disclosed herein. WORKING EXAMPLE One specific security management application of a dynamic group management system may be configured to have the following functionality, and may be based upon the aforementioned architecture: 1. Directory services may have capability to generate and maintain groups and group memberships based on user attributes. 2. The groups and memberships may be propagated to `domains` (Notes servers, NT servers, or other `Spoke` servers which must support LDAP) including development and production environments. 3. May have ability to specify creation of Global or Local group. 4. May have capability to add one or many global groups to a local group. 5. Global group may be added to a local group by using "Global Group Name" as an attribute in group definition criteria while creating/modifying a local group definition. 6. The following security classifications may apply to security groups: 1. Group membership listings: 1. OPEN: List group memberships for all users. 2. CLOSED: Only group owner, delegates can list group memberships for the groups they own. 2. Viewing group security definition: 1. RULE-OPEN: All users can look at security group definition. 2. RULE-CLOSED: Only group owners and delegates can view group definition for any group. 7. Two types of groups may be supported: 1. "AUTOMATIC"--Group memberships are automatically adjusted whenever there is any change in attribute types, attribute values and/or user attributes. 2. "ONE-TIME"--Group definition criteria will be used only to speed up generation of this group. Group definition criterion is no longer applicable to the group once the group is created. The group memberships cannot be altered from directory. (Adding and deleting specific users to and from automatically created security groups may be done via using "user name" as an attribute in the group definition criteria.) 8. Groups and membership may be created and maintained via a scheduled batch process, or near real time. 9. Groups may be left in the `hub` where they can be read directly, or they can be pushed to `spoke` directories, which can exist anywhere (intranets, extranets, WWW, inside other enterprises, etc.) 10. Group memberships may always be same on all domains only with the exception of a non-existent user on a particular domain. 11. May have ability to modify group creation criteria and modifying criteria should result in altering group memberships through a modification process. 12. The following synchronization functionality may be available for synchronizing groups and memberships, created from directory, across domains and directory databases: 1. The Hub Directory may be the Master for synchronization logic. 2. For the groups in the directory the memberships on domains (target platforms like NT, Notes or `spoke` directories supporting LDAP) may need to be synchronized with memberships in the Hub directory database. A report may need to be generated to highlight the membership mismatches if they occur. 13. Groups that are in the directory and not on domains may need to be created on those appropriate domains. 14. Groups may get deleted in the directory only after they are deleted from all domains. 15. Security groups may not be effective dated. But attribute changes for effective dated attributes from an organization structure may automatically alter group definitions and group memberships. 16. Group Definition Criteria: 1. Group definition criteria may be based on one or more (any number) of user attributes. 2. Only criteria used for group definition are "value of attribute IS" and or "value of attribute IS NOT". 3. Group definition criteria may be a combination of multiple attributes with all "AND" or all "OR" conditions. 4. All attributes and their values for defining criteria may be selected from predefined values. 5. Effective dated group definition criteria. Other conditions such as ">", "<", "LIKE" etc. may be used. 17. Creating Groups/Group Memberships: 1. Only "Group Admins" may create a group. 2. May need separate "Group Admin" privileges to create global/local groups. 3. Partial success in creation of a group may be acceptable provided manual synchronization procedures are followed to salvage partially successful group creation scenarios. Partial success in group creation may be defined as (1) group is created at least on one domain and in the directory database for all domain; and (2) Creation of complete memberships in directory. If memberships are not successfully created on all domains, then synchronization tool may get memberships synchronized on different domains. 4. Groups cannot be renamed. 5. While creating group memberships, if a user does not exist on a particular domain, the user may not be a member of the group on that particular domain, but user will be a group member on the domains where he/she exists. 6. Global groups may need to be created on all master NT and Notes domains. 7. Global groups may be created only on NT master domains and can cause group creation on Notes domains. 8. Local groups may be created only on NT Resource domains and can cause group creation on other domains. 9. "Group Admins" can also specify that groups be pushed to `spoke` directory servers. 10. Where spoke servers exist, the InetOrgPerson Schema may be used as a mechanism for selecting users for inclusion in a group (manual or automatic). This implies that the Hub directory has read accesses to `spoke` directories, and may be managed as a manual work process. 11. Where spoke servers exist, the GroupofNames Object Class may be used as the target for creating groups. This implies that the Hub directory has write accesses to `spoke` directories, which may be managed as a manual work process. 18. Modifying Groups/Group Memberships: 1. Modifying group definition criteria may change group memberships accordingly. 2. Delegates as well as group owners may modify group definition criteria for the groups they own. 3. Modifying group definition criteria may generate audit log reflecting all the changes caused by changing the group definition criteria. 4. Modifying or deleting an attribute value associated with a user may result in changing group membership during a batch transaction for that user. 5. Changing global group definition criteria may generate a report of local groups affected by the change. This report and new rule for the global group definition may be communicated to group owners and delegates of the affected local group. 6. Changing membership should do the changes in directory database first and then on all the domains. If memberships are not successfully changed on all domains, then synchronization tool may get memberships synchronized on different domains. 7. Once created, global group may not be changed to local group and vice versa. 19. Deleting Groups/Group Memberships: 1. Only group owners may delete groups they own. 2. Groups may not be deleted from directory database until deleted from all domains. 3. Deleting a global group may generate a report of local groups affected by the deletion. This report will may be communicated to group owners and delegates of the affected local groups. 4. Deleting memberships may delete memberships in directory first and then on the domains. Synchronization may be done in case of partial success in deleting memberships. 20. Attribute Types and Attribute Values: 1. "Attribute type owner" may own attribute types and the pick list values associated with the attribute types he/she owns. 2. "Attribute type owner" may modify or delete attribute types and pick list values that he/she owns. 3. HR may assign or remove HR-related attribute values associated with users. 4. Attribute types and attribute values may be deleted even if they are assigned to a user. Group membership may be adjustable accordingly for the user via a batch process. 5. Attribute types or attribute values may be deleted even if they are used in the group definition criteria. The group definition and group memberships for the groups using the deleted attribute type/value may then be altered. The group may not be deleted even if there does not exist any members in the group. Notification may need to be sent to owners and delegates of altered groups. 6. From an HR perspective, security groups may be created for following criteria: 1. Users working for one or more organizations. 2. Scope (Global/Regional) 3. Business Unit 4. Function 5. Region 6. Role/Level 7. Home organization of positions 8. All users reporting directly to a position. 9. All users reporting directly and indirectly to a position. 10. Country 11. Office internal address 12. Employment Status 13. Employee/Contractor/EBP (external business partner) 14. Sitecode 21. Group Ownership/Delegates: 1. There may always be one owner for every group. 2. Ability to transfer ownership of a group. 3. Only group owner and "Directory Admin" may transfer ownership of group. 4. Ability to delegate group membership maintenance to other users or groups. 5. Only group owner may add or remove delegates for the groups they own. 6. Transferring group ownership may retain the delegates on the group. 7. Delegates may not manage other delegates. 22. Reporting (i.e., what information can be retrieved): 1. List of groups a user belongs to. 2. List of users in a group. 3. List of groups owned by an owner. 4. List of all users and roles for all administrative users. 5. List of delegates for a group. 6. List of all groups with their owners and delegates. Synchronization and Dynamic Updates The aforementioned exemplary security management application may include a Group Management Service (GMS) program and a Group Synchronizer Service (GSSYNC) program that cooperatively are used to dynamically update dynamic groups consistent with the invention. The GMS program may be responsible for maintenance of groups, and may generally operate by reading command-requests in a Global Directory Services (GDS) database functioning as a hub directory, and acting upon the commands, making group changes against the hub directory. Such changes may then be pushed out, selectively, to specific domains (e.g. Windows NT, Lotus Domino, ORACLE, or other LDAP directories functioning as spoke directories. Commands to the GMS program may be made by users via a thin-client (user-interface) component of the GDS system. Command-requests may be read, in turn, by GMS and transformed or deleted to acknowledge acceptance of the commands. The GMS may modify the groups and group membership on platforms (e.g., Notes and NT domains) as well as spoke directory servers, and record their states in the GDS database. For example, the status attributes discussed above in connection with FIG. 7 may be used to identify records to be operated upon by the GMS program, e.g., with a status of 0 when active and processed, and a status {character pullout}0 when some processing is required. The GMS program may be scheduled or near real-time, and may be implemented as a multi-threaded service that processes group changes and group memberships based on configurable parameters. The GSSYNC program may be configured as a process that operates in conjunction with the GMS program, but at a lower priority, running only run when the GMS program is not running. If the GSSYNC program is running when the GMS program begins execution, it may request that the GSSYNC program suspend or terminate itself to prevent potential group and membership conflicts between the two processes. A principal responsibility of the GSSYNC program may be to ensure that groups and their memberships are consistent with respect to the GDS database and the attendant domains. The GSSYNC program may be a configurable, multi-threaded service that processes an unlimited number of group and group membership changes per hour, by scaling that service through replication. GMS Program Functional Flow The following represents a conceptual view of the GMS logic. At the highest level, the GMS logic typically executes sequentially. However, for certain operations, the GMS program may spawn and synchronize multiple threads of execution to hasten adjustment of group membership lists. Additional worker threads may also be spawned to adjust group membership. The GMS program may be configured to execute the following steps each time it is scheduled to run: 1. Protect Against Synchronizer Conflict In general terms, the GMS program typically runs more frequently than the GSSYNC program, e.g,. once per hour vs. once per week. To prevent conflict, the GMS and GSSYNC programs are typically mutually exclusive, with the GMS program having higher priority. Thus, if the GMS program wishes to run but finds that the GSSYNC program is running, it should issue a request for the GSSYNC program to either suspend or shut down, and then retry the operation. In addition, this logic prevents multiple instances of the GMS program from executing simultaneously.
[START]
if GMS already running
exit
endif
if GSSYNC running
send GSSYNC request to suspend or shutdown
goto START
else
set GSSYNC lock to prevent GSSYNC from running
endif
2. Delete Groups This section honors command requests for group deletion:
for each group to be deleted:
del grp definition
del grp members
del grp delegates
if local grp
del grp hierarchy (global grps that may belong)
endif
for domains in which grp exists
if grp global
for any local grps possessing global grp
del global group membership on domain
endif
del grp from domain
del grp mapping for domain
log delete/result code
next
if no errors
del grp
del grp hierarchy
endif
next
3. Remove Group from Domain This section honors command requests to remove a group from a domain, where a domain is a target platform (e.g. NT or Notes Domino, or a spoke directory based on LDAP or other technologies). This task applies to both global and local groups.
for each group to be removed
del grp from domain
del grp map for domain
log result code
next
4. Delete Domains This section honors command requests to remove a domain from the system altogether.
for each domain to be removed
get list of grps mapped to that domain
for each grp
if grp global
for any local grps possessing global grp
del global group membership
next
endif
del grp from domain
del grp mapping for domain
log delete/result code
next
next
5. Delete Attribute Types This section honors command requests to delete attribute types; note that removing an attribute type can result in changed group memberships, based upon group definition criteria.
for each attribute type to be deleted
for each group that uses this attribute type
del group defn attributes that match attribute_type_id
next
delete user attributes that match attribute_type_id
delete attribute values that match attribute_type_id
delete attribute delegates
delete attribute types themselves
next
6. Delete Attribute Values This section honors command requests to delete attribute values; note that removing an attribute value can result in changed group memberships, based upon group definition criteria.
for each attribute value to be deleted
for each group that uses this attribute value in its defn
del group defn attr that match attribute_value_id
next
del user attributes that match attribute_type_id
reset default value for attribute_type_id
del attribute values that match attribute_type_id
next
7. Delete User Attributes This section honors command requests to delete user attributes; note that removing a user attribute can result in changed group memberships, based upon group definition criteria.
for each user attribute to be deleted
for each group that references this attribute_type with
this attribute value
determine whether user is added or dropped from the group
next
delete gds_t_user_attributes for this user attribute
next
8. Calculating Deltas for Memberships The membership generation process is initiated by a set of `deltas` (or changes to the desired group membership). Members to be removed are signified by a group membership status value of 2; members to be added are denoted by a group membership status of 1.
for each group
get list of current members
get list of new members based upon group defn criteria
discrepency-check:
generate list of members to remove
generate list of members to add
next
9. Add a Group to a Domain This section honors requests to add a group to a domain. This task applies to both global and local groups.
for each group to be added
create group on domain
update group status
get a membership list for this group
populate membership in the domain
if group is local
get list of global groups contained in this group
add global groups to domain
endif
next
10. Delete Global Groups from Local Groups Global groups may be permitted to be members of local groups (the converse is typically not true, however); it may be desirable to remove global groups from local groups, as follows.
For each global group to be deleted from a local group
For the local group for this record
For each domain
Remove global group from domain
Next
Delete gds_t_group_hierarchy record
Next
Next
11. Add Global Groups to Local Groups Addition of global groups to local groups occurs as follows.
For each global group to be added to a local group
For the local group for this record
For each domain
Add global groups from domain
Next
Update gds_t_group_hierarchy record.status
Next
Next
12. Adjust Membership on Domains or Spoke Servers This section honors the group membership `deltas` (or change requests) as represented in the membership table. Firstly, necessary group memberships are deleted. Secondly, requested group membership additions are made. Multiple, separate threads can execute the addition and deletion requests; however, each thread typically must deal with an independent group.
For each group member to be deleted
For the group, get list of domains
For each domain
Delete member from group
Next
Delete this group membership record
Next
For each group member to be added
For the group, get list of domains
For each domain
Add member to group
next
Next
14. Release Synchronizer Lock After executing the aforementioned sequence of operations, the GMS program may release its `lock` for GSSYNC program. In the remaining inactive time (between scheduled runs of the GMS program), the GSSYNC program is permitted to execute, honoring only active groups and memberships (status value set to 0). GSSYNC Program Functional Flow The following represents a generalized view of the GSSYNC logic. At the highest level, the GSSYNC logic may execute sequentially. However, for certain operations, GSSYNC program may be configured to spawn and synchronize multiple threads of execution to hasten adjustment of group membership lists. As needed, worker threads can be spawned to adjust group membership. The GSSYNC process may be configured to execute the following steps each time it is scheduled to run: 1. Protect Against Synchronizer Conflict As above with the GMS program, the GSSYNC program is required to verify the GMS program is not currently running.
[START]
if GSSYNC already running
exit
endif
if GMS running
exit
endif
2. Validate Global Groups This section determines whether all GDS global groups actually exist on all master domains. If they are not all present, GSSYNC program will create the groups on the appropriate domains.
fetch list of global groups from GDS
for each global group
for each master domain
if global group not present on domain
create global group on domain
record in GDS
endif
next
next
3. Validate Local Groups This section determines whether all GDS local groups actually exist on the specified domains. If they are not all present, the GSSYNC program may create the local groups on the appropriate domains.
fetch list of local groups from GDS
for each local group
for each domain registered for the local group
if local group not present on domain
create local group on domain
record in GDS
endif
next
next
4. Validate Global Group Membership This section synchronizes the membership of global groups based upon the membership lists maintained by the GDS.
For each global group
get a list of members for the group from GDS (status = 0)
for each master domain
get members of group on domain
next
discrepancy-check and build list of adds/drops
for all drop records
drop on specified domain
next
for all add records
add on specified domain
next
next
5. Validate Local Group Membership This section synchronizes the membership of local groups based upon the membership lists maintained by the GDS.
For each local group
get a list of members for the group from GDS (status = 0)
get a list of global groups for the group from GDS (status = 0)
for each domain
get members of group on domain
get global groups on domain
next
discrepancy check, build list of adds/drops
for all drop records
drop on specified domain
next
for all add records
add on specified domain
next
next
6. Release Synchronizer Lock After executing the sequence of operations, the GSSYNC program will release its `lock` for GMS. 7. Background Tasks Because it is of a lower priority, the GSSYNC program may execute a background thread that polls the GMS program synchronizer lock. If the GMS program synchronizer lock is set (indicating that the GMS program is requesting that GSSYNC program terminate), the GSSYNC program may terminate itself after safely finishing its current operation. The GMS and GSSYNC modules may not be configured to talk to the domains or directory services database directly. Instead, they may share domain and GDS database services which reside in a separate API. The following API functions may be provided for shared use by the GMS and GSSYNC modules: General Services Initialize--initializes communications with GDS and domains Log_error--logs an error message Log_group change--logs a group change to the GDS group log table Log_member_change--logs a member change to the GDS member log table Terminate--terminates communication with GDS and domains High-Level Services Group_ins--creates a group from any domain, records in GDS Group_del--deletes a group from any domain, records in GDS Member_ins--adds a member to a group, records in GDS Member_del--deletes a member from a group, records in GDS Group_list--lists groups present on any domain Member_list--lists members present on any domain GDS Access Services Ins--adds a new record to one of the GDS tables Upd--updates one or more records in GDS tables Del--deletes one or more records from the GDS tables SQL--retrieves information based upon a SQL query from GDS Notes Primitive Services (for Lotus Notes domains) NO_group_ins--adds a group to a Notes domain NO_group_del--deletes a group from a Notes domain NO_group_list--retrieves list of groups from Notes domain NO_member_ins--adds a member to a Notes domain NO_member_del--deletes a member from a Notes domain NO_member_list--retrieves list of group members from Notes domain NT Primitive Services (for Windows NT domains) NT_group_ins--adds a group to an NT domain NT_group_del--deletes a group from an NT domain NT_group_list--retrieves list of groups from NT domain NT_member_ins--adds a member to an NT domain NT_member_del--deletes a member from an NT domain NT_member_list--retrieves list of group members from NT domain Spoke Primitive Services SPT_group_ins--adds a group to a spoke directory SPT_group_del--deletes a group from a spoke directory SPT_group_list--retrieves list of groups a spoke directory SPT_member_ins--adds a member to a spoke directory SPT_member_del--deletes a member from a spoke directory SPT_member_list--retrieves list of group members from a spoke directory Arguments for the API functions typically vary based upon domain and required functionality (e.g., NT group functions will take a BOOL flag indicating global/local group status). In addition, Notes functions will typically automatically compensate for canonical naming issues (e.g., adding a member via NO_member_ins will automatically add a short and a long--canonical--name to the membership list). Various modifications may be made to the illustrated embodiments without departing from the spirit and scope of the invention. Therefore, the invention lies in the claims hereinafter appended.
|
Same subclass | ||||||||||