Rule based data management
Data is acquired for an Identity System based on a one or more rules. The data can be from the same Identity System Component, another Identity System Component or a component external to the Identity System. The acquired data can be used to populate an Identity Profile, configure a workflow, or provide information to any other object, process, component, etc. of the Identity System. In one embodiment, the present invention combines dynamic identity value substitution and directory filter rules to enable rule based identity management. It enables dynamic population of identity data and real-time routing for identity management workflows. In other embodiments, the present invention can be applied to systems other than Identity Systems.
Latest Oracle Patents:
- Partitioning documents for contextual search
- Systems and methods for identifying process flows from log files and visualizing the flow
- System and method for transaction continuity across failures in a scale-out database
- Clone-aware backup and restore
- Declarative method of grouping, migrating and executing units of work for autonomous hierarchical database systems
This application claims the benefit of U.S. Provisional Application No. 60/395,152, “Access and Identity System,” filed on Jul. 11, 2002, which is incorporated herein by reference.
BACKGROUND OF THE INVENTION1. Field of the Invention
The present invention is directed to technology for managing data using rules.
2. Description of the Related Art
With the growth of the Internet, the use of networks and other information technologies, Identity Systems have become more popular. In general, an Identity System provides for the creation, removal, editing and other managing of identity information stored in various types of data stores. The identity information pertains to users, groups, organizations and/or things. For each entry in the data store, a set of attributes are stored. For example, the attributes stored for a user may include a name, address, employee number, organization, region, telephone number, email address, user ID and password. The Identity System can also manage access privileges that govern what an entity can view, create, modify or use in the Identity System. Often, this management of access privileges is based on one or more specific attributes, membership in a group and/or association with an organization.
Entities managed by an Identity System may require access to or be associated with a variety of data and resources that may be internal or external to the Identity System. For example, a user may need job codes identifying tasks performed by resources, information about various resources, information from other entities managed by the Identity System, approval from other entities to perform tasks, cooperation from other entities to perform tasks, etc. These dependencies create management and maintenance problems for administrators of the Identity System. For example, when creating an entry for a new user, the person creating the entry needs to know which resources are available to that user and which other entities are associated with that new user (e.g. assistants, managers, partners, etc.). Additionally, as the information about resources and associated entities change, the entry for the new user must be updated.
Therefore, there is a need to provide an improved system for managing data in an Identity System that reduces the management and maintenance effort.
SUMMARY OF THE INVENTIONThe present invention, roughly described, pertains to technology for managing data using rules. For example, data is acquired based on one or more rules. The rules utilize information from an identity profile in the Identity System. The acquired data can be from the same Identity System Component, another Identity System Component or a component external to the Identity System. The acquired data can be used to populate an Identity Profile, configure a workflow, or provide information to any other object, process, component, etc. of an Identity System. In one embodiment, the present invention combines dynamic identity value substitution and directory filter rules to enable rule based identity management. It enables dynamic population of identity data and real-time routing for identity management workflow. In other embodiments the present invention can be applied to systems other than Identity Systems.
One implementation of the present invention includes accessing first data from a data unit, applying the first data to a rule, identifying additional data based on the rule and adding the additional data to the data unit. The additional data can be used to add values for attributes of an identity profile. Alternatively, the additional data can be used to add job codes or an identification of a resource to an identity profile. Based on the job code or the identification of the resource, a task can be provisioned for the particular resource.
Another implementation of the present invention includes accessing first data from a data unit, where the data unit is accessed as part of a workflow. The first data is applied to a rule. Additional data is identified based on the rule. The additional data is then used to perform the workflow.
The above described processes can be fully or partially performed by an Identity System. Alternatively, the above described processes can be performed by a system other than an Identity System.
The present invention can be accomplished using hardware, software, or a combination of both hardware and software. The software used for the present invention is stored on one or more processor readable storage media including hard disk drives, CD-ROMs, DVDs, optical disks, floppy disks, tape drives, RAM, ROM or other suitable storage devices. In alternative embodiments, some or all of the software can be replaced by dedicated hardware including custom integrated circuits, gate arrays, FPGAs, PLDs, and special purpose computers. In one embodiment, software implementing the present invention is used to program one or more processors. The processors can be in communication with one or more storage devices, peripherals and/or communication interfaces.
These and other objects and advantages of the present invention will appear more clearly from the following description in which the preferred embodiment of the invention has been set forth in conjunction with the drawings.
The present invention, roughly described, pertains to technology for managing data using rules. The present invention can also be used with many different systems. For example, the present invention can be used with an Identity System or an Access Management System. The present invention can also be used with other systems.
Web Server 18 is a standard Web Server known in the art and provides an end user with access to various resources via network 16. One embodiment includes two firewalls. A first firewall (see dotted lines) is connected between network 16 and Web Server 18. A second firewall (see dotted lines) is connected between Web Servers 16 and 18 and Access Server 34/Identity Server 40.
The Access System includes Access Server 34, Web Gate 28, and Directory 36. Access Server 34 provides authentication, authorization, auditing and logging services. It further provides for identity profiles to be used across multiple domains and for access based on a single web-based authentication (sign-on). Web Gate 28 acts as an interface between Web Server 18 and Access Server 34. Web Gate 28 intercepts requests from users for resources 22 and 24, and authorizes them via Access Server 34. Access Server 34 is able to provide centralized authentication, authorization, and auditing services for resources hosted on or available to Web Server 18 and other Web Servers.
The Identity System includes Web Pass 38, Identity Server 40 and Directory 36. Identity Server 40 manages identity profiles. An identity profile is a set of information associated with a particular entity (e.g. user, group, organization, etc.). The data elements of the identity profile are called attributes. An attribute may include a name, a value and access criteria. The Identity Server includes three main applications, which effectively handle the identity profiles and privileges of the user population: User Manager 42, Group Manager 44, and Organization Manager (also called Object Manager) 46. User Manager 42 manages the identity profiles for individual users. Group Manager 44 manages identity profiles for groups. Organization Manager 46 manages identity profiles for organizations and/or can manage any object. Identity Server 40 also includes Publisher 48, an application that enables entities to quickly locate and graphically view information stored by Directory 36. In one embodiment, Web Pass 38 is a Web Server plug-in that sends information back and forth between Identity Server 40 and the Web Server 20, creating a three-tier architecture. The Identity System also provides a Certificate Processing Server (not shown in
User Manager 42 handles the functions related to user identities and access privileges, including creation and deletion of user identity profiles, modification of user identity profile data, determination of access privileges, and credentials management of both passwords and digital certificates. With User Manager 42, the create, delete, and modify functions of user identity management can be set as flexible, multi-step workflows. Each business can customize its own approval, setup, and management processes and have multiple processes for different kinds of users.
Group Manager 44 allows entities to create, delete and manage groups of users who need identical access privileges to a specific resource or set of resources. Managing and controlling privileges for a group of related people—rather than handling their needs individually—yield valuable economies of scale. Group Manager 44 meets a wide range of e-business needs: easy creation, maintenance, and deletion of permanent and ad hoc groups of users who may be allowed or denied access to particular resources; modification and adaptation of groups and their access privileges with minimal disruption to the directory server's underlying schema; efficient addition and deletion of users from established groups; and delegation of administrative responsibility for group membership and subscription requests and approvals.
With Group Manager 44, companies (or other entities) can allow individual users to do the following: (1) self-subscribe to and unsubscribe from groups, (2) view the groups that they are eligible to join or have joined, and (3) request subscription to groups that have access to the applications they need. Multi-step workflows can then define which users must obtain approval before being added to a group and which can be added instantly. Group Manager 44 also lets organizations form dynamic groups specified by an LDAP filter. The ability to create and use dynamic groups is extremely valuable because it eliminates the administrative headache of continually keeping individual, static membership up-to-date. With dynamic group management features, users can be automatically added or removed if they meet the criteria specified by the LDAP filter. Dynamic groups also greatly enhance security since changes in user identities that disqualify someone from membership in a group are automatically reflected in the dynamic group membership.
The third application in the Identity System, Organization Manager 46, streamlines the management of large numbers of organizations and/or other objects within an e-business network, including partners, suppliers, or even major internal organizations such as sales offices and business units. Certain infrastructure security and management operations are best handled—or can only be handled—at the highest organizational unit level rather than at the individual or group level. Like User Manager and Group Manager, this application relies on multi-step workflow and delegation capabilities. Organization Manager handles the following administrative tasks: (1) organization lifecycle management, whereby companies can create, register, and delete organizations in their systems using customizable workflows; (2) maintenance of organization profiles on an attribute-by-attribute basis through self-service, delegated administration and system-initiated activities; (3) organization self-registration, whereby organizations such as business partners, customers and suppliers can self-generate a request to be added to the e-business network; and (4) creation of reusable rules and processes through multi-step workflows.
The various components of
The system of
To understand how the system of
With the system of
Authentication and Authorization decisions are based on policy domains and policies. A policy domain is a logical grouping of Web Server host ID's, host names, URL prefixes, and rules. Host names and URL prefixes specify the course-grain portion of the web name space a given policy domain protects. Rules specify the conditions in which access to requested resources is allowed or denied, and to which end users these conditions apply. Policy domains contain two levels of rules: first level default rules and second level rules contained in policies. First level default rules apply to any resource in a policy domain not associated with a policy.
A policy is a grouping of a URL pattern, resource type, operation type (such as a request method), and policy rules. These policy rules are the second level rules described above. Policies are always attached to a policy domain and specify the fine-grain portion of a web name space that a policy protects. In practice, the host names and URL prefixes from the policy's policy domain are logically concatenated with the policy's URL pattern. The resulting overall pattern is compared to the incoming URL. If there is a match, then the policy's various rules are evaluated to determine whether the request should be allowed or denied; if there is not a match, then default policy domain rules are used.
If the user successfully authenticates for the requested resource (step 62), then the method proceeds to step 74. Otherwise, the unsuccessful authentication is logged in step 64. After step 64, the system then performs authentication failure actions and Web Gate 28 denies the user access to the requested resource in step 66. In step 74, the successful authentication of the user for the resource is logged. The method then performs authentication success actions in step 76. In response to the successful authentication, Web Gate 28 then passes a valid authentication cookie to browser 12 (step 80), which stores the cookie. After passing the cookie in step 80, the system attempts to authorize in step 56.
In step 56, the method determines whether the user is authorized to access the requested resource. If the user is authorized (step 90), the method proceeds to step 92. Otherwise, the unsuccessful authorization is logged in step 96. After step 96, the method performs authorization failure actions (step 98) and Web Gate 28 denies the user access to the requested resource. If authorization is successful (step 90), then the successful authorization of the user is logged in step 92. Authorization success actions are performed in step 94. The user is granted access to the requested resource in step 95. In one embodiment of step 95, some or all of HTTP request information is provided to the resource. In one or more scenarios, the resource being accessed is the Identity System.
More information about authorization, authentication, an Access System and an Identity System can be found in U.S. patent application Ser. No. 09/998,908, “Support for Multiple Data Stores,” filed on Nov. 30, 2001, which is incorporated herein by reference in its entirety.
Both the Identity System and the Access System make use of Directory 36. A unit of information stored in Directory 36 is called an entry or identity profile, which is a collection of information about an object. The information in an entry often describes a real-world object such as a person, but this is not required. A typical directory includes many entries that correspond to people, departments, groups and other objects in the organization served by the directory. An entry is composed of a set of attributes, each of which describes one particular trait of the object. Each attribute has a type, one or more values, and associated access criteria. The type describes the kind of information contained in the attribute, and the value contains the actual data.
An entry in the directory has a set of attributes that are required and a set of attributes that are allowed. For example, an entry describing a person is required to have a cn (common name) attribute and an sn (surname) attribute. One example of an allowed attribute may be a nickname. Any attribute not explicitly required or allowed is prohibited.
Examples of attributes stored in a user identity profile include: first name, middle name, last name, title, email address, telephone number, fax number, mobile telephone number, pager number, pager email address, identification of work facility, building number, floor number, mailing address, room number, mail stop, manager, direct reports, administrator, organization that the user works for, region, department number, department URL, skills, projects currently working on, past projects, home telephone, home address, birthday, previous employers and anything else desired to be stored by an administrator. Examples of attributes stored in a group identity profile include: owner, name, description, static members, dynamic member rule, subscription policies, etc. Examples of attributes stored in a user organization identity profile include: owner, name, description, business category, address, country, etc. In other embodiments, less or more than the above-listed information is stored.
Each entity has a distinguished name (DN), which uniquely identifies the node. In one embodiment, each entry also has a relative name, which is different from all other relevant names on the same level of the hierarchy. In one implementation, the distinguished name (DN) comprises a union of the relative names up the tree. For example, the distinguished name of employee 1 (node 250) is
DN=CN=Empl, OU=OrgA, O=CompanyA, DC=entity,
where:
-
- DC=Domain Component
- O=Organization
- OU=Organizational Unit
- CN=common name.
There are many ways for an entity to access and use the Identity System. In one embodiment, the entity can access the Identity System's services using a browser. In other embodiments, XML documents and API's can be used to access the services of the Identity System. For example, an entity can use a browser by pointing the browser to Identity Server 40. The user will then be provided with a login page to enter the user's ID, password, type of user and application requested (optional). Upon filling out that information, the user will be authenticated and authorized (by the Access System) to use the Identity System. Alternatively, the Access System can be bypassed (or there may be no Access System) and the Identity System authenticates the user.
As described above, the Identity System of
By selecting My Identity tab 406, a user is provided with the information stored in that user's identity profile. Create User Identity tab 408 allows a user with the appropriate privileges to create a new user identity profile (e.g. with a workflow). Deactivate User Identity tab 410 allows a user with proper privileges to remove an identity profile from the directory. Substitute Rights tab 412 allows the user to indicate who can proxy that user and allows the user to be a proxy for someone else. Request tab 414 allows a user to monitor workflows that are in progress or recently completed. Depending on the user's privileges, by selecting request tab 414, the user can see all workflows that involve that user, that are started by that user, that affect that user or that the user has privileges to view. Request tab 414 will indicate workflows for which there is an outstanding action to be done by the current user. The user can select that workflow and perform the task.
Configure tab 416 allows a user to configure various options for User Manger 42. The user must have sufficient privileges to access Configure tab 416. The user can perform attribute access control, delegate administration, define workflows and set the search base. Attribute access control includes controlling who has view and modify permissions for each attribute. Attributes can be set at any and all levels in an organization. The configuration also allows the specification of an e-mail notification list when a change to an attribute is requested. Delegation administration includes delegating administrative tasks to local administrators. An entity can choose what rights to delegate, whom to delegate to, and the scope to delegate. Workflow definition includes defining workflows for a particular organization, defining who will be responsible for the workflow actions and/or defining who will be receiving notifications for the workflow actions. Setting the search base includes setting the search base for a particular organization, person or set of persons. This will localize access to ensure security.
Configure tab 440 allows an entity to provide attribute access control, delegate rights, define workflows and expand dynamic groups. Attribute access control includes controlling who has view and modify permissions for each attribute in group identity profiles. Additionally, e-mail notification lists can be created which are used to notify entities when a change to an attribute is requested. Administration tasks can be delegated to local administrators. An entity can choose what rights to delegate, who to delegate to, and what the scope of the delegation is. Workflow definition includes defining the workflows for a particular group. This includes defining who is responsible for the workflow actions and who will be receiving notifications for workflow actions. Note that some of the tabs and services may not be available to all entities, depending upon the privileges of those entities.
The Group Manager also allows user to subscribe and unsubscribe themselves to groups. With sufficient privileges, users can also view/add/remove/search members of a group,
Create Organizational Profile tab 446 allows a user to create new organizational objects, if the user has sufficient privileges. Request tab 448 allows a user to access pending workflows and workflows that have recently been finished that relate to organizational objects. Access to Request tab 448 can be restricted and/or limited depending upon users privileges. If a user has a step to perform for a workflow, it will be indicated by Request tab 448.
Configure tab 450 allows the entity to perform attribute access control, delegate administration, define workflows and define container limits. Attribute access control includes controlling who has view and modify permissions for each attribute of an organizational identity profile. In addition, an entity can specify an e-mail notification list when a change to an attribute is requested. Delegating administration includes delegating administrative tasks to local administrators. An entity can choose what rights to delegate, whom to delegate to, and the scope of the delegation. Workflow definition includes defining the workflows for a particular organization, including who will be responsible for the workflow actions and who will be receiving notifications for the workflow. Container limits includes controlling how many objects can be created in an organization. This would also include defining who will be receiving notifications that a container limit has been met, has been violated or is close to being met.
More information about integrated. Identity and Access Systems can be found in U.S. patent application Ser. No. 09/793,658, “User Authentication,” filed on Feb. 26, 2001, incorporated herein by reference in its entirety.
In one embodiment, each identity profile is an object stored in the directory. Each object is based on a class. When the system is configured, an administrator defines which class is to be used for users, which class is to be used for groups and which class is to be used for organizations. In one implementation there is one class used for users, one class for groups and one class for organizations. In other implementations, multiple classes could be used for each. Each class defines a set of attributes that can be used for that class. At installation, set-up, or at a later time, the required attributes for a class are configured.
In one embodiment, certain display types (for example, selection menu, radio button, and check box) allow (or some embodiments require) for the use of a filler, rule or list. In other embodiments, other display types can also allow for the use of a filter, rule or list to populate the attribute. A list is a static set of values. A filter is an LDAP (or similar) filter that is used to query the directory (or other data store) in order to build a list. For example, an administrator can create a filter to find every instance of objectClass=dialUpConnection and department=sales and build a list with the telephone numbers of the matching objects. A rule is a filter that includes dynamic substitution.
(&(objectClass=users)(OU=sales)(region=west)
Each of the variables (user, sales, west) are static variables that are typed explicitly. An example of a rule using dynamic variables is as follows:
(&(objectClass=users)(OU=$OU$)(region=$region$)
In the above rule, the variables $OU$ and $region$ are dynamic variables. The Identity Server will replace the dynamic variables with data based on the corresponding attributes in the identity profile. That is, a dynamic variable $OU$ represents the organization attribute for the identity profile under consideration. Therefore, $OU$ will be replaced in the rule with the actual value of the organization attribute for the identity profile under consideration. Similarly, $region$ will be replaced in the rule with the actual value of the region attribute in the identity profile under consideration. Note that $OU$ and $region$ are examples of abbreviations of attributes. Other abbreviations and attributes can also be used.
In step 566 of
Once an object class is configured, new objects can be created using that object class. Each of these new objects created is an Identity Profile stored in the Directory server (or other data store).
In step 600 of
In step 610, the filter for the attribute is run against the directory. That is, the filter statement is used to perform a query to find the appropriate objects in the directory.
In step 612, the attribute specified (see step 566) is accessed for each object returned in the result set of step 610. In step 614, each of the attributes accessed in step 612 are displayed. In step 616, one or more of the attributes are selected by the user for storage in the identity profile. For example, as discussed above, the filter may be used to access a list of potential managers. In one embodiment of step 616, the person creating the object may choose one or more of the managers. The name of the chosen manager is then stored in the manager attribute. In other embodiments, the choice may be made automatically, or all of the returned managers can be automatically chosen. Note that the data that is searched in the directory in step 610 can be data for the application being used to create the identity profile or can be for another application that also uses the directory store. In other embodiments, the filter can be run against a different data store.
Steps 632-642 are used for attributes that are based on rules. In step 632, the Identity Server accesses the attributes that are specified in the rule using dynamic variables. That is, the rule may include one or more dynamic variables. Each of the dynamic variables specifies an attribute in the identity profile under consideration. Step 632 includes the Identity Server accessing the actual values of the attribute specified by the dynamic variable. Thus, if the dynamic variable is $OU$, then the Identity Server will access the attribute OU (which is Organizational Unit). In step 634, the data accessed from the attributes in the previous step will be applied to the rule. That is, a filter will be created by replacing the dynamic variables with the data from the accessed attributes. In step 636, the filter will be run against the directory (or other data store). This is similar to step 610. The result of the query is a result set. Each of the items in the result set will be accessed in step 638 in order to read the specified attribute (see step 566) for that particular entry. The specified attributes of the result set are displayed in step 640. One or more of the displayed attributes can be selected in step 642 for storage in the identity profile. In other embodiments, there is no selection of attributes. Rather, they automatically populate the identity profile.
One example of using rules to provide additional information into an identity profile is to provide a list of potential managers, as discussed above. An example of such a rule to do so could be as follows:
(&(objectClass=users)(OU=$OU$)(region=$region$)(title=Manager))
With this rule, the attribute specified in step 566 would be the names or distinguished names of the person associated with the objects in the result set.
Another example may be to identify certain business partners to be associated with a user. To do so, an administrator may use the following rule:
(&(objectClass=partners)(OU=$OU$)(region=$region$))
With this rule, the attribute configured in step 566 may include the name or distinguished name of the partner. Note that the object class is set to “partners.” In one embodiment, it is contemplated that there will be an object class for storing information about each of the business partners. All of the objects created for that object class will be searched to find the appropriate objects having the same organizational unit and region as the identity profile under consideration. For those that meet the test, the name stored in those identity profiles will be reported and used to populate the Business Partners attribute of the identity profile being created or modified.
A lot of the tasks that are performed in the Identity System are accomplished using workflows. A workflow is a predefined set of steps that perform a specific task, where information or tasks are passed between participants and programs according to a defined set of rules. One embodiment of the present invention supports the following types of workflows: create object; delete object; change the value of attributes; and certificate issuance, revocation and renewal. In one embodiment of the present invention, a user is required to create a workflow to create or delete an object, change the value of an attribute or implement certificates. Workflows ensure that an organization's guidelines for performing a task are met. Workflows can be defined in the User Manager, Group Manager or Organization Manager. Each workflow has two or more steps, including one to start the action and one to implement or commit it. Each step can contain an action, send e-mail notifications to selected persons and start the next step if its entry conditions are satisfied.
Table 1 provides examples of different tasks that can be performed with workflows in the appropriate applications:
Each workflow includes two or more steps. Each step can include one or more actions. Table 2, below, provides examples of different actions that can be performed with various types of workflows:
Table 3 provides a description of the various actions:
Workflows are created based on templates (forms) by users with sufficient privileges. In one embodiment, each template has at least four sections including a section for creating objects, deleting objects, changing attributes and working with certificates. The template provides parameters that define how workflows can be created. Templates can be edited in order to tailor the workflow definition processes. The User Manager, Group Manager and Organization Managers each have their own template files and use those template files to control and define the workflow definition process. In one embodiment, the template file is an XML document that defines a set of parameters for each of the actions available to that particular workflow type. Table 4 describes the various parameters that are used in the template files:
Below is a generic form of a template. In the left hand margin is a letter to identify each line of the template for explanation purposes:
Generic Template©Oblix, Inc., 2001
The first line labeled (a) indicates the workflow type, which includes creating an object, deleting an object, changing attribute or certificates. Lines (b-u) define the parameters for one particular action. One or more of the parameters described above are defined in lines (b-u) for one action. For example, line (d) puts a value into the occurrence parameter, line (e) provides a value for a user action and line (f) provides a value for forceCommit. Lines (h-k) provide the various pre-actions that have to occur before the particular action is performed. Lines (l-o) provide exit conditions. While the generic template above shows line (b-u) for one particular action, a typical template would have parameters for many actions. One template is likely to be used to create many workflows.
In step 790, the system receives a selection of the attributes and the types from the user. That is, the user will select which attributes are optional, which attributes are required and which attributes are supplied. An attribute is supplied if it is provided from another workflow. In other embodiments, other types can be used. In step 792, the participants who can perform the current step being defined are identified. In step 794, pre and post notifications are specified. A pre-notification means that prior to the step being performed the following set of users are sent an e-mail (or other form of communication). Post notification means that after the step has being completed the following individuals are sent an e-mail (or other form of communication).
If there is another step in the workflow (step 796), then the method loops to step 798; otherwise, the process of
In one alternative, each subflow (for a step that has multiple subflows) can be associated with a separate entry condition. In such an embodiment, the user can individually select whether to wait for each subflow
A subflow is a workflow that is initiated by another workflow. The concept of subflow was introduced and implemented to reduce administrative work. If a workflow already exists to perform a task, any other workflow that needs to perform that task should be able to leverage off the first workflow. When creating a workflow, an indication that there is a sub-workflow is provided by the creator of the workflow when the creator indicates that one or more of the variables are supplied.
The workflow that initiates the subflow is referred to as the parent workflow. A workflow can be both a parent workflow to a first workflow and a subflow to a second workflow. The parent workflow may or may not wait for the subflow, as defined in the workflow creation. Consider the following example, a company uses a first workflow to create new users for the Identity System and add the new user's identity profile to the directory. As part of its process, the new user workflow obtains the new user's telephone number. The obtaining of the new user's telephone number is accomplished by performing a new telephone number workflow. In this example, the new telephone number workflow is initiated by a step in the new user workflow. Therefore, the new telephone number workflow is a subflow of the new user workflow. In one alternative, the new telephone number workflow can also call a subflow, for example, to get a new telephone line connected and operational. This, second subflow can also call a subflow, and so on. There can be many levels of nesting of subflows. Additionally, a parent workflow can have many subflows.
In one embodiment, a parent workflow and its subflows must all be performed by the same application. For example, the all must be performed by the User Manager. Or, they must be performed by the Group Manager, etc.
In some situations, a workflow is requested without knowing the location of the target identity profile (e.g., the identity profile being created). For example, a user can request to create an object without indicating where to store the object in the directory. In such a scenario, the system will find and report workflows that perform the requested task and can be accessed by the user. When the system reports the list of workflows (e.g. via a GUI), the system will also report the domain associated with each workflow. In this situation, step 846 includes the system receiving a selection from the user of the workflow desired, and the domain to operate on.
In step 846, the system receives a selection from the user of the work flow desired. Note that if step 844 only identified one workflow, then step 846 can be skipped or performed automatically. In step 850, it is determined whether the user is allowed to perform this workflow step. If not, the process of
In step 854, pre-notifications, if any, defined in the workflow are sent out. In step 858, the current step of the workflow is performed. For example, an action is performed In step 860, it is determined whether there are supplied variables. When creating a workflow, the creator had the option of defining the types of variables. Supplied variables are those variables whose value will be supplied by a subflow. If the current step has a supplied variables, then the system searches for any workflows that can supply the variable and apply to the appropriate domain. If only one workflow is found for each supplied variable, then those workflows are initiated as a subflow in step 862. If multiple workflows are found for a particular supplied variable, then the user is given a choice and the chosen workflow is initiated as a subflow in step 862. Note that the subflow could itself have a subflow, which could itself have a subflow, and so on. There is no limitation on the number of subflow nestings.
If there are no supplied variables, or after the subflow(s) are started, then post step notifications are sent out, if any, in step 866. In step 868, the next step is accessed from the workflow definition. If there are no more steps, then the process of
In step 874, the system determines whether the user is allowed to perform the next step. If not, the process of
Note that different steps may be set up for performance by different users. Thus, a first user may start the workflow but a different user or a different set of users may be needed for intermediate or later steps. Therefore, the process of
If the participant is not specified by a name (step 1000), then it is determined whether the participant is specified by an identification of a group (step 1010). If the participant is specified by identification of a group, then in step 1012, the members of the group are identified. In step 1014, it is determined whether the particular entity attempting to perform the step of the workflow is a member of that group. If so, that entity is allowed (step 1016) to perform the step. If not, the entity is not allowed to perform the step of the workflow (step 1018).
If the participant is specified by a filter (step 1030), then that filter is applied to the identity profile of the entity attempting to perform the step of the workflow (step 1032). If that entity's identity profile satisfies the filter, then that user is allowed to perform the workflow in step 1036. Otherwise, the user is not allowed to perform the step of the workflow (step 1038).
If the participants are specified by a rule (step 1040), then the rule is evaluated to identify the dynamic variables and access the attributes, corresponding to the dynamic variables, of the identity profile that is the subject of the workflow. Those accessed attributes are used to populate the rule in step 1044 in order to create a filter. The filter is applied to the identity profile of the user attempting to perform the step of the workflow. If the identity profile of the user attempting to perform the workflow satisfies the filter, then that user is allowed to perform the step of the workflow (step 1050). Otherwise, the user is not allowed to perform the workflow (step 1052).
One popular application for using workflows is to create a new user.
(&(objectClass=users)(title=admin)(OU=$OU$)(region=$region$))
The above rule indicates that a pre-notification will be sent to all users who have a title of “admin” and are in the same organization as the newly created user and have the same region as the newly created user. Thus, the pre-notification may be sent to more than one manager or only one manager, depending on how many users satisfy the rule. The Identify Server will access the rule, identify the two dynamic variables ($OU$ and $region$), and replace those two dynamic variables with data from the identity profile being created. Once the dynamic variables are replaced, the rule has become the following filter:
(&(objectClass=users)(title=Admin)(OU=Marketing)(region=West)).
The above filter is used to perform a query which identifies a set one or more managers, which are then sent a pre-notification. In step 110, the manager (or managers) who is pre-notified approves the new user. In step 112, the new user is completely created and stored in the directory.
More information about workflows can be found in U.S. patent application Ser. No. 09/998,910, “Template Based Workflow Definition,” filed on Nov. 30, 2001, incorporated herein by reference in its entirety.
Entities managed by the Identity System may require access to a variety of resources that are external to the Identity System. For example, a user may need a telephone connection and/or accounts on various computer systems. A person working as an Identity System administrator can manually submit a request for the necessary external resources to one or more external provisioning systems. Alternatively, that request can be submitted automatically or semi-automatically.
A provisioning system services resource requests by establishing external resource access for an entity, such as an Identity System user. Most provisioning systems include one or more agents with each agent corresponding to an external resource. For each requested resource, the provisioning system assigns an agent to make the resource available to a specified entity. In one example, the provisioning system receives a request to establish a computer system account and telephone connection for a user. The provisioning system assigns one agent to create the computer account and another agent to create the telephone connection. Provisioning systems are also capable of terminating an entity's resource access. One implementation of an Identity System includes a Provisioning Bridge Server to manage communications with the provisioning systems—enabling the Identity System to automate the use of multiple provisioning systems.
Provisioning system 1210 includes agents 1212, 1214, and 1216. Provisioning system 1220 includes agents 1222, 1224, and 1226. Provisioning systems 1210 and 1220 receive requests from Provisioning Bridge Server 1198 to allocate or eliminate access to external resources for entities managed by the Identity System, such as users. Examples of external resources include applications and operating systems on computer systems and telephone connections. Provisioning systems 1210 and 1220 delegate each request they receive to an agent that is adapted to interface with the requested resource. Provisioning system 1210 may allocate a task to agent 1212, 1214, or 1216. Provisioning system 1220 may allocate a task to agent 1222, 1224, or 1226. As shown in
Multiple provisioning systems may be required to support all of the resources employed by the Identity System's entities. For example, provisioning system 1210 may only have agents that interface with engineering related external resources, and provisioning system 1220 may only have agents that interface with marketing related external resources. In one example, provisioning system 1210 employs agents 1212, 1214, and 1216 to provide and remove access to engineering related resources 1211, 1213, and 1215. Provisioning system 1220 employs agents 1222, 1224, and 1226 to provide and remove access to marketing related external resources 1221, 1223, and 1225.
Provisioning Bridge Server 1198 facilitates the Identity System's automated use of multiple provisioning systems 1210 and 1220. Provisioning Bridge Server 1198 maintains control information 1200, which correlates the external resources used by Identity System entities with the various provisioning systems. During operation, the Identity System may need to have a resource related task performed, such as providing an entity with access to a resource or eliminating an entity's access to a resource. Provisioning Bridge Server 1198 identifies the proper provisioning system for performing the resource related task and submits a request to the proper provisioning system to perform the task. Provisioning Bridge Server 1198 employs control information 500 to identify the proper provisioning system for performing the desired task.
In one implementation, control information 1200 includes entries with the following fields: 1) Job Code—identifying a classification assigned to an entity in the Identity System based on the entity's role in one or more organizations; 2) Viewable Domain—identifying the domain which can potentially have access to an IT Resource and; 3) IT Resource—an IT resource, including peripherals, computing devices, applications, data stores and other resources. This only provides one example of fields for control information 1200. Alternate embodiments of control information 500 may include numerous other configurations that correlate job codes, external resources, and provisioning systems.
Table 6 below shows one example of content stored in control information 500:
Table 6 shows that provisioning bridge server 1198 needs to arrange for entities with job code A to receive access to IT resources NT1, Unix 22, and SAP. For example, NT1 can be a server running Windows NT, Unix 22 can be a server running the Unix operating system, and SAP can be an application. Entities with job code B are to be provided access to IT resource WINXP34 (e.g., computer running Windows XP). In one embodiment, providing access includes setting up an account for the appropriate user. The accounts can be set up by accessing the user identity profile in order to determine or read a username and/or password. In other embodiments, a random username and password/or can be created.
By employing job codes, the Identity System can provide entities, such as users, with a label that corresponds to the external resources the entity needs. The Identity System can assign job codes to an entity based on the role the entity plays in the organization managed by the Identity System. In one implementation the Identity System sets job codes for an entity based on the groups to which the entity belongs. The Identity System associates a job code attribute with an entity to identify all of the entity's job codes.
In one embodiment, an attribute can only be changed using a workflow. In other embodiments, an attribute can be changed using a user interface, without a workflow. In some embodiments, only users with appropriate access privileges can change an attribute. In some embodiments, attributes can only be changed with approval from a list of users (e.g. managers, administrators, etc.). The control information (discussed herein) is updated periodically. In some embodiments, the control information is updated automatically. In other embodiments, an administrator must manually update the control information.
If there are tasks that have not yet been assigned to a provisioning system, Provisioning Bridge Server 1198 submits a request to one of the provisioning systems to perform a provisioning task (step 1340). Provisioning Bridge Server 1198 submits the request to the provisioning system that is identified in control information 1200. After the task request is submitted, Provisioning Bridge Server 1198 determines whether any other provisioning tasks still need to be assigned to a provisioning system (step 1342).
Once all of the job code related tasks have been assigned, Provisioning Bridge Server 1198 waits for the requested tasks to be completed (step 1344), regardless of whether they have failed or completed successfully. In one implementation, each provisioning system signals when a task has been completed—indicating whether it completed the task successfully or failed. Provisioning Bridge Server 1198 determines whether any of the tasks failed (step 1346). If none of the tasks failed, Provisioning Bridge Server 1198 signals that the provisioning tasks have all been successfully performed (step 1350). If any of the tasks failed (step 1346), Provisioning Bridge Server 1198 determines whether to continue with provisioning or cancel all provisioning (step 1348). If Provisioning Bridge Server 1198 is not to proceed with provisioning, a provisioning error is signaled (step 1352). In some embodiments, Provisioning Bridge Server 1198 may also undo tasks that have already been completed. In one implementation, Provisioning Bridge Server 1198 also provides a signal identifying the failed tasks (step 1352). The criteria for determining whether to continue in step 1348 can be set by a system administrator when the Identity System is initialized. Alternatively, Provisioning Bridge Server 1198 can send a message to a system administrator and wait for the reply to indicate whether to continue. Various other methods can be employed for making this determination.
In further embodiments, Provisioning Bridge Server 1198 does not submit all of the task requests and wait for their completion before proceeding. Instead, each task request is assigned to a separate thread of operation and proceeds individually. In one implementation this processing occurs in parallel. In yet another implementation, this processing occurs serially.
One example of provisioning is to automatically provide access to IT Resources for a particular user. For example, a new user can be created using a workflow. As part of the workflow, the user's name, title, address, and organization are entered into the identity profile. An attribute of the user's identity profile called IT Resources can be configured, as described above, to be populated based on a rule. One example of such a rule is the following:
(&(objectClass=OBESSJCMAPPING)(obViewableDomain=$OU$)
This rule indicates that there will be a search through the directory for all objects of the objectClass OBESSJCMAPPING. Each object having a viewable domain equal to the organization name stored in the organization attribute of the newly created user will be returned. In one embodiment, the returned attribute will be one or more IT Resources. For example, Table 6 above provides a portion of a set of objects (OBESSJCMAPPING objects) that are stored in the directory. Those objects having the appropriate viewable domain will be returned. The identified attribute specified can be the IT Resource. In other embodiments, the identified attribute specified can be the job code. The returned IT Resources or job codes are then provided to an administrator, user, etc. This administrator, user, etc. can select the appropriate IT Resources or job codes. In other embodiments, all of the returned IT Resources or job codes will automatically be populated into the new user's IT Resource attribute, with no selection being made by the administrator, user, etc. Once the attribute is populated, a provisioning task can be started to provide the user with accounts on the IT Resources identified in the user's IT Resource attribute.
More information about provisioning tasks can be found in U.S. patent application Ser. No. 10/145,684, “Employing Job Code Attributes In Provisioning,” filed on May 15, 2002, incorporated by reference herein in its entirety.
The foregoing detailed description of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto.
Claims
1. A method for performing rule-based identity management, comprising:
- receiving, at an identity server, a request to add data to an identity profile for an entity, wherein the identity profile is stored as an object in a directory, wherein the directory comprises a database for storing one or more identity profiles, wherein the identity profile object is based on a class, wherein the class defines one or more attributes for the identity profile object such that the identity profile comprises one or more attributes, wherein the class defines a rule for a first attribute having one or more dynamic variables for a first attribute;
- receiving an attribute value for a second attribute of the identity profile object;
- accessing the class for the identity profile object;
- reading the rule having one or more dynamic variables from the class;
- automatically accessing the attribute value for the second attribute of the identity profile object based on the dynamic variable in the rule;
- automatically applying the attribute value rule by replacing a dynamic variable in the rule with the attribute value of the second attribute to create a filter;
- identifying additional data based on the filter, wherein identifying the additional data comprises: using the filter to perform a query against the directory with the first-data to find a set of one or more objects in the directory matching the filter; receiving an identification of a particular attribute in each of the one or more objects matching the filter; accessing, for each of the one or more objects, the particular attribute to generate a list of one or more values, each value corresponding to the particular attribute in one of the one or more objects; displaying, for a user, the list of one or more values; and receiving a selection of one or more values from the list of values; and
- adding the additional data to the identity profile, wherein the step of adding includes adding the selected one or more values to the first attribute in the identity profile.
2. A method according to claim 1, further comprising:
- receiving the rule; and
- receiving the attribute identification.
3. A method according to claim 1, wherein:
- the additional data includes one or more job codes.
4. A method according to claim 1, wherein:
- the additional data includes an identification of a resource external to a system that is performing the steps of accessing, applying, identifying and adding.
5. A method according to claim 1, wherein:
- the additional data includes an identification of a first resource.
6. A method according to claim 1, wherein:
- identifying additional data includes using the rule to search for control information about a set of resources.
7. A method according to claim 5, further comprising:
- sending a request for the first resource in response to the step of adding.
8. A method according to claim 5, further comprising:
- provisioning a task related to the first resource in response to the additional data.
9. A method for performing rule-based identity management, the method comprising:
- receiving, at an identity server, a request to add data to an identity profile for an entity, wherein the identity profile is stored as an object in a directory, wherein the directory comprises a database for storing one or more identity profiles, wherein the identity profile object is based on a class, wherein the class defines one or more attributes for the identity profile object such that the identity profile comprises one or more attributes, wherein the class defines a rule having one or more dynamic variables;
- accessing the class for the identity profile object;
- reading the rule having one or more dynamic variables from the class, wherein the class defines one or more dynamic variables comprising a first dynamic variable that corresponds to a region attribute, a second dynamic variable that corresponds to an organization attribute, and a third dynamic variable that corresponds to a group attribute in the identity profile object for the entity;
- receiving a first set of attribute values for the first dynamic variable, the second dynamic variable, and the third dynamic variable of the identity profile object;
- storing the first set of attribute values;
- automatically accessing the attribute values for the first group of dynamic variables of the identity profile object based on the dynamic variable in the rule
- automatically applying the first set of attribute values to the rule by replacing the first dynamic variable with a value stored for the region attribute, replacing the second dynamic variable with a value stored for the organization attribute and replacing the third dynamic variable with a value stored for the group attribute in the identity profile object to create a filter;
- identifying additional data based on the filter, wherein identifying the additional data comprises: using the filter to perform a query against the directory with the first set of attribute values to find a set of one or more objects in the directory matching filter; receiving an identification of a particular attribute in each of the one or more objects matching the filter, wherein the particular attribute refers to manager name; accessing, for each of the one or more objects, the particular attribute to generate a list of one or more values, each value corresponding to the particular attribute in one of the one or more objects; displaying, for a user, the list of one or more values; and receiving a selection of one or more manager names; and
- adding the additional data to the identity profile, wherein the step of adding includes adding at least one of the manager names to the identity profile.
10. A method according to claim 1, wherein:
- the method is at least partially performed by an integrated Identity System and Access System.
11. A method for performing rule-based identity management, the method comprising:
- receiving, at an identity server, a request to add data to an identity profile for an entity, wherein the identity profile is stored as an object in a directory, wherein the directory comprises a database for storing one or more identity profiles, wherein the identity profile object is based on a class, wherein the class defines one or more attributes for the identity profile object such that the identity profile comprises one or more attributes, wherein the class defines a rule having one or more dynamic variables for a first attribute;
- receiving an attribute value for a second attribute of the identity profile object;
- accessing the class for the identity profile object;
- reading the rule having one or more dynamic variables from the class;
- automatically accessing the attribute value for the second attribute of the identity profile object based on the dynamic variable in the rule and the identity profile object being accessed as part of a workflow;
- automatically applying the attribute value to the rule by replacing a dynamic variable in the rule with the attribute value of the second attribute to create a filter;
- identifying additional data based on the filter, wherein identifying the additional data comprises: using the filter to perform a query against the directory with the first data to find a set of one or more objects in the directory matching the filter; receiving an identification of a particular attribute in each of the one or more objects matching the filter; accessing, for each of the one or more objects, the particular attribute to generate a list of one or more values, each value corresponding to the particular attribute in one of the one or more objects; displaying, for a user, the list of one or more values; and receiving a selection of one or more values from the list of one or more values; and
- using the additional data to perform the work flow, wherein the additional data comprises the selected one or more values.
12. A method according to claim 11, wherein:
- using the additional data includes contracting entities identified with the additional data.
13. A method according to claim 11, wherein:
- identifying additional data comprises evaluating whether a second identity profile satisfies the rule with the first data.
14. A method according to claim 13, further comprising:
- starting the workflow; and
- adding attribute data to the first identity profile, the attribute data includes the first data, the step of using includes providing for a first entity to perform a step of the workflow.
15. A method according to claim 11, wherein:
- the method is at least partially performed by an integrated Identity System and Access System.
16. One or more processor readable storage devices having processor readable code embodied on the processor readable storage devices, the processor readable code for programming one or more: processors, the processor readable code comprising:
- code for receiving, at an identity server, a request to add data to an identity profile for an entity, wherein the identity profile is stored as an object in a directory, wherein the directory comprises a database for storing one or more identity profiles, wherein the identity profile object is based on a class, wherein the class defines one or more attributes for the identity profile object such that the identity profile comprises one or more attributes, wherein the class defines a rule having one or more dynamic variables for a first attribute;
- code for receiving an attribute value for a second attribute of the identity profile object;
- code for accessing the class for the identity profile object;
- code for reading the rule having one or more dynamic variables from the class;
- code for automatically accessing the attribute value for the second attribute of the identity profile object based on the dynamic variable in the rule;
- code for automatically applying the attribute value to the rule by replacing a dynamic variable in the rule with the attribute value of the second attribute to create a filter;
- code for identifying additional data based on the filter, wherein the code for identifying the additional data comprises: code for using the filter to perform a query against the directory with the first data to find a set of one or more objects in the directory matching the filter; code for receiving an identification of a particular attribute in each of the one or more objects matching the filter; code for accessing, for each of the one or more objects, the particular attribute to generate a list of one or more values, each value corresponding to the particular attribute in one of the one or more objects; code for displaying, for a user, the list of one or more values; and code for receiving a selection of one or more values from the list of values; and
- code for adding the additional data to the identity profile, wherein the code for adding includes adding s the elected one or more values to the first attribute in the identity profile.
17. One or more processor readable storage devices according to claim 16, wherein:
- the additional data includes an identification of a first resource; and
- the processor readable code further includes code for provisioning a task related to the first resource in response to the additional data.
18. One ore more processor readable storage devices according to claim 16, wherein:
- the processor readable code at least partially implements an integrated Identity System and Access System.
19. One or more processor readable storage devices having processor readable code embodied on the processor readable storage devices, the processor readable code for programming one or more: processors, the processor readable code comprising:
- code for receiving, at an identity server, a request to add data to an identity profile for an entity, wherein the identity profile is stored as an object in a directory, wherein the directory comprises a database for storing one or more identity profiles, wherein the identity profile object is based on a class, wherein the class defines one or more attributes for the identity profile object such that the identity profile comprises one or more attributes, wherein the class defines a rule having one or more dynamic variables for a first attribute;
- code for receiving an attribute value for a second attribute of the identity profile object;
- code for accessing the class for the identity profile object;
- code for reading the rule having one or more dynamic variables from the class;
- code for automatically accessing the attribute value for the second attribute of the identity profile object based on the dynamic variable in the rule and the identity profile object being accessed as part of a workflow;
- code for automatically applying the attribute value to the rule by replacing a dynamic variable in the rule with the attribute value of the second attribute to create a filter;
- code for identifying additional data based on the filter, wherein the code for identifying the additional data comprises: code for using the filter to perform a query against the directory with the first data to find a set one or more objects in the directory matching filter; code for receiving an identification of a particular attribute in each of the one or more objects matching the filter; code for accessing, for each of the one or more objects, the particular attribute to generate a list of one or more values, each value corresponding to the particular attribute in one of the one or more objects; code for displaying, for a user, the list of one or more values; and code for receiving a selection of one or more values from the list of values; and
- code for using the additional data to perform the work flow, wherein the additional data comprises the selected one or more values.
20. One or more processor readable storage devices according to claim 19, wherein the processor readable code further comprises:
- code for starting the workflow; and
- code for adding attribute data to the first identity profile, the attribute data includes the first data, the code for using includes code for providing for a first entity to perform a step of the workflow, the code for identifying additional data comprises code for evaluating whether a second identity profile satisfies the rule with the first data.
21. One or more processor readable storage devices according to claim 19, wherein:
- the processor readable code at least partially implements an integrated Identity System and Access System.
22. An Identity System, comprising:
- one or more storage devices; and
- one or more processor wherein the storage devices comprise processor readable code executable by the processor(s), the processor readable code comprising:
- code for receiving, at an identity server, a request to add data to an identity profile for an entity, wherein the identity profile is stored as an object in a directory, wherein the directory comprises a database for storing one or more identity profiles, wherein the identity profile object is based on a class, wherein the class defines one or more attributes for the identity profile object such that the identity profile comprises one or more attributes, wherein the class defines a rule having one or more dynamic variables for a first attribute;
- code for receiving an attribute value for a second attribute of the identity profile object;
- code for accessing the class for the identity profile object;
- code for reading the rule having one or more dynamic variables from the class;
- code for automatically accessing the attribute value for the second attribute of the identity profile object based on the dynamic variable in the rule;
- code for automatically applying the attribute value to the rule by replacing a dynamic variable in the rule with the attribute value of the second attribute to create a filter;
- code for identifying additional data based on the filter, wherein the code for identifying the additional data comprises: code for using the filter to perform a query against the directory with first data to find a set of one or more objects in the directory matching the filter; code for receiving an identification of a particular attribute in each of the one or more objects matching the filter; code for accessing, for each of the one or more objects, the particular attribute to generate a list of one or more values, each value corresponding to the particular attribute in one of the one or more objects; code for displaying, for a user, the list of one or more values; and code for receiving a selection of one or more values from the list of values; and
- code for adding the additional data to the identity profile, wherein the code for adding includes code for adding the selected one or more values to the first attribute in the identity profile.
23. An Identity System according to claim 22, wherein:
- the additional data includes an identification of a first resource; and
- the processor readable code further includes code for provisioning a task related to the first resource in response to the additional data.
24. An Identity System according to claim 23, further comprising:
- a provisioning bridge, the provisioning bridge includes the code for provisioning a task.
25. An Identity System, comprising:
- one or more storage devices; and
- one or more processor wherein the storage devices comprise processor readable code executable by the processor(s), the processor readable code comprising:
- code for receiving, at an identity server, a request to add data to an identity profile for an entity, wherein the identity profile is stored as an object in a directory, wherein the directory comprises a database for storing one or more identity profiles, wherein the identity profile object is based on a class, wherein the class defines one or more attributes for the identity profile object such that the identity profile comprises one or more attributes, wherein the class defines a rule having one or more dynamic variables for a first attribute;
- code for receiving an attribute value for a second attribute of the identity profile object;
- code for accessing the class for the identity profile object;
- code for reading the rule having one or more dynamic variables from the class;
- code for automatically accessing the attribute value for the second attribute of the identity profile object based on the dynamic variable in the rule and the identity profile object being accessed as part of a workflow;
- code for automatically applying the attribute value to the rule by replacing a dynamic variable in the rule with the attribute value of the second attribute to create a filter;
- code for identifying additional data based on the filter, wherein the code for identifying the additional data comprises: code for using the filter to perform a query against the directory with the first data to find a set of one or more objects in the directory matching the filter; code for receiving an identification of a particular attribute in each of the one or more objects matching the filter; code for accessing, for each of the one or more objects, the particular attribute to generate a list of one or more values, each value corresponding to the particular attribute in one of the one or more objects; code for displaying, for a user, the list of one or more values; and code for receiving a selection of one or more values from the list of values; and
- code for using the additional data to perform the work flow, wherein the additional data comprises the selected one or more values.
26. An Identity System according to claim 25, wherein the processor readable code further comprises:
- code for starting the workflow; and
- code for adding attribute data to the first identity profile, the attribute data includes the first data, the code for using includes code for providing for a first entity to perform a step of the workflow, the code for identifying additional data comprises code for evaluating whether a second identity profile satisfies the rule with the first data.
27. A method according to claim 25, wherein the directory resides on a directory server.
28. A method according to claim 25, wherein the directory supports lightweight directory access protocol (“LDAP”).
29. A method for performing rule based identity management in an identity system, the identity system being configured to provide identity management services for a network, the method comprising:
- receiving, at the identity system, a request to create an identity profile for a user, wherein the identity profile is stored as an object in a directory, wherein the identity profile object is based on a class, wherein the class defines one or more attributes for the identity profile object such that the identity profile comprises one or more attributes, wherein each attribute being configured to store information about the user, wherein the class defines the rule having one or more dynamic variables for a first attribute;
- providing a template that comprises an indication of one or more attributes for which values are to be provided;
- receiving an attribute value for a second attribute of the identity profile object;
- accessing the class for the identity profile object;
- reading the rule having one or more dynamic variables from the class
- automatically accessing the attribute value for the second attribute of the identity profile object based on the dynamic variable in the rule;
- automatically applying the attribute value to the rule by replacing a dynamic variable in the rule with the attribute value of the second attribute to create a filter;
- identifying additional data based on the filter, wherein identifying the additional data comprises: using the filter to perform a query against the directory with the first data to find a set of one or more objects in a directory matching the filter, receiving an identification of a particular attribute in each of the one or more objects matching the filter; accessing, for each of the one or more objects, the particular attribute to generate a list of one or more values, each value corresponding to the particular attribute in one of the one or more objects; displaying, for a user, the list of one or more values; and receiving a selection of a first attribute value for the first attribute, from the list of values;
- creating the identity profile comprising the first attribute having the first attribute value and the second attribute having the second attribute value; and
- saving the identity profile object in the directory.
30. A method as recited by claim 29, wherein selecting a second attribute value comprises:
- displaying, for a user, attributes from the plurality of objects; and
- allowing a user to select an attribute from the one of the plurality of object.
31. A method as recited by claim 29, wherein selecting a second attribute value comprises selecting a second attribute value without user input.
32. A method as recited by claim 29, wherein the request to add data to the first attribute in the identity profile comprises a request to create a new identity profile.
33. A method as recited by claim 32, wherein creating a new identity profile comprises:
- accessing an object class information;
- providing a template of attributes to the requester, wherein the template provides an indication of the attribute that need to be filled in; and
- receiving an initial value for the attribute.
5010478 | April 23, 1991 | Deran |
5077666 | December 31, 1991 | Brimm et al. |
5455953 | October 3, 1995 | Russell |
5530861 | June 25, 1996 | Diamant et al. |
5581691 | December 3, 1996 | Hsu et al. |
5664154 | September 2, 1997 | Purcell et al. |
5678041 | October 14, 1997 | Baker et al. |
5692125 | November 25, 1997 | Schloss et al. |
5708780 | January 13, 1998 | Levergood et al. |
5713023 | January 27, 1998 | Hayata et al. |
5721900 | February 24, 1998 | Banning et al. |
5724595 | March 3, 1998 | Gentner |
5732408 | March 24, 1998 | Takahashi |
5734837 | March 31, 1998 | Flores et al. |
5754939 | May 19, 1998 | Herz et al. |
5764890 | June 9, 1998 | Glasser et al. |
5815703 | September 29, 1998 | Copeland et al. |
5848273 | December 8, 1998 | Fontana et al. |
5944824 | August 31, 1999 | He |
5991810 | November 23, 1999 | Shapiro et al. |
5999911 | December 7, 1999 | Berg et al. |
6014666 | January 11, 2000 | Helland et al. |
6044465 | March 28, 2000 | Dutcher et al. |
6073109 | June 6, 2000 | Flores et al. |
6078747 | June 20, 2000 | Jewitt |
6098056 | August 1, 2000 | Rusnak et al. |
6131120 | October 10, 2000 | Reid |
6134634 | October 17, 2000 | Marshall, Jr. et al. |
6138104 | October 24, 2000 | Marchak et al. |
6141778 | October 31, 2000 | Kane et al. |
6145003 | November 7, 2000 | Sanu et al. |
6151531 | November 21, 2000 | Frankel et al. |
6158010 | December 5, 2000 | Moriconi et al. |
6182142 | January 30, 2001 | Win et al. |
6195710 | February 27, 2001 | Borgendale et al. |
6208986 | March 27, 2001 | Schneck et al. |
6212558 | April 3, 2001 | Antur et al. |
6253202 | June 26, 2001 | Gilmour |
6253239 | June 26, 2001 | Shklar et al. |
6253257 | June 26, 2001 | Dundon |
6256737 | July 3, 2001 | Bianco et al. |
6256739 | July 3, 2001 | Skopp et al. |
6260077 | July 10, 2001 | Rangarajan et al. |
6266420 | July 24, 2001 | Langford et al. |
6278993 | August 21, 2001 | Kumar et al. |
6279043 | August 21, 2001 | Hayward et al. |
6314470 | November 6, 2001 | Ward et al. |
6323881 | November 27, 2001 | Broulik et al. |
6335927 | January 1, 2002 | Elliott et al. |
6338097 | January 8, 2002 | Krenzke et al. |
6343287 | January 29, 2002 | Kumar et al. |
6347312 | February 12, 2002 | Byrne et al. |
6349306 | February 19, 2002 | Malik et al. |
6353929 | March 5, 2002 | Houston |
6366913 | April 2, 2002 | Fitler, Jr. et al. |
6401101 | June 4, 2002 | Britton et al. |
6401138 | June 4, 2002 | Judge et al. |
6415368 | July 2, 2002 | Glance et al. |
6434531 | August 13, 2002 | Lancelot et al. |
6442567 | August 27, 2002 | Retallick et al. |
6490655 | December 3, 2002 | Kershaw |
6499023 | December 24, 2002 | Dong et al. |
6523022 | February 18, 2003 | Hobbs |
6529941 | March 4, 2003 | Haley et al. |
6539379 | March 25, 2003 | Vora et al. |
6549941 | April 15, 2003 | Jaquith et al. |
6611840 | August 26, 2003 | Baer et al. |
6647383 | November 11, 2003 | August et al. |
6671695 | December 30, 2003 | McFadden |
6671745 | December 30, 2003 | Mathur et al. |
6701368 | March 2, 2004 | Chennapragada et al. |
6704807 | March 9, 2004 | Mathur et al. |
6704873 | March 9, 2004 | Underwood |
6708170 | March 16, 2004 | Byrne et al. |
6721804 | April 13, 2004 | Rubin et al. |
6732178 | May 4, 2004 | Van Horne et al. |
6732179 | May 4, 2004 | Brown et al. |
6741853 | May 25, 2004 | Jiang et al. |
6757720 | June 29, 2004 | Wechler, Jr. |
6760750 | July 6, 2004 | Boneh et al. |
6768988 | July 27, 2004 | Boreham et al. |
6769000 | July 27, 2004 | Akhtar et al. |
6785686 | August 31, 2004 | Boreham et al. |
6785713 | August 31, 2004 | Freeman et al. |
6785726 | August 31, 2004 | Freeman et al. |
6839701 | January 4, 2005 | Baer et al. |
6880086 | April 12, 2005 | Kidder et al. |
6948135 | September 20, 2005 | Ruthfield et al. |
7013435 | March 14, 2006 | Gallo et al. |
7013469 | March 14, 2006 | Smith et al. |
7035926 | April 25, 2006 | Cohen et al. |
7039871 | May 2, 2006 | Cronk |
7069330 | June 27, 2006 | McArdle et al. |
7076784 | July 11, 2006 | Russell et al. |
7114037 | September 26, 2006 | Agarwal et al. |
7120914 | October 10, 2006 | Manthos et al. |
7213249 | May 1, 2007 | Loo et al. |
7216163 | May 8, 2007 | Sinn |
7231661 | June 12, 2007 | Villavicencio et al. |
7249369 | July 24, 2007 | Knouse et al. |
7266595 | September 4, 2007 | Black et al. |
7340447 | March 4, 2008 | Ghatare |
7349912 | March 25, 2008 | Delany et al. |
7363339 | April 22, 2008 | Delany et al. |
7380008 | May 27, 2008 | Teng et al. |
7398311 | July 8, 2008 | Joshi et al. |
20020032684 | March 14, 2002 | Kobayashi et al. |
20020038306 | March 28, 2002 | Griffin et al. |
20020049749 | April 25, 2002 | Helgeson et al. |
20020067370 | June 6, 2002 | Forney et al. |
20020073180 | June 13, 2002 | Dewhurst et al. |
20020083178 | June 27, 2002 | Brothers |
20020138763 | September 26, 2002 | Delany et al. |
20020161766 | October 31, 2002 | Lawson et al. |
20030028752 | February 6, 2003 | Fu et al. |
20030037052 | February 20, 2003 | Kitain et al. |
20030055762 | March 20, 2003 | Holt |
20030055806 | March 20, 2003 | Wong et al. |
20030065558 | April 3, 2003 | Shaw et al. |
20030083908 | May 1, 2003 | Steinmann |
20030088708 | May 8, 2003 | Lewallen |
20030097380 | May 22, 2003 | Mulhern et al. |
20030105733 | June 5, 2003 | Boreham et al. |
20030105742 | June 5, 2003 | Boreham et al. |
20030115196 | June 19, 2003 | Boreham et al. |
20030115548 | June 19, 2003 | Melgar |
20030120593 | June 26, 2003 | Bansal et al. |
20030120601 | June 26, 2003 | Ouye et al. |
20030144982 | July 31, 2003 | Reulein et al. |
20030145074 | July 31, 2003 | Penick |
20030204481 | October 30, 2003 | Lau |
20030208397 | November 6, 2003 | VanDusen |
20030217127 | November 20, 2003 | Sinn |
20030217333 | November 20, 2003 | Smith et al. |
20040003351 | January 1, 2004 | Sommerer et al. |
20040024762 | February 5, 2004 | Agarwal et al. |
20050240490 | October 27, 2005 | Mackey |
- U.S. Appl. No. 10/314,888, Office Action dated Jan. 26, 2006, 31 pages.
- U.S. Appl. No. 10/345,873, Office Action dated Sep. 9, 2005, 13 pages.
- U.S. Appl. No. 10/345,873, Office Action dated Mar. 10, 2006, 7 pages.
- U.S. Appl. No. 10/354,913, Office Action dated Sep. 9, 2003, 19 pages.
- U.S. Appl. No. 10/354,913, Final Office Action dated Apr. 6, 2004, 22 pages.
- U.S. Appl. No. 10/354,913, Office Action dated Apr. 15, 2005, 20 pages.
- U.S. Appl. No. 10/354,913, Final Office Action dated Dec. 5, 2005, 15 pages.
- U.S. Appl. No. 10/354,914, Office Action dated Aug. 1, 2005, 15 pages.
- U.S. Appl. No. 10/354,914, Final Office Action dated Feb. 10, 2006, 16 pages.
- U.S. Appl. No. 10/354,914, Notice of Allowance dated Mar. 12, 2008, 11 pages.
- Leon, McAfee's NetTools Promises to Ease Network Desktop Diagnosis, InfoWorld, San Mateo, Jul. 24, 1995, vol. 17, Iss. 30, p. 53.
- Cooney, IBM rolls out host and server-based mgmt. apps, Network World, Framingham, Feb. 6, 1995, vol. 12, Iss. 6, pp. 6-7.
- Walsh, Remedy releases three applications for help-desk suite, InfoWorld, San Mateo, Apr. 21, 1997, vol. 19, Iss. 16, p. 34.
- Schmersal, Testing to maintain service standards, Communications News, Nokomis, Mar. 1998, vol. 35, Iss. 3, pp. 22-23.
- Musthaler, The trouble with help desk selection, Network World, Framingham, Feb. 20, 1995, vol. 12, Iss. 8, pp. 35-39.
- Clear Trust, Unified Access Management Securant Technologies, Inc., pp. 1-23, 1997.
- SiteMinder Agent Operations, Version 4.0, Netegrity Inc., 1997.
- SiteMinder Deployment Guide, Version 4.0, Netegrity Inc., 1997.
- SiteMinder Policy Server Operations Guide, Version 4.0, Netegrity Inc., 1997.
- SiteMinder Developer's API Guide, Version 4.0, Netegrity Inc., 1997.
- SiteMinder Installation Guide, Version 4.0, Netegrity Inc., 1997.
- Kim, K.H., “APIs for Real-Time Diistributed Object Programming”, Coputer, IEEE 2000, June, pp. 72-80.
- McLellan, et al., “Building More Usable APIs”, IEEE Software, pp. 78-86, May/Jun. 1998.
- Saba—Products, Saba Enterprise 5, dated 1997-2006, 2 pages.
- Saba—Company, dated 1997-2006, 1 page.
- Saba—Solutions, Competency-Driven HCM, dated 1997-2006, 1 page.
- Saba—Talent, dated 1997-2006, 2 pages.
- Saba—Collaboration, dated 1997-2006, 1 page.
- Stets, et al., “Component-Based APIs for Versioning and Distributed Applications”, IEEE, pp. 54-61, 1999.
- U.S. Appl. No. 09/570,276, Office Action dated Nov. 14, 2006, 28 pages.
- U.S. Appl. No. 10/314,888, Office Action dated Jul. 26, 2006, 26 pages.
- U.S. Appl. No. 10/325,465, Office Action dated Sep. 19, 2006, 25 pages.
- U.S. Appl. No. 10/328,920, Office Action dated May 31, 2006, 20 pages.
- U.S. Appl. No. 10/345,879, Office Action dated Oct. 5, 2006, 30 pages.
- U.S. Appl. No. 10/354,913, Office Action dated May 12, 2005, 16 pages.
- U.S. Appl. No. 09/570,276, Office Action dated Mar. 25, 2003, 36 pages.
- U.S. Appl. No. 09/570,276, Final Office Action dated Sep. 5, 2003, 24 pages.
- U.S. Appl. No. 09/570,276, Advisory Action dated Nov. 17, 2003, 3 pages.
- U.S. Appl. No. 09/570,276, Office Action dated Jan. 14, 2004, 17 pages.
- U.S. Appl. No. 09/570,276, Office Action dated Sep. 13, 2004, 16 pages.
- U.S. Appl. No. 09/570,276, Final Office Action dated Feb. 21, 2006, 17 pages.
- U.S. Appl. No. 09/570,276, Final Office Action dated Jul. 9, 2007, 16 pages.
- U.S. Appl. No. 09/570,276, Office Action dated Oct. 2, 2007, 14 pages.
- U.S. Appl. No. 10/314,888, Final Office Action dated Feb. 9, 2007, 34 pages.
- U.S. Appl. No. 10/314,888, Office Action dated Jul. 27, 2007, 37 pages.
- U.S. Appl. No. 10/325,465, Final Office Action dated Apr. 4, 2007, 25 pages.
- U.S. Appl. No. 10/325,465, Advisory Action dated Jun. 19, 2007, 3 pages.
- U.S. Appl. No. 10/325,465, Office Action dated Dec. 12, 2007, 20 pages.
- U.S. Appl. No. 10/328,920, Notice of Allowance dated Dec. 5, 2006, 8 pages.
- U.S. Appl. No. 10/345,873, Notice of Allowance dated Jul. 6, 2006, 6 pages.
- U.S. Appl. No. 10/345,879, Final Office Action dated May 17, 2007, 39 pages.
- U.S. Appl. No. 10/345,879, Advisory Action dated Jul. 27, 2007, 5 pages.
- U.S. Appl. No. 10/345,879, Office Action dated Oct. 31, 2007, 35 pages.
- U.S. Appl. No. 10/354,913, Final Office Action dated Oct. 31, 2006, 15 pages.
- U.S. Appl. No. 10/354,913, Final Office Action dated Apr. 18, 2007, 20 pages.
- U.S. Appl. No. 10/354,913, Ex Parte Quayle Action dated Nov. 1, 2007, 7 pages.
- U.S. Appl. No. 10/354,914, Office Action dated Sep. 22, 2006, 8 pages.
- U.S. Appl. No. 10/354,914, Final Office Action dated Apr. 5, 2007, 9 pages.
- U.S. Appl. No. 11/684,796, Office Action dated Nov. 27, 2007, 25 pages.
- U.S. Appl. No. 10/952,592, Office Action dated Oct. 4, 2006, 17 pages.
- U.S. Appl. No. 10/952,592, Final Office Action dated May 3, 2007, 54 pages.
- U.S. Appl. No. 10/952,592, Office Action dated Aug. 23, 2007, 22 pages.
- U.S. Appl. No. 10/354,913, Office Action dated Feb. 7, 2008, 10 pages.
- U.S. Appl. No. 10/314,888, Final Office Action dated Feb. 22, 2008, 37 pages.
- U.S. Appl. No. 11/684,796, Final Office Action dated Jun. 17, 2008, 22 pages.
Type: Grant
Filed: Dec 20, 2002
Date of Patent: Dec 16, 2008
Patent Publication Number: 20040010519
Assignee: Oracle International Corporation (Redwood Shores, CA)
Inventors: Richard P. Sinn (Milpitas, CA), Thomas B. Remahl (Los Altos, CA), Andy M. Tsang (San Jose, CA)
Primary Examiner: Jean M. Corrielus
Assistant Examiner: Giovanna Colan
Attorney: Townsend and Townsend and Crew LLP
Application Number: 10/327,607
International Classification: G06F 12/00 (20060101); G06F 17/30 (20060101);