Patent Grant
7447701
This Application is related to “Preparing Output XML Based on Selected Programs and XML Templates,” by Michele C. Lee, U.S. patent application Ser. No. 09/997,410, filed Nov. 30, 2001, and incorporated herein by reference in its entirety.
1. Field of the Invention
The present invention is directed to technology for automatically configuring object classes.
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, 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.
The data store often maintains attributes associated with an entity, such as a user, group, or organization, in an object that corresponds to the entity. For example, an object for a user may contain attributes for the user's name and login code. The Identity System often employs different classes of objects, with each class corresponding to a different type of entity. In one example, the Identity System employs different object classes for users, groups, and organizations. Each object in the user object class contains a set of attributes that correspond to a user. Each object in the group object class contains a set of attributes that correspond to a group. Each object in the organization object class contains a set of attributes that correspond to an organization.
The object classes employed in the data store may be used by many different systems and applications, in addition to the Identity System. The Identity System needs to have the object classes configured to support their use by the Identity System. In one example, the Identity System needs to associate meta-attributes with the attributes in an object class. The meta-attributes provide information the Identity System employs when using the object class attributes, such as an attribute's display name.
Traditionally, a system administrator manually configures object classes for the Identity System. The administrator informs the Identity System of each object class and configures each object class attribute—providing meta-attributes when necessary. The manual configuration is typically a tedious process that consumes a great deal of time. It is desirable for the configuration to be automated.
Some Identity System users also employ an Access Systems. An Access System provides for the authentication and authorization of users attempting to access resources. For efficiency purposes, there is an advantage to integrating the Identity System and the Access System. Additionally, integrating the Identity System and the Access System allows for single-sign-on functionality across multiple resources. Thus, there is also a need for Access Systems and integrated Identity/Access Systems to automatically configure object classes. Systems other than Identity and Access Systems can also benefit from automatically configuring object classes. Automated object class configuration can benefit any application or system that needs to interface with data store object classes.
The present invention, roughly described, pertains to technology for automatically configuring attribute sets, such as object classes. In one implementation, an Identity System configures an object class, based on a template for the object class. The template includes entries that identify attributes for the object class. In one embodiment, each entry identifies an attribute and a corresponding meta-attribute. In alternate embodiments, the template may support multiple objects and include entries with different types of information.
The Identity System identifies a template that corresponds to the object class being configured. The Identity System also retrieves schema information for the object class. In one implementation, the schema information identifies the attributes for the object class. The Identity System uses the schema information and template to configure the object class.
During configuration, the Identity System selects an attribute in the object class and identifies a corresponding template entry. The Identity System configures the attribute, based on the information in the template entry. In one embodiment, the template entry identifies a meta-attribute for the selected attribute, and the Identity System assigns the meta-attribute to the selected attribute in the object class. The Identity System repeats this procedure for each attribute in the object class.
Different embodiments employ a variety of techniques to identify template entries that correspond to a selected attribute. In one instance, the Identity System attempts to identify a template entry with a name that matches the corresponding attribute. A match can be found when the names are identical or have a desired level of similarity. If there is not a match, the Identity System employs a default template entry with generic configuration information.
Various embodiments of the present invention are incorporated in an Identity, Access, or integrated Identity/Access System. Further embodiments, however, are employed in systems other than Identity, Access, and integrated Identity/Access Systems. Further implementations of the invention provide for configuring attribute sets other than object classes. One embodiment configures classes of tables in a database—configuring attributes in a class of database table using a template.
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.
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 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. 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 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
The received log-on information is passed back to Web Server 18 and on to Web Gate 28. Web Gate 28 in turn makes an authentication request to Access Server 34, which determines whether the user's supplied log-on information is authentic or not. Access Server 34 performs the authentication by accessing attributes of the user's identity profile and the resource's authentication criteria stored on Directory 36. If the user's supplied log-on information satisfies the authentication criteria, the process flows as described below; otherwise, the end user is notified that access to the requested resource is denied and the process halts.
After authenticating the user, Web Gate 28 queries Access Server 34 about whether the user is authorized to access the resource requested. Access Server 34 in turn queries Directory 36 for the appropriate authorization criteria for the requested resource. Access Server 34 retrieves the authorization criteria for the resource and answers Web Gate 28's authorization query, based on the resource's authorization criteria and the user's identity profile. If the user is authorized, the user is granted access to the resource; otherwise, the user's request is denied. Various alternatives to the above described flow are also within the spirit and scope of the present invention.
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 (step 64). After step 64, the system performs authentication failure actions and Web Gate 28 denies the user access to the requested resource (step 66). In step 74, the successful authentication of the user for the resource is logged. The method then performs authentication success actions (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 (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 (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 (step 92). Authorization success actions are performed in step 94. The user is granted access to the requested resource (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/997,410, “Preparing Output XML Based on Selected Programs and XML Templates,” 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. The basic unit of information store in Directory 36 is called a object, entry or identity profile, which is a collection of information about an entity. The information in an entry often describes a real-world entity such as a person, but this is not required. A typical directory includes many entries that correspond to people, departments, groups and other entities in the organization served by the directory. An object is composed of a set of attributes, each of which describes one particular trait of the entity. In one implementation, 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 may be required to have a cn (common name) attribute and an sn (surname) attribute in one embodiment. 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, 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 relative 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 150) is DN=CN=Empl, OU=OrgA, O=CompanyA, DC=entity, where:
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 206, a user is provided with the information stored in that user's identity profile. Create User Identity tab 208 allows a user with the appropriate privileges to create a new user identity profile (e.g. with a workflow). Deactivate User Identity tab 210 allows a user with proper privileges to remove an identity profile from the directory. Substitute Rights tab 212 allows the user to indicate who can proxy that user and allows the user to be a proxy for someone else. Request tab 214 allows a user to monitor workflows that are in progress or recently completed. Depending on the user's privileges, by selecting request tab 214, 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 214 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 216 allows a user to configure various options for User Manger 42. The user must have sufficient privileges to access Configure tab 216. 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 240 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. Manage Subscriptions tab 239 allows users to subscribe to groups or unsubscribe from groups. Manage Members tab 241 allows users to view, add, remove, and search members of a group.
Create Organizational Profile tab 246 allows a user to create new organizational objects, if the user has sufficient privileges. Request tab 248 allows a user to access pending workflows and workflows that have recently been finished that relate to organizational objects. Access to Request tab 248 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 248.
Configure tab 250 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.
The object classes supported in Directory 36 need to be configured for use with the Identity System. The automatic configuration provided by the process shown in
The Identity System identifies an object class supported by Directory 36 for configuration (step 300). In one implementation, the Identity System queries a system administrator or other user for the name of an object class to be configured. In other embodiments, many different techniques can be used for identifying object classes that need configuration. For example, the Identity System may select an object class from a list of object classes to be configured. In one implementation, only a single object class can be identified for each type of object. For example, the Identity System will only recognize one user object class and one group object class. In alternate embodiments, multiple object classes can be configured for a single type of object.
The Identity System identifies a template that corresponds to the identified object class (step 302). A template contains entries that correspond to attributes in the identified object class. In one implementation, a template only includes attributes that are meant to correspond to one object class. Alternatively, a template can include attributes for multiple object classes. In one embodiment, the Identity System only has access to a single template that contains a list of attributes to employ across multiple object classes. Any set of configuration information for an object class or attributes in an object class can be employed as a template. A template may also include multiple sets of configuration information. In one format, a template entry includes an attribute identifier, such as an attribute name or unique code, and a meta-attribute for the identified attribute. A meta-attribute provides information used by the Identity System when employing the associated attribute. Alternatively, each entry can include additional information that corresponds to an attribute.
In one embodiment, a meta-attribute includes the following components: 1) cardinality—identifying whether one or multiple values are associated with the attribute; 2) display name—identifying a name to be displayed on a graphical user interface to describe the attribute; 3) display type—identifying a display format for the attribute's display name; 4) searchable—indicating whether a user can perform a search, based on the associated attribute; 5) version—identifying the version of the Identity System software; 6) visible—indicating whether the attribute can be viewed; 7) semantic type—identifying any action or special meaning associated with the attribute. The Identity System employs the semantic type to associate additional meaning with the attribute. For example, when the semantic type is “Login,” the Identity System recognizes that the attribute contains a login identifier and employs the attribute whenever a login identifier is required. The above list only represents one example of a meta-attribute. Further embodiments employ different meta-attributes.
In one implementation of step 302, the Identity System identifies a corresponding template based on the template's name. Matching a template name to an object class name can be useful when Directory 36 employs standard directory server software with well-known object class names. Examples of such directory server software include products provided by Netscape, Novell, and Microsoft. One example of a well-known name for a user object class is InetOrgPerson. In a matching implementation, the Identity System looks for a template with an identifier corresponding to the InetOrgPerson name.
Different techniques can be employed for identifying a template that corresponds to the identified object class. For example, the Identity System can try to identify a template with a name that has a predefined level of similarity to the object class name. The Identity System can alternatively try to identify a template with entries for a predetermined number of attributes that correspond to the attributes identified in the object class. In some instances, the selected object class may be non-standard and customized—making its name unknown to the Identity System. In order to address this concern, the Identity System can include generic templates for use when matching criteria is not satisfied.
The Identity System retrieves schema information for the object class identified in step 300 (step 304). In one embodiment, the schema is maintained in Directory 36. The schema identifies each attribute in the object class and information relating to the attributes. In some instances, a schema may not provide any information about the attributes, but merely list the attributes for reference. In one implementation, the schema for an object class identifies attributes that are required by the object class and attributes that are supported by the object class, but not required. In one embodiment, the Identity System retrieves the entire schema. In alternate embodiments, only portions of the schema are retrieved.
In one implementation, the schema identifies the following information for each attribute: 1) attribute name—identifying the name for the attribute; 2) attribute alias—identifying any aliases used to identify the attribute; 3) attribute identifier—providing a unique identifier for the attribute; and 4) syntax—identifying the attribute syntax, such as case insensitive string, integer, and binary. Those skilled in the art will recognize that this is only one example of a schema format. In different embodiments, many different schema formats can be employed. The Identity System uses the schema information to identify the attributes in the identified object class from step 300.
The Identity System employs the schema information and template to configure the object class (step 306). The schema identifies object class attributes, and the template provides configuration information for the attributes. In one implementation, the Identity System assigns a meta-attribute to each attribute. Alternatively, the Identity System performs additional or different operations, such as associating attributes in the object class with entries in the template—providing the Identity System with awareness of how Directory 36 identifies objects and attributes employed by the Identity System. The configuration allows the Identity System and Directory 36 to communicate using a common language that recognizes a common set of objects and treats attributes in those objects in the same manner.
After configuring the object class, the Identity System presents the object class configuration to the system administrator (step 308). The system administrator reviews the configuration and determines whether any changes are necessary. The system administrator may recognize that some automatic configuration results fail to comply with the system administrator's implementation of the Identity System. If no changes are required (step 310), the configuration process is complete. Otherwise, the Identity System allows the administrator to manually modify the object class configuration (step 312). In one implementation, the Identity System provides a graphical user interface that allows the system administrator to review object class configuration (step 308) and implement modifications (step 312).
If a matching template is identified, the Identity System selects the matching template (step 322). Otherwise, the Identity System selects a generic template (step 324). The generic template can have many different forms in different embodiments of the present invention. In one embodiment, the generic template includes a list of many attributes that may be used across multiple object classes. In another embodiment, the generic template includes several generic entries that correspond to generalized attribute formats. In a further embodiment, the generic template only includes one generic entry.
The Identity System configures the selected attribute (step 342). The attribute configuration allows the Identity System to recognize and utilize the attribute. One implementation of attribute configuration includes the Identity System assigning a meta-attribute to the selected attribute. In alternate embodiments, the Identity System performs additional or different configuration operations, such as making an association between the selected attribute and a template entry.
The Identity System determines whether any of the object class attributes that are eligible for selection remain unselected (step 344). If any of the attributes have not yet been selected, the Identity System selects an object class attribute (step 340) and repeats the above-described process. Otherwise, the object class configuration is complete.
The Identity System determines whether any of the entries in the identified template match the selected attribute (step 360). In different embodiments, various forms of criteria are applied to determine whether a template entry matches a selected attribute. In one implementation, a match is found if the template entry has a name or field corresponding to the name of the selected attribute. Alternatively, the Identity System can employ different filtering techniques to determine whether a match occurs. In one implementation, the Identity System finds a match when a template entry includes a character pattern with a predetermined level of similarity to the name of the selected attribute. The Identity System can also employ values other than the attribute name for matching, such as the attribute's unique identifier. Alternatively, a match can be found when a selected attribute has a set of characteristics that correspond to an entry in the template.
If a matching entry is found (step 360), the Identity System assigns a meta-attribute from the matching template entry to the selected attribute (step 362). In one embodiment, the assigned meta-attribute includes a number of components, as described above. The Identity System stores the meta-attribute for the attribute in a corresponding object in Directory 36 in one implementation. In this implementation, an object class exists for meta-attributes. The Identity System creates an object for each meta-attribute and stores the meta-attribute's components and their values in the object.
In an alternate embodiment, the Identity System stores a meta-attribute for the selected attribute in an object in Directory 36 for the selected attribute. In this embodiment, the Identity System supports an attribute object class—each attribute has an associated object that lists at least the attribute and its associated meta-attribute.
If a matching template entry is not found (step 360), the Identity System determines whether to employ a default template entry (step 364). In one implementation, a default template entry provides a generic set of meta-attribute components and values that can be assigned to the selected attribute. If it is not desirable to employ a default template entry, the Identity System leaves the attribute without any new information and is done with the configuration process. In an alternate embodiment, the decision not to use a default template entry halts the entire object class configuration. This can be the case when the selected attribute needs to be configured by a matching template entry in order for the Identity System to recognize the attribute. In one example, matching template entries are required for user name and login identification attributes in the user object class. Many different attributes can be mandatory in alternate embodiments.
If it is desirable to use a default template entry, the Identity System assigns the meta-attribute from the default entry to the selected attribute. In one implementation, the default entry includes the meta-attribute components listed above and provides the following default values: 1) cardinality—single value; 2) display type—text; and 3) version—the current version of the Identity System software. In alternate embodiments, different default values and meta-attribute components can be provided.
Although the configuration process described in
If the selected attribute is listed in the template entry (step 380), a match is found and the process in
In further embodiments, the processes described above with reference to
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.
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.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5010478 | Deran | Apr 1991 | A |
| 5077666 | Brimm et al. | Dec 1991 | A |
| 5455953 | Russell | Oct 1995 | A |
| 5530861 | Diamant et al. | Jun 1996 | A |
| 5581691 | Hsu et al. | Dec 1996 | A |
| 5664154 | Purcell et al. | Sep 1997 | A |
| 5678041 | Baker et al. | Oct 1997 | A |
| 5692125 | Schloss et al. | Nov 1997 | A |
| 5708780 | Levergood et al. | Jan 1998 | A |
| 5721900 | Banning et al. | Feb 1998 | A |
| 5724595 | Gentner | Mar 1998 | A |
| 5732408 | Takahashi | Mar 1998 | A |
| 5764890 | Glasser et al. | Jun 1998 | A |
| 5815703 | Copeland et al. | Sep 1998 | A |
| 5848273 | Fontana et al. | Dec 1998 | A |
| 5944824 | He | Aug 1999 | A |
| 5991810 | Shapiro et al. | Nov 1999 | A |
| 5999911 | Berg et al. | Dec 1999 | A |
| 6014666 | Helland et al. | Jan 2000 | A |
| 6073109 | Flores et al. | Jun 2000 | A |
| 6078747 | Jewitt | Jun 2000 | A |
| 6098056 | Rusnak et al. | Aug 2000 | A |
| 6105035 | Monge et al. | Aug 2000 | A |
| 6131120 | Reid | Oct 2000 | A |
| 6134634 | Marshall, Jr. et al. | Oct 2000 | A |
| 6138104 | Marchak et al. | Oct 2000 | A |
| 6141778 | Kane et al. | Oct 2000 | A |
| 6145003 | Sanu et al. | Nov 2000 | A |
| 6151531 | Frankel et al. | Nov 2000 | A |
| 6158010 | Moriconi et al. | Dec 2000 | A |
| 6182142 | Win et al. | Jan 2001 | B1 |
| 6195710 | Borgendale et al. | Feb 2001 | B1 |
| 6208986 | Schneck et al. | Mar 2001 | B1 |
| 6212558 | Antur et al. | Apr 2001 | B1 |
| 6253239 | Shklar et al. | Jun 2001 | B1 |
| 6253257 | Dundon | Jun 2001 | B1 |
| 6256739 | Skopp et al. | Jul 2001 | B1 |
| 6260077 | Rangarajan et al. | Jul 2001 | B1 |
| 6266420 | Langford et al. | Jul 2001 | B1 |
| 6278993 | Kumar et al. | Aug 2001 | B1 |
| 6279043 | Hayward et al. | Aug 2001 | B1 |
| 6314470 | Ward et al. | Nov 2001 | B1 |
| 6323881 | Broulik | Nov 2001 | B1 |
| 6338097 | Krenzke et al. | Jan 2002 | B1 |
| 6343287 | Kumar et al. | Jan 2002 | B1 |
| 6347312 | Byrne et al. | Feb 2002 | B1 |
| 6349306 | Malik et al. | Feb 2002 | B1 |
| 6353929 | Houston | Mar 2002 | B1 |
| 6366913 | Fitler, Jr. et al. | Apr 2002 | B1 |
| 6401101 | Britton et al. | Jun 2002 | B1 |
| 6401138 | Judge et al. | Jun 2002 | B1 |
| 6415368 | Glance et al. | Jul 2002 | B1 |
| 6434531 | Lancelot et al. | Aug 2002 | B1 |
| 6442567 | Retallick et al. | Aug 2002 | B1 |
| 6490655 | Kershaw | Dec 2002 | B1 |
| 6499023 | Dong et al. | Dec 2002 | B1 |
| 6523022 | Hobbs | Feb 2003 | B1 |
| 6529941 | Haley et al. | Mar 2003 | B2 |
| 6539379 | Vora et al. | Mar 2003 | B1 |
| 6549941 | Jaquith et al. | Apr 2003 | B1 |
| 6611840 | Baer et al. | Aug 2003 | B1 |
| 6671695 | McFadden | Dec 2003 | B2 |
| 6671745 | Mathur et al. | Dec 2003 | B1 |
| 6701368 | Chennapragada et al. | Mar 2004 | B1 |
| 6704807 | Mathur et al. | Mar 2004 | B1 |
| 6704873 | Underwood | Mar 2004 | B1 |
| 6708170 | Byrne et al. | Mar 2004 | B1 |
| 6721804 | Rubin et al. | Apr 2004 | B1 |
| 6732178 | Van Horne et al. | May 2004 | B1 |
| 6732179 | Brown et al. | May 2004 | B1 |
| 6741853 | Jiang et al. | May 2004 | B1 |
| 6760750 | Boneh et al. | Jul 2004 | B1 |
| 6768988 | Boreham et al. | Jul 2004 | B2 |
| 6785686 | Boreham et al. | Aug 2004 | B2 |
| 6785713 | Freeman et al. | Aug 2004 | B1 |
| 6785726 | Freeman et al. | Aug 2004 | B1 |
| 6816871 | Lee | Nov 2004 | B2 |
| 6839701 | Baer et al. | Jan 2005 | B1 |
| 6880086 | Kidder et al. | Apr 2005 | B2 |
| 6948135 | Ruthfield et al. | Sep 2005 | B1 |
| 7013435 | Gallo et al. | Mar 2006 | B2 |
| 7013469 | Smith et al. | Mar 2006 | B2 |
| 7035926 | Cohen et al. | Apr 2006 | B1 |
| 7039871 | Cronk | May 2006 | B2 |
| 7069330 | McArdle et al. | Jun 2006 | B1 |
| 7076784 | Russell et al. | Jul 2006 | B1 |
| 7114037 | Agarwal et al. | Sep 2006 | B2 |
| 7120914 | Manthos et al. | Oct 2006 | B1 |
| 20020032684 | Kobayashi et al. | Mar 2002 | A1 |
| 20020038306 | Griffin et al. | Mar 2002 | A1 |
| 20020049749 | Helgeson et al. | Apr 2002 | A1 |
| 20020067370 | Forney et al. | Jun 2002 | A1 |
| 20020073180 | Dewhurst et al. | Jun 2002 | A1 |
| 20020083178 | Brothers | Jun 2002 | A1 |
| 20020138763 | Delany et al. | Sep 2002 | A1 |
| 20030028752 | Fu et al. | Feb 2003 | A1 |
| 20030037052 | Kitain et al. | Feb 2003 | A1 |
| 20030055806 | Wong et al. | Mar 2003 | A1 |
| 20030083908 | Steinmann | May 2003 | A1 |
| 20030088708 | Lewallen | May 2003 | A1 |
| 20030097380 | Mulhern et al. | May 2003 | A1 |
| 20030105733 | Boreham et al. | Jun 2003 | A1 |
| 20030105742 | Boreham et al. | Jun 2003 | A1 |
| 20030115196 | Boreham et al. | Jun 2003 | A1 |
| 20030115548 | Melgar | Jun 2003 | A1 |
| 20030120593 | Bansal et al. | Jun 2003 | A1 |
| 20030120601 | Ouye et al. | Jun 2003 | A1 |
| 20030144982 | Reulein et al. | Jul 2003 | A1 |
| 20030145074 | Penick | Jul 2003 | A1 |
| 20030204481 | Lau | Oct 2003 | A1 |
| 20030217127 | Sinn | Nov 2003 | A1 |
| 20030217333 | Smith et al. | Nov 2003 | A1 |
| 20040003351 | Sommerer et al. | Jan 2004 | A1 |
| 20040024762 | Agarwal et al. | Feb 2004 | A1 |
| 20050240490 | Mackey | Oct 2005 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20040010514 A1 | Jan 2004 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60395152 | Jul 2002 | US |
