Centralized directory services supporting dynamic group membership

Abstract

A method whereby application and network services (such as access control and electronic mailing list servers) can use a directory service to define groups of directory members using a directory search specification evaluated at service delivery time (dynamic group membership.) Traditionally, network services have been delivered to groups of users defined in relatively narrow manners: either by keeping a list of all users who are members of the group, or by attaching specific group membership attribute information to the information maintained about each specific user. Dynamic group membership allows these services to be delivered to groups of users who can be defined by a completely arbitrary specification of user attribute information. For example, electronic mail can be sent to a group of users whose office was located in a certain building (specifically, whose office location attribute matched a specific value.) Another example is that users may be permitted to access a network service, such as a printer, based on whether the printer is in the same building as the user (specifically, whether the printer's location attribute matches the user's office location attribute).

Claims

What is claimed is:

1. A method for use in connection with application and network services to provide a directory service that defines dynamic groups of directory members, the method comprising the steps of:

defining a directory search specification for a dynamic group based upon user attribute information, where said dynamic group is any set of users in which membership is dynamically determined and in which groups of users are defined by said directory search specification;

evaluating said directory search specification at a service delivery time;

determining whether information maintained in a directory matches said directory search specification;

delivering said service to said dynamic group;

providing a directory server to maintain information about users; and

providing a messaging server that maintains information about groups in said directory server;

wherein when said messaging server sends a search specification to said directory server which causes said directory server to return a set of users or group objects; and

wherein said message server then causes said message to be sent to each of the users or groups returned by said search.

2. The method of claim 1, further comprising the step of:

providing a set of expressions and Boolean operations for use in a directory search.

3. The method of claim 2, wherein said expressions comprise any of:

equal=where an instance of the attribute exactly matches the value;

contains*which is used as a wild card to allow presence check, or partial matches;

sounds like.about.=which is used in name searches;

greater or equal>=which is used for numerical comparisons;

less or equal<=which is used for numerical comparisons;

an `!` operator which is used to negate any expression; and

`&` (and) and `.vertline.` (or) operators which are used in combining expressions.

4. The method of claim 1, wherein said dynamic groups may use any of a dynamic group filter and a tree structure in the creation of groups.

5. The method of claim 4, wherein said dynamic group filter provides set management by creating sets of members in said directory using said members attributes.

6. The method of claim 4, wherein said tree structure comprises parameters that are used to determine what portion of said directory tree to search.

7. The method of claim 1, further comprising the step of:

enumerating members of said dynamic group retrieving some piece of information on each group member.

8. The method of claim 7, wherein said group membership enumeration step further comprises the steps of:

reading said group;

retrieving membership criteria;

initiating a subsequent search based on said membership criteria is initiated; and

stepping through the results of said subsequent search to produce a membership list, along with any desired information for each member.

9. The method of claim 1, further comprising the step of:

verifying membership in said dynamic group.

10. The method of claim 9, wherein said verifying step further comprises the step of:

answering a query for a web page accessible only to members of a given group to ensure that a client requesting access is a member of said dynamic group in question.

11. The method of claim 1, further comprising the steps of:

examining a purported group member's entry to determine if it is within the scope of said group's membership criteria; and

searching said purported member's entry with a filter corresponding to said group's membership criteria;

wherein a successful return indicates group membership and an unsuccessful return indicates no group membership.

12. The method of claim 1, wherein each user is represented as an inetOrgPerson object; and

wherein a class of attributes mailRecipient object is combined with said inetOrgPerson object for a user to receive mail.

13. The method of claim 12, wherein said mailRecipient attributes define information which identifies any of the name of a messaging server that stores a user's mail, a user identifier used by said user to login to a messaging server; and electronic mail addresses that identify a specific user.

14. The method of claim 1, wherein a dynamic group may contain other groups.

15. An apparatus for use in connection with application and network services to provide a directory service that defines dynamic groups of directory members, comprising:

a directory search specification for a dynamic group based upon user attribute information, where said dynamic group is any set of users in which membership is dynamically determined and in which groups of users are defined by said directory search specification;

means for evaluating said directory search specification at a service delivery time;

means for determining whether information maintained in a directory matches said directory search specification;

means for delivering said service to said dynamic group;

a directory server to maintain information about users; and

a messaging server that maintains information about groups in said directory server;

wherein when said messaging server sends a search specification to said directory server which causes said directory server to return a set of users or group objects; and

wherein said message server then causes said message to be sent to each of the users or groups returned by said search.

16. The apparatus of claim 15, further comprising:

a set of expressions and Boolean operations for use in a directory search.

17. The apparatus of claim 16, wherein said expressions comprise any of:

equal=where an instance of the attribute exactly matches the value;

contains*which is used as a wild card to allow presence check, or partial matches;

sounds like .about.=which is used in name searches;

greater or equal>=which is used for numerical comparisons;

less or equal<=which is used for numerical comparisons;

an `!` operator which is used to negate any expression; and

`&` (and) and `.vertline.` (or) operators which are used in combining expressions.

18. The apparatus of claim 15, wherein said dynamic groups may use any of a dynamic group filter and a tree structure in the creation of groups.

19. The apparatus of claim 18, wherein said dynamic group filter provides set management by creating sets of members in said directory using said members attributes.

20. The apparatus of claim 18, wherein said tree structure comprises parameters that are used to determine what portion of said directory tree to search.

21. The apparatus of claim 15, wherein members of said dynamic group retrieving some piece of information on each group member are enumerated.

22. The apparatus of claim 15, wherein membership in said dynamic group is verified.

23. The apparatus of claim 15, wherein each user is represented as an inetOrgPerson object; and

wherein a class of attributes mailRecipient object is combined with said inetOrgPerson object for a user to receive mail.

24. The apparatus of claim 23, wherein said mailRecipient attributes define information which identifies any of the name of a messaging server that stores a user's mail, a user identifier used by said user to login to a messaging server; and electronic mail addresses that identify a specific user.

25. The apparatus of claim 15, wherein a dynamic group may contain other groups.

Description

BACKGROUND OF THE INVENTION

1. Technical Field

The invention relates to a method of improving administration and management of services provided in a network. More specifically, the invention relates to defining groups of users who access network services, or are provided network services, in such a way as to determine membership only when the service is requested or about to be provided, and to determine this membership based on a flexible specification of user or object attributes.

2. Description of the Prior Art

Traditional methods of identifying groups of users who are to receive network services can be classified as follows:

A group may be comprised of a list of members belonging to the group.

A user may be identified as a member of a group by having a specific attribute with a specific value identifying the user as a member of the group.

Static Lists

The Unix file system supports a groups permission model to specify who may access various files (and directories.) Each file is owned by a specific user and group. To determine whether a user can access a file, the user must be identified as its owner or must be in the list of users who belong to the group which owns the file.

Electronic mailing lists are maintained to allow electronic mail to be distributed to all users who are listed as members of the list. Systems such as majordomo implement mechanisms to maintain membership in the list on a user-by-user basis.

Calendaring software, such as Corporate Time from Corporate Software & Technologies Int. Inc., supports specific groups of users who may modify the schedule to a room or network resource, or who may be invited to a particular meeting.

While all of the above groups may contain other groups, they all require specific maintenance of membership information about the group. Specifically, whomever is a member of the group to receive access or service must be explicitly listed in the group itself, or as a member of a group which is listed as a member. Each time a user enters or exits an organization, the user must be specifically added to all appropriate groups, or specifically removed from such groups. As the number of different groups in an organization grows, this can be a major administrative burden.

While removal of user names from all groups can be automated, it is more difficult to automate entering users in all appropriate groups. Typically, information about who should and should not be entered in a group is distributed throughout an organization, and services for a new user can be made available relatively haphazardly, depending on when the administrative entity responsible for each group learns about a user and their need for service. In the case of mailing lists, an information service (for example) may never be made available to a user if the administrator fails to know that the user is entitled to the information (such as a contractor working in a building may not be entered in the mailing list for people who work in the building because the contractor is not administered by the same entity as everyone else in the building.)

Group Attributes

An alternative method of identifying group membership consists of adding specific group identification information to the collection of information about a user.

An example of physical group attribute identification involves issuing an employee identification badge or key. The user can be granted a service or admitted to a building upon presentation of the badge or by using the key to open a lock. In this case, control of a user's right to access requires providing or confiscating a physical token (the badge or key.)

Electronic badge sensor systems can now communicate to a centralized service to check whether the badge bearer can access a service or system. This access, however, is usually granted to a list of badges--which is identical to the group list method described above.

In digital certificate technology, groups can be identified as those people possessing certificates that have been signed by a specific certification authority (CA). For example, all company employees may be identified as those who possess certificates signed by the company CA. There is no need to consult a static list to determine membership in the company (the CA's signature is verified using algorithmic means.) While this is a very scaleable mechanism for identifying group membership it remains relatively rigid, i.e. the person is a member of the group or not.

It would be advantageous to provide a technique for defining groups of users who access network services, or are provided network services, in such a way as to determine membership only when the service is requested or about to be provided, and to determine this membership based on a flexible specification of user or object attributes.

SUMMARY OF THE INVENTION

The invention herein provides a technique, referred to as dynamic group membership, which is based on a more flexible model of specifying group membership. Specifically, a group member can be determined by whether the information maintained in a centralized directory service matches an arbitrary specification. Thus, instead of checking to see whether a user possesses a specific group attribute, dynamic group membership is determined by checking any user attribute.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration showing a view of a directory (partial contents);

FIG. 2 is an illustration showing a view of static groups (Engineering and Marketing Groups);

FIG. 3 is an illustration showing a view of dynamic groups (Engineering and Marketing Groups) according to the invention;

FIG. 4 is an illustration showing a view of a directory after updates;

FIG. 5 is an illustration showing a view of static groups (each group updated, three updates in this example);

FIG. 6 is an illustration showing a view of dynamic groups (no updates required) according to the invention; and

FIGS. 7a and 7b provide block schematic diagrams that show a presently preferred implementation of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention herein provides a technique, referred to as dynamic group membership, which is based on a more flexible model of specifying group membership. Specifically, a group member can be determined by whether the information maintained in a centralized directory service matches an arbitrary specification. Thus, instead of checking to see whether a user possesses a specific group attribute, dynamic group membership is determined by checking any user attribute.

For example, assume that a user has these attributes:

name

location

department

manager

There are at least three kinds of groups that can be driven from this attribute information:

Department groups--everyone with the same department.

Examples: Marketing, Engineering, Sales, Accounting.

Direct reports--everyone with the same manager.

Examples: Will Robinson's Staff, Seif Steiner's Staff, Judy Tomlin's Staff.

Building groups--everyone who works in the same building.

Examples: Building 12 List, Building 11 List.

When using static group lists, each of these groups is maintained separately. Thus, if a person moves from building 12 to building 11, that person must be removed from the Building 12 list and added to the Building 11 list. This requires two separate and unrelated administrative actions. When using dynamic groups, however, information need only be changed in a single place (i.e. the user's location is changed in their directory entry). Thereafter, if mail is sent to the Building 12 list, the user no longer receives it and, conversely, if mail is sent to the Building 11 list, it is automatically delivered to the user because the value of the user's location attribute matches that of Building 11 and not Building 12.

One advantage of the invention is apparent when adding or deleting users to or from a centralized directory service. When a user joins an organization, appropriate values are entered for the person's attributes. For example, a user might have the following attribute values, which might be entered at the time the person joins an organization:

name=Sam Spinoza

location=Bldg 12

department=Engineering

manager=Seif Steiner.

If the appropriate groups are defined using dynamic group membership, the administrative tasks are completed just by entering this attribute information. For example, the user is automatically a member of the Engineering group (assuming the Engineering group is dynamically defined as every user whose department is Engineering.) If static groups are used, there are at least three additional administrative tasks that must be performed (specifically, adding the user to each separate location, department, and manager list.)

In the above example, there is a relatively small number of groups to be maintained (e.g. Marketing, Engineering, Sales, Accounting, Will Robinson's Staff, Seif Steiner's Staff, Judy Tomlin's Staff, Building 11 List, Building 12 List). In general, the number of groups that can be dynamically defined can be (minimally) a function of all distinguishable values of each attribute and combinations thereof. This number grows very quickly as an organization grows, which makes maintaining group membership information incredibly burdensome without dynamic group membership.

The following example serves to emphasize how dynamic groups are much more powerful than static groups. Consider defining a group of "New Employees" who should receive (for example) introductory orientation messages. Defining and maintaining a dynamic group of employees hired in the last 30 days would be simple (assuming the directory maintained an attribute such as createdTime indicating when the object was created in the directory):

currentTime-createdTime<30 days

Trying to maintain the membership of such a group using static group technology requires that an administrator both update the list every time someone enters the company and remove older members on a regular basis.

As the above example suggests, dynamic groups are not limited to just looking for exact value matches for individual attributes. A rich set of expressions and Boolean operations are available in directory search mechanisms to create many combinations. The expressions used in dynamic groups (as implemented in an LDAP-based directory service in the. presently preferred embodiment of the invention) are:

equal=An instance of the attribute exactly matches the value

contains* Used as a `wild card` to allow presence check, or partial matches

sounds like.about.=Very useful for example in name searches

greater or equal>=For numerical comparisons

less or equal<=For numerical comparisons

The `!` operator is used to negate any expression, e.g. !(location=New York) means the location can be anything other than `New York`.

The `&` (and) and `.vertline.` (or) operators are used in combining expressions.

These operators can combine and modify the search expressions to give dynamic group specification even more expressive power. For example, if the directory service provides the following attributes:

PayGrade: (a numerical representation of a person's pay grade within the organization--From low of 1 to high of 10)

Location: (the plant in which the person works, e.g. London, England or New York, U.S.A)

If a user wanted to send mail to all people in the U.S.A. in the higher pay grades to notify them of stock blackout periods, a dynamic group could be created with a defining filter of:

(&(PayGrade>=8)(Location=*, U.S.A.)

Description of Information used in Defining a Dynamic Group

Dynamic groups use two paradigms in the creation of groups: filters and tree structure. The first paradigm can be thought of as set management. For example, take the following people in the directory:

            Person        Building           Department
            John          Building: 10       Engineering
            Jane          Building: 11       Dept: Sales
            Jim           Building: 10       Dept: Sales

    People in building 10            People in the Sales department
    John (Building: 10 Dept: Engineering)
                                     Jane (Building 11 Dept: Sales)
    Jim (Building: 10 Dept: Sales)   Jim (Building: 10 Dept: Sales)

                             TABLE A
         Attributes of an LDAP-based inetOrgPerson Object
    Attributes               Attribute Description
    Common Name              (Required) Defines the person's
                             common name.
    Surname                  (Required) Defines the person's
                             surname, or last name.
    BusinessCategory         Identifies the business in which the
                             person is involved.
    CarLicense               Identifies the person's car license plate
                             number.
    DepartmentNumber         Identifies the department for which the
                             person works.
    Description              Provides a text description of the
                             person.
    EmployeeNumber           Identifies the person's employee
                             number.
    EmployeeType             Identifies the person's type of
                             employment (for example, full time).
    FacsimileTelephoneNumber Identifies the person's fax number.
    GivenName                Identifies the person's given, or first,
                             name.
    HomePhone                Identifies the person's home phone
                             number.
    HomePostalAddress        Identifies the person's home mailing
                             address.
    Initials                 Identifies the person's initials.
    JpegPhoto                Contains an image in jpeg format.
    Location                 Identifies the location in which the
                             person resides.
    LabeledURI               Specifies a universal resource locator
                             that is relevant to the person.
    Mail                     Identifies the person's electronic mailing
                             address.
    Manager                  Distinguished name representing the
                             person's manager.
    Mobile                   Identifies the person's mobile phone
                             number.
    Organizational Unit      Identifies the organizational unit to
                             which the person belongs.
    Pager                    Identifies the person's pager number.
    PhysicalDeliveryOfficeName Identifies a location where physical
                             deliveries can be made.
    PostalAddress            Identifies the person's business mailing
                             address.
    PostalCode               Identities the person's business postal
                             code(such as a United States zip code).
    PostOfficeBox            Identifies the person's business post
                             office box.
    PreferredDeliveryMethod  Identifies the person's preferred method
                             of contact or delivery.
    RoomNumber               Identifies the room number in which the
                             person is located.
    Secretary                Identifies the person's secretary or
                             administrator.
    SeeAlso                  URL to information relevant to the
                             person.
    State                    Identities the state or province in which
                             the person resides.
    StreetAddress            Identifies a street address at which the
                             person is located.
    Acess Control Information Identifies access control information for
                             the person's entry.
    TelephoneNumber          Identifies the person's telephone
                             number.
    Title                    Identifies the person's title.
    UserID                   Identifies the person's user ID.
    UserPassword             Identifies the password with which the
                             person can bind to the directory.
    x500UniqueIdentifier     Undefined.


                         TABLE B
         Attributes of an LDAP-based mailRecipient Object
    Attributes               Attribute Description
    Common Name              (Required) Defines the person's
                             common name.
    Mail                     Identifies the person's electronic
                             mailing address.
    MailAccessDomain         Identifies the domain from which the
                             mail user can login to obtain mail.
    MailAlternateAddress     Identifies an alternate mail address for
                             address is acceptable.
    MailAutoReplyMode        Identifies the auto reply mode set for
                             the mail user.
    MailAutoReplyText        Contains the text sent when
                             autoreplying to mail sent to the user.
    MailDeliveryOption       Identifies the mail delivery mechanism
                             to be used for the mail user.
    MailForwardingAddress    Identifies a mail address to which the
                             user's mail is to be forwarded.
    MailHost                 Identifies the host on which the user's
                             mail account resides.
    MailMessageStore         Identifies the path to the directory
                             containing the user's mail box.
    MailProgramDeliveryInfo  Identifies commands used for
                             programmed mail delivery.
    MailQuota                Maximum disk space allowed for the
                             user's mail box.
    MultiLineDescription     Contains descriptive text regarding the
                             mail user.
    UserID                   Identifies the mail user's user ID.
    UserPassword             Identifies the password with which the
                             mail user can bind to the directory.


                         TABLE C
           Attributes of an LDAP-based mailGroup Object
    Attributes               Attribute Description
    Mail                     (Required) Identifies the list's electronic
                             mailing address.
    Common Name              Defines the list's common name.
    MailAlternateAddress     Identifies an alternate mail address for
                             the user.
    MailHost                 Identifies the host on which the user's
                             mail account resides.
    MgrpAllowedBroadcaster   URL identifying a mail user that is
                             allowed to send mail to the mail group.
    MgrpAllowedDomain        Domain from which users can send
                             mail to the mail group.
    MgrpDeliverTo            Dynamic group membership method of
                             identifying members of the mail group.
    MgrpErrorsTo             Mailing address to which mail delivery
                             error messages are sent.
    MgrpModerator            Mailing address to which rejected mail
                             messages are sent.
    MgrpMsgMaxSize           Maximum message size that can be
                             sent to the mail group.
    MgrpMsgRejectAction      Specifies the action to the taken in the
                             event that mail sent to the mail group is
                             ejected
    MgrpMsgRejectText        Contains the text to be sent in the
                             event that mail sent to the mail group is
                             rejected. Identifies a recipient of mail
                             that is sent to the
    mgrpRFC822Mail           Member mail group, but who is not in
                             actuality a member of the mail group.
    Owner                    Distinguished name that identifies the
                             mail group's owner.

• Inventors
  Fitler, Jr., William H.; Howes, Timothy A.; Steinback, Bruce L.;
• Assignee
  Netscape Communications Corporation (Mountain View, CA)
• Published
  Apr-2-2002
• Current US Classes:
  707/10
  707/104.1
  707/3
  707/6
  707/9
  709/201
  709/242
  709/244
• Application #
  177434
• International Classes
  G06F 017/30
• Field of Search
  707/3 707/10 707/6 707/9 707/203 709/225 709/226 709/201 709/229 709/206 709/212 709/242 709/244 379/10 713/167 705/42 705/54
• Examiner
  Corrielus; Jean M.
• Agent
  Glenn; Michael A.
• US Patent References:
  4925311
  5677851
  5687167
  5694393
  5748736
  5787442
  5991393
  5991807
  6018766
  6049799
  6061499
  6065054
  6092199
  6105027
  6192362