Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

• the present invention relates, generally, to the administration of user accounts and resources, and, in preferred embodiments, to systems and processes for provisioning users with resources based on policies, roles, organizational information, attributes and authorizations or information from another user.
• a common use of communication networks is to provide users access to network resources such as software, electronic data, or files in storage systems or databases connected to the network.
• network resources such as software, electronic data, or files in storage systems or databases connected to the network.
• Network environments often involve a variety of network users, where the users may be grouped or categorized by a relation or role that the user serves in the environment.
• users of the company's computer network may include company officers, directors, managers, engineers, technical support staff, office support staff, accounting department staff, information technology (IT) department staff, contractors, consultants, temporary employees or other relation-based or role-based groups or categories of network users.
• Other companies, organizations or network environments may have other relation or role-based groups of users.
• Each user may have a need to access certain network resources in connection with the user's relation or role.
• other types of resources may also be allocated to (or restricted from) users, based on the user's relation or role in the environment.
• users may be allocated such resources as telephones, telephone accounts, computers, Internet accounts, e-mail accounts, office equipment and supplies, laboratory or engineering equipment and supplies, or other resources, based on the user's role or relation with the company.
• Some network resources may be provided by one or more computer systems connected to a user's local area network (LAN) or "intranet.”
• LAN local area network
• intranet a computer system on a LAN may operate as a server for providing LAN users access to software, electronic data, files or other network resources served by the server.
• Other types of allocatable resources may comprise managed services available from remote computer systems connected to the user or LAN through a wide area network (WAN), such as the Internet.
• WAN wide area network
• managed services as databases, email systems, financial services, or the like may be provided to users through an Internet connection.
• resources such as databases are commonly available over the Internet, including, the search databases provided and maintained by the U.S.
• Patent and Trademark Office Other databases and other types of resources available over the Internet are provided and maintained by service companies, for which they charge subscribers for the right to use such resources.
• service companies typically employ an account agent comprising software running on a computer located at the same site as the resource, for maintaining and administering user accounts for users of resource.
• an account agent is the enRoleTM product produced by ACCESS360 of Irvine, California, the assignee of the present invention.
• These resources may be accessed by a user on a LAN, for example, through an Internet connection linking the LAN or the user's computer directly to the Internet. Connections that link LANs to external resources, such as other LANs or remote databases, are called bridges, routers, and gateways.
• a bridge passes information between two or more LANs.
• a router connects a LAN to a larger LAN or to a WAN by interpreting protocol information and selectively forwarding packets to different LAN or WAN connections through an efficient, available route.
• a gateway connects and translates between networks that use different communications protocols.
• LAN computers typically use a gateway or router to connect to a WAN such as the Internet. However, such connections can be a security risk to the LAN. Applications, files or other information received on the LAN from the Internet may contain computer viruses. In addition, such connections can provide a route for Internet users to gain unauthorized access to sensitive files on the LAN.
• firewalls are used for inhibiting unauthorized access to resources on the LAN, while letting authorized LAN users access resources on the WAN.
• Firewalls can also detect and inhibit passage of viruses to the LAN.
• a firewall is a computer security device, typically composed of software running on computer that acts as the LAN's gateway to the WAN or on a dedicated computer placed between the LAN and the WAN.
• Firewall devices may also be composed of hardware, firmware or combinations of software, hardware and firmware.
• An example of a conventional system environment is shown in Prior Art Fig. 18, wherein a resource 900, shown as a database, is connected, through a resource agent 902 and a firewall 904, to the Internet 906. Users Ul and U2 are also connected to the Internet.
• the resource 900 is accessible to authorized users, such as paying subscribers.
• the resource agent 902 stores information relating to authorized users, such as passwords, identification information and access rights information, and controls access to the database to allow authorized users access to the database, but inhibit unauthorized users from accessing the database. Because the resource agent 902 provides and maintains access rights, the agent is located at a secure location relative to the users, such as on-site with the resource 900.
• an engineering company may open a user account with a database service for each of its technical employees, to allow access to a database of technical data or technical articles.
• the engineering company may open a user account with an email service for each employee of the company.
• the resource 900 may be considered the technical database or the email service database.
• Information associated with each such user, such as passwords, identification information and access rights information is stored and maintained by the resource agent 902, as described above. However, over a period of time, the roles or status of a user may change.
• Role Based Access Control is one form of automatic provisioning, which may by LAN-based, that has become commercially available.
• RBAC provides permissions (access rights) to a user to access certain accounts (files, web pages, etc.) available over the network, based on a person's role in the organization. For example, a file or folder may be viewed only by its creator, or may be accessible to a larger group of users through an organization's network, depending on the permission rights established for that file or folder.
• RBAC Resource Provisioning Management
• managed resources may have user management consoles which enable a human to make changes to the managed resource, the consoles or interfaces may be incompatible with the RPM system.
• software agents may be deployed as translators between the RPM system and the managed resources.
• the agent in essence, replaces human intervention with automated steps that perform essentially the same function.
• the agent is capable of receiving a message or request from the RPM system, and translating the request to code that can interface with the Application Programming Interfaces (APIs) of the managed resource. After the managed resource performs the particular function of the request, the managed resource may pass values to the agent, which may then communicate the values back to the RPM system.
• APIs Application Programming Interfaces
• the managed resource may pass values to the agent, which may then communicate the values back to the RPM system.
• the implementation of an RPM system may require resources that are cost-prohibitive for some companies or organizations. Implementation of an RPM system typically requires system servers, terminals, system software, agents and other items associated with a communications network.
• RPM service provider delivering provisioning services such as identity, entitlement, policies and roles for the general public to utilize when the need for resource provisioning arises.
• provisioning services such as identity, entitlement, policies and roles for the general public to utilize when the need for resource provisioning arises.
• One area of particular concern in an RPM system relates to resource usage.
• a resource that has not been accessed for a period of time by an employee or other person to whom the resource has been made available, or, in other words, a dormant resource, and, conversely, a resource that has been accessed excessively, can present a plurality of problems to an organization managing the resource. For example, a resource that has not been accessed for a period of time but remains available to an employee unnecessarily burdens the resource provisioning management system. In order to be operational, resources demand system overhead.
• a resource may utilize system memory, system processor time, and other elements of a resource provisioning management system in order to be functional for employees or other persons utilizing the resource.
• Resources place a burden on resource provisioning management system overhead in connection with such utilization. This burden may be acceptable for a resource that is accessed regularly, but for a resource that is not accessed regularly the burden is unnecessary.
• a dormant resource in a resource provisioning management system renders the system inefficient.
• various allocations of a system must be made for the resource, including, but not limited to, allocations of system memory, allocation of system administrative time, and other allocations necessary for the proper functioning of the resource.
• a dormant resource may also compromise the security of a resource provisioning management system.
• An open account on any resource carries with it various levels of vulnerability.
• Hackers routinely look for accounts on which there has been little or no usage to enter into system servers and databases. If an open account is unused or used infrequently, it is possible that the account receives little attention from system administrators. Thus, the likelihood that a breach of system security through that particular account is noticed by system administrators becomes small.
• a resource provisioning management system without an adequate identity policy in place, it can become virtually impossible for a resource provisioning management system to manage user identities across multiple resources. For example, suppose an identity policy exists in a resource provisioning management system that identifies each user of a particular resource, such as, for example, a telephone account, by the user's last name preceded by the first initial of the user's first name. Thus, if a user's name were "John Williams," his account identity would be "jwilliams.” However, without further provisions in the identity policy to make a suitable distinction between users bearing identical names, any other user of the resource with the name of "John Williams" would have the exact same account identity and would be indistinguishable from the first "John Williams".
• an identity policy is not implemented that efficiently identifies and manages all account holders on the system, overall system performance may suffer dramatically. In addition, a poorly crafted identity policy may compromise system security. If an account holder within an RPM system is identified in several different ways within the system, and if the identity policy implemented in the system is inadequate to coordinate multiple account identities, it may be difficult or impossible for an RPM system to identify on which account a breach of system security occurred and by whom the breach was perpetrated.
• Some identity policies currently used by various organizations supplying resources allow for interactive selection of an identity between the system and the account holder. For example, some Internet email service providers allow an account holder to choose an identity for purposes of email.
• an account holder by the name of "John Williams” might enter, as his email identity, the identity "jwilliams.”
• John Williams is a relatively common name and, more than likely, the email identity "jwilliams” will already have been taken when a person named John Williams tries to establish an identity for his account, the system may notify the account holder and request that a different identity be chosen.
• This type of situation has led to the proliferation of email identities of the type "jwilliams 100" or “jwilliamsmiami” or other email identities that somehow serve to distinguish one or more persons with identical names. Allowing interaction between a system and an account holder to establish an identity on the system results in a complete lack of consistency in system identities and, consequently, increased difficulty in managing system accounts.
• Yet another area of particular concern in an RPM system relates to passwords required by users to enter and utilize such resources.
• a robust and well-designed policy for establishing passwords provides a mechanism for maintaining system privacy and security.
• a poorly crafted password policy in an RPM system may compromise system security.
• Some password mechanisms used by various organizations supplying and/or utilizing resources provide virtually no restrictions on the types of passwords that are acceptable for entering and utilizing a resource. It would not be uncommon for these organizations to allow any characters to make up a password so long as the password consists of a minimum number of characters.
• a password may consist of any characters so long as the password is at least eight characters long.
• These characters, from left to right, are the characters that correspond to the home keys on a computer keyboard, and represent a typical, easily formulated, easily remembered, and, unfortunately, easily discoverable password.
• embodiments of the present invention relate to systems and methods for provisioning users based on policies, user roles and attributes, which reduces or minimize the number of unique roles which must be created. Further embodiments of the present invention relate to systems and methods for provisioning users based on policies which allow both "soft" and “hard” resources to be provisioned. Yet further embodiments of the present invention relate to systems and methods for provisioning resources in bundles. Yet further embodiments of the present invention relate to systems and methods for provisioning users based on policies that can take various process paths that are established as a result of the entry of user parameters. Yet further embodiments of the present invention relate to systems and methods for provisioning users based on policies which may require information or authorization from another person.
• the method and system involves establishing a set of attributes and user roles, and defining a plurality of resource access policies based on selected attributes and user roles.
• the method and system also involves receiving attribute information and user role information for a particular user or resource, determining which resource access policies are applicable to the user based on the received user role information and attribute information, and provisioning the user with resources based on the applicable resource access policies.
• the method also includes establishing a set of attributes, organizational information, and user roles and defining a plurality of resource provisioning policies. based on selected attributes, organizational information, and user roles.
• the method also includes receiving attribute information and user role information for a particular user or resource, determining which resource provisioning policies are applicable to the user based on the received user role information, organizational information, and attribute information, seeking additional information or authorizations from third parties in accordance with the applicable resource provisioning policies, and provisioning the user with the resources specified by the applicable resource provisioning policies if all necessary additional information or authorizations have been received from the third parties.
• the method may also include provisioning over a network and provisioning users with external resources.
• a method for provisioning resources of a plurality of organizations using a single logical server, each organization having internal resources may also comprise the steps of establishing a set of attributes, organizational information, and user roles for each organization; defining a plurality of resource access provisioning policies for each organization based on selected attributes, organizational information, and user roles; receiving attribute information, organizational information, and user role information from each organization for a particular user or , resource, or database; determining which resource provisioning policies are applicable to users based on the received user role information, organizational information, and attribute information; grouping each organization together into a resource exchange; and cross-provisioning users from a remote, centralized location with resources from organizations within the resource exchange based on the applicable resource access provisioning policies.
• the method may also include the step of providing a translational map for organizations within the resource exchange. Further, the method may include the step of providing high level authentication of organizations within the resource exchange. The method may further include the step of providing identity synchronization of organizations within the resource exchange. The method may further include the step of providing an audit trail for organizations within the resource exchange, and may further include the step of providing anonymity for organizations within the resource exchange.
• a method for provisioning resources of a plurality of organizations using a server in a public provision infrastructure may also comprise the steps of establishing a set of attributes, organizational information, and user roles for each organization having resources; defining a plurality of resource access provisioning policies for each organization having resources based on selected attributes, organizational information, and user roles; receiving attribute information, organizational information, and user role information from each organization for a particular user or , resource, or database; receiving attribute information, organizational information, and user role information from members of a general public desiring use of a resource within the public provisioning infrastructure; generating a resource provisioning ticket for the members of the general public; determining which resource provisioning policies are applicable to users based on the received user role information, organizational information, and attribute information; and forwarding the provisioning ticket to a vendor of a particular resource.
• a system for provisioning resources of a plurality of organizations may comprise a third party resource provisioning management service provider; a server for provisioning resources, wherein the server is operated by a third party resource provisioning management service provider; internal resources belonging to each organization; and a network providing a link between the server and the internal resources; wherein the third party resource provisioning management service provider provisions the internal resources of each organization over the network at the request of the organization.
• the system may further comprise external resources, wherein the external resources are provisioned for each organization.
• a system for provisioning resources of a plurality of organizations may also comprise a third party resource provisioning management service provider; a server for provisioning resources, wherein the server is operated by a third party resource provisioning management service provider; a resource exchange made up of the plurality of organizations, each organization having internal resources; and a network providing a link between the server and the internal resources, wherein the third party resource provisioning management service provider cross-provisions the internal resources of each organization within the resource exchange over the network at the request of each organization.
• the system may further comprise a translational map for organizations within the resource exchange, means for each high level authentication of organizations within the resource exchange, means for identity synchronization of organizations within the resource exchange, and means for providing an audit trail for organizations within the resource exchange.
• a system for provisioning resources of a plurality of organizations may also comprise means for establishing a set of attributes, organizational information, and user roles for each organization having resources; means for defining a plurality of resource access provisioning policies for each organization having resources based on selected attributes, organizational information, and user roles; means for receiving attribute information, organizational information, and user role information from each organization for a particular user or , resource, or database; means for receiving attribute information, organizational information, and user role information from members of a general public desiring use of a resource within the public provisioning infrastructure; means for generating a resource provisioning ticket for the members of the general public; means for determining which resource provisioning policies are applicable to users based on the received user role information, organizational information, and attribute information; and means for forwarding the provisioning ticket to a vendor of a particular resource.
• Soft resources may include e-mail and voice mail accounts, application programs, databases, files, folders, the Internet, Web pages, organizational Intranets, messages to third parties, digital certificates for enabling the user to access encrypted resources, the capability to order products over the Internet, the ability to order a corporate credit card, access to financial services providers, and the like.
• Soft resources may include resources managed at remote sites on a wide area network (WAN).
• WAN wide area network
• workflow may be added, deleted or modified by pre-defined users from a remote site on the WAN.
• users may be provisioned with "hard” resources such as telephones, computers, cellular telephones, pagers, personal digital assistants, desks, chairs, file cabinets, other physical components, and the like.
• multiple resources may be bundled in one or more groups, such that users may be provisioned with resource bundles.
• Embodiments of the present invention may also relate to systems and methods for establishing a dormant resource policy for resources considered dormant and what activity should be taken as a consequence thereof.
• Yet further embodiments of the present invention relate to systems and methods for establishing a policy for excessive use of resources and what activity should be taken as a consequence thereof.
• Yet further embodiments of the present invention relate to systems and methods for establishing a usage policy for use of resources that relieves system overhead demands.
• Yet further embodiments of the present invention relate to systems and methods for establishing a usage policy for use of resources that makes efficient use of system components.
• Yet further embodiments of the present invention relate to systems and methods for establishing a usage policy for use of resources that maintains system integrity. Yet further embodiments of the present invention relate to systems and methods for establishing a dormant resource policy that ascertains a reason for dormancy and reconciles the resource. Embodiments of the present invention may also relate to systems and methods for establishing identities for users of a managed resource. Yet further embodiments of the present invention relate to an identity policy in an RPM system that provides rules allowing the system to uniquely identify each user within the system. Yet further embodiments of the present invention relate to an identity policy in an RPM system that include rules that determine how users in an RPM system are identified within the system and within each resource managed by the system.
• Yet further embodiments of the present invention relate to an identity policy in an RPM system that determines how users in multiple managed resources are identified within and across the multiple resources. Yet further embodiments of the present invention relate to an identity policy in an RPM system that provides rules for creating an identity for a user of a system resource from the user's attributes, including, but not limited to, the user's name and the user's role within an organization, and, further, may provide the capability to utilize different combinations of attributes to formulate a unique identity. Yet further embodiments of the present invention relate to an identity policy in an RPM system that combines a user's attributes in such a way that a reasonable user identity may be generated for a particular user in the event some of that user's attributes conflict with another user of the resource.
• an identity policy when generating an identity for a user, will not only take into consideration attributes of the user for whom the identity is being generated, but also attributes of other users of the resource. Yet further embodiments of the present invention relate to an identity policy in an RPM system that provides rules for automatically resolving conflicts between user identities. Yet further embodiments of the present invention relate to an identity policy in an RPM system that provides rules for creating user identities without user interaction. Embodiments of the present invention may also relate to methods and systems for establishing passwords in an RPM system. Yet further embodiments of the present invention relate to methods and systems for establishing a password policy in an RPM system that restricts certain passwords from being utilized by users on the system.
• Yet further embodiments of the present invention relate to methods and systems for establishing a password policy in an RPM system that requires users to formulate passwords that are acceptable to each resource in the system and that comply with company or organizational policy on passwords generally. Yet further embodiments of the present invention relate to methods and systems for establishing a password policy in an RPM system that combines password rules for each resource within the system into a unified policy applied across all resources within the system. Yet further embodiments of the present invention relate to methods and systems for establishing a password policy in an RPM system that recognizes conflicts in password syntax in such embodiments. Yet further
• FIG. 1 is a diagram of an external view of an Application Service Provider (ASP) environment embodiment of the present invention.
• ASP Application Service Provider
• FIG. 2 is a diagram of an external view of a Corporate Enterprise environment embodiment of the present invention.
• FIG. 3 is a diagram of logical architecture of a system according to an embodiment of the present invention.
• FIG. 4 is a diagram of a component arrangement of a system according to an embodiment of the present invention.
• FIG. 5 is a diagram of an example deployment of a system according to an embodiment of the present invention.
• FIG. 6 is a diagram of another example deployment of a system according to an embodiment of the present invention.
• FIGS. 7A-E are sequence diagrams of interactions relating to authenticating a user, adding a user, provisioning a service for a user, provisioning services for a new user based on policy, and synchronizing services and enforcing policy violations.
• FIG. 8 is diagram of graphical interfaces in a sequence relating to a provisioning process.
• FIG. 9 is a diagram of a generalized architecture of a resource provisioning management system according to an embodiment of the present invention
• FIG. 10 is a diagram of a resource provisioning management system utilizing a centralized server according to an embodiment of the present invention.
• FIG. 11 A is a flow diagram of resource provisioning management using a centralized server according to an embodiment of the present invention.
• FIG. 1 IB is another flow diagram of resource provisioning management using a centralized server according to an embodiment of the present invention.
• FIG. 12 is a diagram of a resource provisioning management system utilizing a centralized server and external resources according to an embodiment of the present invention.
• FIG. 13 is a diagram of a resource provisioning management system utilizing a centralized server providing cross-provision of affiliate resources in a resource exchange according to an embodiment of the present invention.
• FIG. 14A is a flow diagram of a resource provisioning management method utilizing a centralized server providing cross-provisioning of affiliate resources in a resource exchange according to an embodiment of the present invention.
• FIG. 14B is another flow diagram of a resource provisioning management method utilizing a centralized server providing cross-provisioning of affiliate resources in a resource exchange according to an embodiment of the present invention.
• FIG. 15 is a diagram of a resource provisioning management system utilizing a centralized server providing a public provisioning infrastructure according to an embodiment of the present invention.
• FIG. 16 is a flow diagram of a resource provisioning management method utilizing a centralized server providing a public provisioning infrastructure according to an embodiment of the present invention.
• FIG. 17 is a diagram of various levels of a resource provisioning management system utilizing a centralized server according to an embodiment of the present invention.
• FIG. 18 is a diagram of a Prior Art wide area network environment.
• FIG. 19 is a diagram of a resource provisioning management system environment according to an embodiment of the present invention.
• FIG. 20 is a diagram of a resource provisioning management system environment according to a further embodiment of the present invention.
• FIG. 21 is a flow diagram of generalized method for managing usage according to an embodiment of the present invention.
• FIG. 22 is a flow diagram of a method for managing usage according to an embodiment of the present invention.
• FIG. 23 is a block diagram of a system for reconciling account usage according to a usage policy in an embodiment of the present invention.
• FIG. 24 is a flow diagram of a method for generating a user identity according to an identity policy.
• FIG. 25 is a flow diagram of a method for generating a user identity across multiple resources according to an identity policy.
• FIG. 26 is a flow diagram for generating user identities according to an identity policy in an embodiment of the present invention.
• FIG. 27 is a block diagram of a system for assigning user identities in an RPM system via an agent.
• FIG. 28 is a flow diagram of a method for establishing passwords complying with a password policy.
• FIG. 29 is a flow diagram of a method for automatically generating and establishing passwords complying with a password policy before a user has entered a system.
• FIG. 30 is a diagram of a computer keyboard detailing passwords based on a keyboard sequence.
• FIG. 31 is a diagram of a system combining various resource password rule sets into a password policy.
• FIG. 32 is a flow diagram of a method for determining overly restrictive rule sets.
• FIG. 33 is a block diagram of a system for establishing passwords in an RPM system via an agent.
• FIG. 34 is a block diagram of an agent acting as a translator between a resource provisioning management system and a managed resource according to an embodiment of the present invention.
• FIG. 35 is a more detailed block diagram of an agent acting as a translator between a resource provisioning management system and a managed resource according to an embodiment of the present invention.
• FIG. 36 is a block diagram illustrating an agent having a separate protocol plug-in library and ERMA library for each operating system supported, according to an embodiment of the present invention.
• Embodiments of the present invention relate to a system operable on a communication network for provisioning users with resources based on policies, roles and attributes.
• Embodiments of the present invention will be generally referred to herein as a resource provisioning management (RPM) system, or simply “the system.”
• RPM resource provisioning management
• the system may be implemented with software applications and modules deployed on various processor or computer systems connected for communication over one or more network or non-network links.
• the processors in which the modules and applications are deployed may differ from system embodiment to system embodiment.
• the types of users, administrators and other entities that interact with the system may differ from system embodiment to system embodiment.
• Preferred embodiments of the system are designed to provide a high level of flexibility to accommodate the needs of a variety of potential applications of use.
• FIGS. 1 and 2 Two representative examples of system environments in which embodiments of the present invention operate are shown in FIGS. 1 and 2, respectively.
• FIG. 1 shows a generalized representation of an Application Service Provider (ASP) environment embodiment
• FIG. 2 shows a generalized representation of an Enterprise environment embodiment of the system.
• a platform computer system 10 is coupled for communication with a plurality of user computers, administrator computers and other entities over a network 12, depending upon the needs of the system.
• Further entities, including external systems, databases and directories, third party service providers, managed services and system administrators may be coupled for communication to the platform system 10 through the same network or through other networks or dedicated communication links, depending upon the needs of the system.
• the network environment may also include one or more network servers, routers and other network structure and devices (not shown).
• a network environment may comprise a local area network (LAN), for example, within an office or building.
• the network environment may comprise a wide area network (WAN) including, but not limited to, the Internet.
• the platform system 10 may be implemented, for example, with one or more processors or computers which include or operate with associated memory and software modules and applications to carry out various functions described herein.
• the platform system 10 carries out various functions associated with provisioning users with resources based on policies, roles, organizational information, and attributes, as described below.
• processors or computers associated with the users, administrators, and service providers, for example, implemented by software running on those computers, as described below.
• Embodiments of the present invention can therefore run on a cluster of computers or on a single computer. These computers may or may not have multiple processors.
• Users, and users acting in administrator roles may operate computers which may include suitable processors, memory devices and user interface devices, such as, but not limited to, display devices, keyboards, mouse devices, or the like, to allow users to obtain and communicate information over the network or other communication link.
• Suitable software may be stored at, or be accessible to, the user and administrator Web browsers or computers, to provide user and administrator interface functions and to allow communication of electronic information and content, such as data, files, programs and other software over the network, in accordance with well known network communication technology.
• software for implementing functions associated with the user and administrator according to embodiments of the present invention may also be stored at, or be accessible to, the user and administrator Web browsers, respectively.
• the system 10 provides a platform for defining policies and provisioning services to a user interacting with the system, or a user interacting with the network on which the system is operating. The system may designate and track the types of services as well as the types of access to these services for a large number of users. In the generalized examples of FIGS.
• the platform system 10 may receive requests for services from user computers.
• the platform system 10 may also receive information from administrator computers relating to, for example, authorizations of users' requests or changes in users, policies or roles.
• the platform system 10 may also provide information to the administrator Web browsers or computers, including, for example, reports on operation and service usage.
• the platform system 10 may provide requests, instructions, or other information to service providers or managed services computers related to providing services to the users, based on user requests, policies, roles, organizational information, and attributes.
• the platform system 10 may control access to services, such as data, files, programs or other electronic information from database or storage systems to the users, based on user requests, policies, roles, organizational information, and attributes.
• a system according to the FIG. 1 embodiment is deployed in an ASP environment.
• An ASP may be described as an organization that deploys, hosts and manages access to applications such as software and other resources to multiple parties from a centrally managed facility.
• the applications are typically delivered over networks, including, but not limited to the Internet, on a subscription basis.
• RPM system administrators 14 are designated as RPM system administrators 14 with access rights greater than other users at the same company.
• RPM system administrators like other users at the same company, are capable of performing operations in accordance with policies put in place by the ASP customer, which may be based on role and organizational information for each user.
• these RPM system administrators are additionally provided with certain system configuration responsibilities, including selecting the processors on which certain modules or applications of the system are deployed, as described below.
• an RPM system administrator may be able to manage, for example, organizations, users, services, roles, workflow rules, policies and the system itself.
• An RPM provisioning system administrator may also generate reports to audit the current and historical status of the system, and may also be authorized to manage different portions of the system's data by being granted permission to access such data.
• the responsibilities of any given RPM system administrator may range from organization management only, to entire system management, depending upon the permission or access rights provided to the given RPM system administrator.
• the system in FIG. 1 may also interface, for example, with one or more Customer End-Users 16, Customer Administrators 18, and Customer Supervisors 20. In the illustrated example, the interfaces for the Customer End-User 16, Customer Administrator 18, and Customer Supervisor 20 are Web enabled for connection over the Internet 12.
• a Customer End-User 16 is a user having access to resources in accordance with policies put in place by the customer
• a Customer End-User 16 may be an employee of an ASP's customer who is provided access to certain ASP resources.
• a Customer End-User 16 would typically be authorized only to perform self-administration of its own personal and account information stored in a Lightweight Directory Access Protocol (LDAP) Directory server (not shown in FIG. 1) by communicating requests for provisioned services/resources over the network using a Web browser.
• LDAP Lightweight Directory Access Protocol
• a Customer Administrator 18, as shown in FIG. 1 is also a user having access to resources in accordance with policies put in place by the customer.
• a Customer Administrator 18 may be an employee of an ASP's customer who is responsible for administering portions of a customer's organization, such as managing organizational and user information and, is therefore provided with permissions or access rights to appropriate system data to perform such functions.
• a Customer Administrator may define and manage use of user roles and policies and, thus, may be provided with permission or access rights to the LDAP Directory Server.
• a Customer Administrator may define or change users, roles, policies, organization hierarchy or the like.
• a Customer Administrator may also generate reports to audit the current and historical status of the system, and therefore may be provided with permission or access rights to the RPM system server containing a report engine 150 (see FIG. 3).
• a Customer Administrator 18 typically would be authorized to manage different portions of the system's data by being granted permission to access such data.
• a Customer Administrator 18 may range from organization management only, to entire system management, depending upon the permission rights granted to the Customer Administrator.
• a Customer Supervisor 20, as shown in FIG. 1, is also a user having access to resources in accordance with policies put in place by the customer.
• a Customer Supervisor 20 may be an employee of an ASP's customer who is responsible for managing or supervising groups of users in the customer organization.
• a Customer Supervisor 20 may delegate responsibilities to another Customer Supervisor. In preferred embodiments, the delegation of responsibility may be authorized for a pre-defined period of time.
• a Customer Supervisor 20 may be an employee of an ASP's customer who is responsible for managing or supervising groups of users in the customer organization.
• a Customer Supervisor 20 may delegate responsibilities to another Customer Supervisor. In preferred embodiments, the delegation of responsibility may be authorized for a pre-defined period of time.
• FIG. 1 also indicates that the system may interface with one or more External Systems 22.
• An External System 22 may be any ASP system that may wish to retrieve customer or managed resource information that is managed by the system 10. This may be accomplished via a direct interface to an RPM directory (see reference character 58 in FIG. 3) used by the system 10 to store such information. As illustrated in FIG.
• the system may also interface with one or more Customer Datastores 24.
• this interface is Internet capable.
• a Customer Datastore 24 may be a relational database or directory that stores ASP customer information. Note that customer-relevant data such as the customer's organization, roles, account information, and user information is stored in the directories within the Customer Datastores 24, while in-progress workflow information, audit logs, historical audit trail information (e.g., requests that have been approved), system state information (e.g. workflow state, requests that have not yet been approved), and information about remote services is stored in the databases within the Customer Datastores 24.
• the system 10 may also interface, for example, with a Managed Service 26, as shown in FIG. 1. In preferred embodiments, this interface is Internet capable.
• a Managed Service 26 may be an application, device or datastore that the system 10 proactively manages.
• a Managed Service may comprise a network device that has an account maintenance system, such as an RPM system, an operating system, an application (e.g., a human resources (HR) system, enterprise resource planning (ERP) system, etc.), public key infrastructure (PKI) certificates, databases, financial services, and the like.
• the Managed Service's system may function independently.
• the datastore for the system 10 and that of a Managed Service may be synchronized periodically or at defined or irregular intervals, for example, to update the datastore.
• the system may also interface, for example, with a Third Party Service Provider 28, as shown in FIG. 1. In preferred embodiments, this interface is Internet capable.
• a Third Party Service Provider 28 may be an external organization that provides services that may be provisioned through the system 10.
• a Third Party Service Provider 28 may be, for example, a credit card service that provides credit cards or credit accounts that are provisioned through the system 10.
• a Third Party Service Provider 28 may be a telephone service company that provides telephone line accounts that are provisioned through the system 10. It should be understood that these are merely representative examples. Many other types of services may be provided by a Third Party Service Provider in accordance with further system embodiments.
• the system 10 may also interface, for example, with a Partner System 30, as shown in FIG. 1. In preferred embodiments, this interface is Internet capable.
• a Partner System 30 may be similar or identical to the system 10, but used by a business partner or customer and integrated into the system 10.
• the Partner System 30 represents a system-to-system interface which, in preferred embodiments, may be used to provide the seamless integration of multiple systems.
• a system according to the embodiment of FIG. 2 is deployed in an Enterprise environment.
• An enterprise may be any organization that desires or requires management and administration of its resources, including, but not limited to, companies, firms, educational organizations, governmental organizations, or other groups or associations.
• the system 10 supports the same capabilities described above with respect to FIG. 1, but with some differences for different kinds of users.
• the system 10 may interface with a System Administrator 50 in a manner similar to the RPM system administrator interface described with respect to FIG. 1.
• the System Administrator 50 may be an employee of the Enterprise, and may have responsibility for configuring the system.
• a System Administrator 50 may be able to manage organizations, users, services, roles, workflow rules, policies, and the system itself. A System Administrator 50 may also generate reports to audit the current and historical status of the system. A System Administrator 50 may be authorized to manage different portions of the system's data by being granted permission to access such data. The responsibilities of a System Administrator 50 may range from organization management only, to entire system management. Instead of Customer End-Users, Customer Administrators and Customer Supervisors described with respect to FIG. 1, the environment in FIG. 2 includes Employees (or Partners) 52, Employee Administrators 54, and Supervisors 56. Each may interface with the system 10, and are preferably web enabled for interfacing with system 10 over the Internet. An Employee may be an employee of the enterprise.
• An Employee 52 is a user having access to resources in accordance with policies put in place by the enterprise. Typically, an Employee may only be authorized to perform self-administration of the Employee's own personal information.
• An Employee Administrator 54 as shown in FIG. 2, may be an employee of the Enterprise who is responsible for Enterprise employee administration.
• An Employee Administrator 54 is a user having access to resources in accordance with policies put in place by the Enterprise, who is responsible for managing the Enterprise's organizational and user information. This may involve defining, changing and managing user roles and policies.
• An Employee Administrator 54 may also generate reports to audit the current and historical status of the system.
• An Employee Administrator 54 may be authorized to manage different portions of the system's data by being granted permission to access such data. The responsibilities of an Employee Administrator 54 may range from organization management only, to entire system management.
• An Enterprise Supervisor 56 may be an employee of the Enterprise who is responsible for managing groups of users within the Enterprise. Typically, an Enterprise Supervisor 56 may make changes to users and approve requests made by users. An Enterprise Supervisor 56 may also generate reports to audit the current and historical status of the system.
• FIG. 2 also indicates that the system may interface with a Directory 58.
• a Directory 58 may be used by the system to store organizational information, user or employee information, partner information, role information, account information, resource information or the like. In one embodiment, the Directory is an LDAPv3 directory. The directory may be supplied by an Enterprise customer, or may be installed solely for the system 10. As illustrated in FIG. 2, the system may interface with a Human Resources
• a Human Resources Datastore 60 may be a database or directory that stores Enterprise employee and partner information.
• the system 10 may also interface with a Partner System 62, Third Party Service Providers 64 and Managed Services 66, in a manner similar to that described above with respect to the Partner Systems 30, Third Party Service Providers 28 and Managed Services 26 in FIG. 1.
• the system 10 in FIGS. 1 and 2 may be used to manage the provisioning of a variety of services or resources to users.
• a service may be any type of resource that may be accessed one or more times by users of the system. For example, a cellular telephone account or an account with a credit card company may be services.
• the system may, for example, designate that certain users have access to a cellular telephone account and a credit card account, and may track the usage by the user of these accounts.
• the system may also set various rules and policies regarding the use of these accounts by the user, depending on the status of the user.
• an organization may provision, or allocate, services to a user within the organization based on defined policies, organizational information, attributes, and the role of the user in the organization.
• the policies, or rules may be pre-defined for the organization based on the needs of the organization and incorporated into the system.
• the policies may be flexible enough to account for the various roles within the organization and the services each role requires. For example, assume an organization hires a new employee in the capacity of System Administrator.
• a pre-set policy for the organization provides that each employee receives regular telephone service, a regular telephone, and an e-mail account
• the system upon the hiring of a new System Administrator, the system will automatically notify the appropriate parties to set up a regular telephone account and an e-mail account for the System Administrator and deliver a regular telephone to the System Administrator's office.
• a pre-set policy for the organization is that each System Administrator has access to all system databases. The system will then automatically grant the System Administrator access to all system databases. For purposes of illustration only, assume that the same organization hires a new employee in the capacity of Outside Salesperson.
• the system automatically notifies the appropriate parties to set up a regular telephone account and an e-mail account for the Outside Salesperson and deliver a regular telephone to the Outside Salesperson's office.
• the organization has a pre-defined policy that Outside Salespersons do not have access to all system databases, as do System Administrators, then access to these databases may be automatically denied by the system to the Outside Salesperson.
• the system may automatically set up a cellular telephone account for and order delivery of a cellular telephone to the Outside Salesperson.
• Preferred embodiments of the system described herein perform these actions automatically based on the role of the person within the organization and policies that are pre-defined for the organization.
• the policies may be based on the needs of the organization and the requirements of each particular role within the organization, such that resources may be provisioned to each user to meet the needs and the requirements of the user's particular role in the organization.
• FIG. 3 A logical architecture view of applications and modules of a system 10 according to one embodiment of the present invention is shown in FIG. 3.
• an example system embodiment may be characterized as a group of software modules with interfaces that allow the modules to collaborate with each other in order to implement the features of the system.
• each module may be a self-contained unit of software that may be replaced within the system without compromising the integrity of the system, as long as the interface of the replaced module is maintained. While the interface to the module may remain consistent, the internal architecture of each module may vary, depending upon the application of use.
• the modules may be grouped into an applications subsystem 102 and a platform subsystem 104.
• the applications subsystem 102 is directed toward applications that help a user or an administrator perform specific functions and, thus, may be implemented in software running on computers operated by users or administrators.
• the platform subsystem is directed toward services and utilities for enabling applications to interact with directories and databases containing the state of a network and the services on that network that are being managed.
• the platform subsystem may be implemented in software running on the platform computer system.
• the applications subsystem 102 may include, for example, administration applications 106, application framework 108 and user applications 110.
• Admimstration applications 106 are applications used by an administrator, via the network, for various administration purposes. These applications may include one or more System Configuration applications 112, which provide an interface to allow an administrator to configure certain properties of the system.
• the administrator interface may allow administrators to make system configuration settings, including, but not limited to, directory communication settings, logging properties, e-mail service settings, and garbage collection settings.
• the System Configuration applications 112 may include an interface to a Form Generation application 114, invoked to provide custom forms for data managed by the system. An example of such a form is illustrated in FIG. 8.
• the Form Generation application 114 may also allow an administrator to create custom forms to be displayed in user and administrator applications.
• the Form Generation application may comprise a graphical user interface builder that associates system data attributes with graphical controls, which may include, but is not limited to, a "What You See Is What You Get" (WYSIWYG) graphical user interface builder.
• the administration applications 106 may also include one or more Service Configuration applications 116, which provide an interface to allow administrators to configure certain properties of a service managed by the system.
• properties of a managed service include, but are not limited to, network location (IP address and port number), encryption for use and management, administrator login (ID and password), and management protocols.
• a service may be bundled as a set with other services that are related through administrator- defined dependencies defined through the administrator interface.
• the Configuration applications 116 may include an interface to the Form Generation application 114 to provide custom forms for the account information to be used in the User Management web user application, which is the Web-based user interface that allows a user to add, modify, and delete other users.
• the application framework 108 comprises a framework that integrates administrator and user applications.
• the application framework may include one or more System Browser applications 118, accessible by the system administrator, that preferably provide a graphical display of the entire managed contents of the system in a format that is easy to use.
• the user applications 110 are applications used by an end-user, over the network, for various purposes.
• the user applications 110 may include one or more Organization Management applications 120 that preferably provide a graphical display of an organization's hierarchy of data in a format that is easy to use. From this interface, organizational units, locations, business partner organizations, users, system roles and organizational roles in the form of a tree view can be constructed and altered.
• the user applications 110 may include one or more Request Management applications 122 that provide an interface for the user to review and manage change requests pending within the system.
• a change request is a request to change one or more attributes of a user, or a request to change one or more attributes of a service belonging to that user.
• the interface may allow, for example, users acting in a supervisory role to approve or disapprove change requests.
• the user applications 110 may also include one or more Form Viewer applications 124 that dynamically display forms as they are designed by the Form Generation administration application 114.
• the access level of the user determines which form, if any, the Form Viewer application will display in different situations.
• One or more Report Viewer applications 126 may be included for allowing a user to instruct a Report Engine in the platform subsystem 104 to execute predefined reports, and for displaying the results to the user.
• the access level of the user determines which reports the Report Viewer will provide.
• the user applications include applications for allowing a user to submit a request for provisioned services.
• the user applications 110 may also include a Policy Management application 128 that provides an interface for defining policies that control the provisioning of services to users.
• policies determine an association between the users and the services or resources, and constraints on those services provisioned to the users, based on attributes and user roles.
• the policies may define one or a series of approvals that are required before provisioning a given service or any service to a user. For example, such approvals may be required from one or more other users acting in a supervisory role. Policies may require one or more approvals if an attribute constraint is violated.
• the approvals may be defined using a Workflow Management application 130, which provides an interface for defining the approval process needed for a request in the system.
• the platform subsystem 104 includes service and utility modules that enable various applications of the system to interact with directories and databases that hold information relating to the state of the system and services available over the network.
• the platform subsystem 104 may include, for example, application services 132, data services 134 and remote services 136.
• the platform modules are designed to be as independent as possible of any domain-specific information. This enables the platform to be easily applied to a different domain and support a new set of applications without (or with minimal) re-architecture.
• the application services 132 includes modules that may be used by several other system applications (client applications) to perform a service. These service modules may provide a separate and independent set of capabilities to their client applications.
• the applications services modules 132 may include an Authorization module 138 for providing a set of authentication implementations that may be used by client applications. Such implementations may include, but are not limited to, simple password authentication techniques or X.509 certificate authentication.
• the application services 132 may also include an Authorization module 140 that provides an interface for authorized users to define authorization rules, and enforces those rules as client applications attempt operations on the system, such as requesting services or data. These rules may apply to accessing data within the system, as well as to operations that can be applied to the system data, such as add, modify, or delete operations.
• a Business-To-Business (B2B) Gateway module 142 may be included to provide an interface to an external access management system such as the RPM system described herein, or a comparable third-party system.
• the B2B Gateway module 142 may provide an external system the ability to add, modify, delete and query user information. In preferred embodiments, these functions may be performed through an open protocol such as, but not limited to, secure hypertext transport protocol (HTTPS) to enable secure communications through the Internet. In preferred embodiments, requests made by external systems to carry out such functions may be stored in an RPM database or other storage facility 144 for auditing purposes.
• the applications services 132 may also include a Logging module 146 that provides a utility for logging information, such as alarms and historical events, into persistent storage (e.g. the RPM database 144) associated with the platform system.
• the applications services 132 may also include a Policy Engine 148 for executing policies that associate users with services.
• the Policy Engine 148 functions to determine whether or not provisioning requests conform to defined policies and to provide correct recovery procedures in the event that a policy is violated. If an approval is needed for a provisioning request, the Policy Engine 148 interfaces with a Workflow Engine 150 to notify and obtain authorization instructions from the appropriate authorization entity, which may be, for example, one or more users having pre-defined supervisory roles.
• Workflow Engine 150 functions to execute and track transactions within the system. Such transactions may include provisioning and de-provisioning of services, user status changes, and the approval process associated with a provisioning request in the system. In preferred embodiments, users with appropriate access levels may, through a client application, query the Workflow Engine for status information relating to a transaction (such as a provisioning request) being executed by the system.
• the applications services modules also include a Report Engine 152 for executing predefined reports and formatting requested information. Note that requests for reports will only come directly from users of the system or the system administrator. They will not come from other systems.
• the data services modules 136 includes modules that assist other modules in interacting with directories and databases that hold the network's state and the system's configuration.
• the data services modules 136 may include an Information Model 154 that provides a logical view of the data in persistent storage in a manner that is independent of the type of data source that holds the data.
• the model abstracts the details of the stored data into more usable constructs, such as Users, Groups and Services, by adding an object-oriented layer on top of the LDAP-based data model.
• the model may also provide an extendable interface to allow for customized attributes that correspond to these constructs.
• the data services modules 136 may also include a Meta-Data module 156 that provides an interface from which a client may discover the design of the directory schema. Meta-Data is data that defines the content of the actual data. This may be used by a client to manage the data in persistent storage with a dynamic approach.
• the remote services modules 134 provide interaction with external systems for provisioning and de-provisioning services. Synchronization of service information and user information, which is the process of making sure that the information stored on the remote service and the information stored in the RPM system match and is up to date, may also be performed by the remote services modules 134.
• the remote services modules 134 may include a Message Transformation module 158 that provides utilities for defining and executing conversions of messages such as add, modify, delete, and search from one format to another. This module handles message formats, rather than delivery protocols. The actual protocols used are determined at run-time, and may include, but are not limited to, Remote Access Management Protocol (RAMP), Encrypted Socket Protocol (ESP), and Directory Access Markup Language over HTTPS (DAML/HTTPS).
• RAMP Remote Access Management Protocol
• ESP Encrypted Socket Protocol
• DAML/HTTPS Directory Access Markup Language over HTTPS
• the message transformation module 158 transforms between the data format used in the LDAP directory and the format used on the external system. Both formats are key value pairs, but the names of the keys must be mapped as part of the conversion process.
• the remote services modules 134 may also include a Provisioning module 160 for providing an abstraction layer for provisioning products and services through external systems. The abstraction layer hides the protocol being used from the provisioning system. The specific protocols used to perform the provisioning, such as those described above, are preferably isolated from the client of the module. In preferred embodiments, new provisioning protocols may be added to the module without disrupting the module interface.
• the remote services modules 134 also include a Synchronization module 162 that retrieves service information from external systems to keep the service information stored by the system up to date.
• the Synchronization module 162 may retrieve organizational information, such as organizational unit and user information.
• the module is preferably pre-set or configured to define the data needed, how to retrieve it, where to store it and how often to perform retrievals.
• the module may also define rules for resolving conflicts between information retrieved from an external system and currently stored data.
• FIG. 4 An example component view embodiment of the system is shown in FIG. 4, wherein logical applications and modules of FIG. 3 are organized into system components.
• a component is a self-contained and independent software entity that can be deployed onto computer and networking hardware separately from other components within the system.
• applications and modules are arranged to form an Application Server component 202, a B2B Server component 204, a Service Server component 206, a Synchronization Server component 208, a Web Server component 210 and a Workflow Server component 212.
• Each of these components is arranged in one of two domains, a trusted domain 214 and a demilitarized zone (DMZ) domain 216, relative to an untrusted domain 218.
• DMZ demilitarized zone
• a DMZ is a computer network (or a single computer) that is protected from a company's internal network (the trusted domain), but is accessible from the internet.
• the DMZ domain 216 contains systems that are accessible from the internet, and can access the internal network (trusted domain).
• the DMZ domain 216 will not typically contain any sensitive data or critical systems.
• the DMZ domain 216 is created so that even if a hacker breaks into the DMZ, the hacker would still have to break into the internal network from the DMZ. Although every effort is made to protect the DMZ from hackers, a security breach in the DMZ should not result in the theft or corruption of data, or in the loss of a critical system.
• the trusted domain which is the internal network, is considered much more sensitive.
• the Application Server component 202 is composed of modules for supporting users interacting with the system, for example, through the Web Server component 210.
• the Application Server component 202 is coupled to the Web Server component 210 and the Workflow Server through secure connections, such as secure remote method invocation (RMI) connections.
• the Application Server component 202 includes the authentication, authorization, report engine and logging modules of the application services 132 and data services modules 136 shown in FIG. 3.
• the Application Server component also executes logic for the presentation of the Application Services modules, so that the Web Server component may remain as simple as possible. This also provides a security boundary for the Application modules.
• each request to the Application Server (requests from users for provisioned services) is authenticated and authorized before it is executed. At this level, only proper system credentials may be sufficient for authentication, to determine whether a valid Web Server is making the request. However, by requiring authorization of the requesting user before any request is executed, the Web Server component may remain in an untrusted domain.
• the B2B Server component 204 is composed of modules for providing an interface to external systems such as another provisioning system of the type described herein, or other third-party provisioning systems that may communicate requests to the platform system.
• the B2B Server component 204 includes the B2B Gateway module 142 and an Authentication module (see reference character 138 in FIG. 3) for authenticating B2B requests.
• the interface may be provided using a secure network protocol, such as HTTPS, for encrypting data transfer and for authentication of requestors. In preferred embodiments, all requesters must be authenticated and authorized before requests can be fulfilled.
• the B2B Server component 204 is also coupled to the Workflow Server 212, preferably through a secure connection, such as a secure RMI connection.
• the Service Server component 206 is composed of modules for providing an interface to managed resources 26 and 66, and services that issue unsolicited notices or asynchronous provisioning confirmations to the system.
• the Service Server component 206 may be connected to managed services resources 26 and 66, through, for example, a DAML/HTTPS connection.
• the Service Server component 206 may be connected to databases, such as a customer database 24, and third party service provider systems 28 and 64, through suitable connections, which may comprise HTTPS connections or vendor-specific connections.
• the Service Server component 206 includes a Notification Gateway module which provides receiving logic that interacts with the Synchronization and Provisioning modules of the Synchronization Server 208 and the Workflow Server 212 components, respectively, through secure connections such as secure RMI connections.
• the separation of the Notification Gateway module from the Synchronization and Provisioning modules provides a security boundary between untrusted and trusted domains.
• the protocols used may be specific to the managed entity. In preferred embodiments, all requestors must be authenticated and authorized before passing on information to any modules in the trusted domain.
• the Synchronization Server component 208 includes modules for periodically synchronizing service information between the service providers 28, 64 and a local data repository.
• the Synchronization Server component 208 is configured to adapt to the service provider's interfaces to extract desired information.
• the Synchronization Server component 208 includes the synchronization and message transformation modules of the remote services 134, the authentication, authorization, and logging modules of the applications services 132, and the data services modules 136 shown in FIG. 3.
• the Web Server component 210 includes modules for providing users with a graphical interface.
• the Web Server component includes an Applications Presentation module, which creates Web pages for the end user, as well as the authentication module of the applications services module group 132.
• the Web Server component is connected to client systems 16, 52, for example, over an HTML/HTTPS connection.
• the Web Server may be configured to require password authentication, X.509 certificate authentication, or both, when using HTTPS.
• the Workflow Server component 212 includes modules for provisioning and de-provisioning services within the system.
• the Workflow Server component includes the policy engine, workflow engine, logging, email, authentication and authorization modules of the applications services module group 132, as well as the data services modules 136 and the provisioning and message transforming modules of the remote services module group 134.
• the components 202-212 of the FIG. 4 embodiment may be deployed in hardware (processor or computer systems) in a variety of manners.
• the components may be deployed on as few processors as possible, for example, to minimize system complexity and operational cost.
• some or all of the components may be separated and distributed to separate processors to maximize computing resources.
• Many of the modules and applications within components can also be distributed to further maximize computing capabilities.
• some or all of the components may be configured in clusters to take advantage of load balancing algorithms and fail-over capabilities. The responsibility of configuring the system deployment may be provided to a system administrator.
• applications, modules or components containing groups of applications or modules as described above may be provided to a system administrator, for example, in software form (such as on a computer readable storage medium), in hardware or firmware form (such as on circuit boards or cards to be installed in a computer system) or a combination thereof.
• the system administrator may then develop a deployment strategy that meets the organization's performance and security needs and deploy the appropriate modules on appropriate hardware devices to fit the desired strategy.
• the system administrator may be free to deploy all of the components of the system on one processor or distribute clusters of each component in almost any combination, if desired.
• An example of simple deployment option is shown in FIG. 5, where the six components 202-212 of FIG. 4 are clustered onto one processor 302 comprising the Platform system.
• processor 302 represents a server running the provisioning system according to embodiments of the present invention described herein.
• the Platform Processor 302 is coupled to external systems and clients over the network 306, through a Web Server Load Balancer 308.
• One or more Data Server processors 304 may be coupled to the platform processor 302 for deploying the RPM Directory and RPM Database.
• the Data Server processors 304 include a server running a relational database server and an LDAP directory server.
• the FIG. 5 embodiment demonstrates a simple deployment with a clustered deployment of servers that deploy all the components of the system.
• the load balancing algorithms dictate which components are running on specific processors. This deployment embodiment, however, may present security risks because the components are not deployed on separate hardware in separate trusted domains, as described above.
• FIG. 6 Another example of a deployment option is shown in FIG. 6.
• All components 210, 204 and 206 shown in the DMZ domain in FIG. 4 that interface to external clients and systems via the Internet may be clustered on one or more dedicated Web Server processors 402 in FIG. 6 to create a boundary between untrusted and trusted domains, where the web client is in an untrusted domain and the rest of the system components are in a trusted domain.
• the Synchronization Server component 208 is deployed in a separate cluster, so that communication with the service providers can be configured independently of other clusters.
• the interfaces to external clients and systems are isolated to one or more servers containing only those components of the system necessary for external interface.
• Other components of the system including, but not limited to, those components that must remain secure, may reside on servers that do not interface to external clients and servers.
• external users of the system whose trustworthiness has not been verified are isolated from secure portions of the system, and the integrity of secure portions of the system residing on other servers within the system may be protected.
• a Business-to- Business functional area may group all requirements for busiriess-to-business interactions. This may include all external interfaces to partner and service subscriber systems.
• An External Data Input functional area may group all requirements for incorporating current customer information into the system, such as existing users and resources.
• An Organization Management functional area may group all requirements for adding, modifying, and deleting organizations.
• a Policy Based Provisioning functional area may group all requirements for defining the provisioning of services based on attributes or a users' membership in a role, group, organizational unit, or organization.
• a Report Generation functional area may group all requirements for reporting capabilities provided by the system.
• a Service Management functional area may group all requirements for defining services that the system may provision.
• a System Administration functional area may group all requirements for configuring the system.
• a User Interface Customization functional area may group all requirements for providing a user the ability to customize a user interface.
• a User Management functional area may group all requirements for adding, modifying, and deleting users. Other functional areas may be developed based on the needs of the system user.
• FIG. 7 A is a sequence diagram of interactions for implementing a user's authentication to the system.
• the user is presented with an application interface to perform system actions.
• the user is presented an interface to an Organization Management application.
• FIG. 7B is a sequence diagram of interactions for adding a user to the system.
• FIG. 7C is a sequence diagram of interactions for implementing on-demand provisioning of a service for a user.
• FIG. 7D is a sequence diagram of interactions for synchronizing service data with a remote host and enforcing any policies that are violated by detecting changes made on the remote host.
• FIG. 7 A is a sequence diagram of interactions for implementing a user's authentication to the system.
• the user is presented with an application interface to perform system actions.
• the user is presented an interface to an Organization Management application.
• FIG. 7B is a sequence diagram of interactions for adding a user to the system.
• FIG. 7C is a sequence diagram of interactions for implementing on-demand provisioning of a service for
• FIG. 7E is a sequence diagram of interactions for implementing an addition of a user to the system and provisioning of services for that user based on provisioning policies.
• user provisioning is accomplished with the RPM system described hereinabove, which may be programmed into a server coupled to an organization's LAN and may also be coupled to a WAN, preferably the Internet.
• RPM provisions users with "soft” resources (such as accounts) based on only on roles
• RPM provisions users with both "hard” and “soft” resources based on policies, which are defined according to user roles and attributes.
• the RPM system may provision a user with "soft" resources, including, but not limited to passwords, e-mail and voice mail accounts, application programs, databases, files, folders, the Internet, Web pages, organizational Intranets, and the like.
• "soft" resources may include messages to third parties, digital certificates for enabling the user to access encrypted resources, the capability to order products over the Internet, the ability to order a corporate credit card, access to financial services providers, and the like.
• RPM may provision users with "hard” resources such as telephones, computers, cellular telephones, pagers, personal digital assistants, desks, chairs, file cabinets, and other physical components.
• RPM may also provide resource bundles, which are pre-packaged groupings of resources that are typically provisioned together.
• a resource bundle may include a cellular telephone, telephone service, a pager account, voice mail, and Internet access.
• Another example of a bundled account may be Digital Subscriber Line (DSL) access and an Internet Service Provider (ISP) account.
• DSL Digital Subscriber Line
• ISP Internet Service Provider
• RPM systems according to embodiments of the present invention may also have the capability of making provisioning adjustments if a user's roles and attributes change, including de-provisioning, and especially de-provisioning all of the allocated resources once a user has left the company.
• the RPM system provisions users with resources based on policies, which are defined based on roles and attributes.
• a role describes a person's responsibility within the organization, and may include roles such as a manager, secretary, system administrator, committee member, and the like. Each role has only two values. For example, a user is either a manager (a "yes” value), or he is not (a "no” value).
• An attribute is a characteristic or quality of a user or resource, such as "amount of time spent traveling," or "cost.” In contrast to a role, each attribute may have multiple values. For example, the attribute "amount of time spent traveling” may have the values "less than 30%,” “between 30% and 60%,” and “greater than 60%.” Policies are written based on these roles and attributes.
• attributes can be used in addition to roles to define a policy, the task of defining the relationship between users and resources is made more efficient. Attributes can take on multiple values, and thus a single policy definition can be written in Boolean form using IF- THEN-ELSE IF statements (or the equivalent) to account for different attribute values, instead of multiple role definitions using LF-THEN statements. It should be noted that although LF-THEN-ELSE statements are presented herein for purposes of explanation only, in embodiments of the present invention any programming language and syntax capable of implementing the equivalent Boolean statements may be employed. A simple example is illustrative. Suppose that a role-based system has defined three roles as follows:
• a new employee is a marketing manager that travels less than 30% of the time.
• a new employee, user B is a marketing manager that travels between 30% and 60% of the time.
• the role-based system would determine that roles 1 and 3 apply to user A, and that user A should be provisioned with a pager and access to the sales figures database.
• the role-based system would also determine that roles 2 and 3 apply to user B, and that user B should be provisioned with a cellular telephone and access to the sales figures database.
• a policy-based system according to embodiments of the present invention has defined two policies as follows:
• the policy-based system would determine that roles 1 and 2 apply to user A, and that user A should be provisioned with a pager and access to the sales figures database. The policy-based system would also determine that roles 1 and 2 apply to user B, and that user B should be provisioned with a cellular telephone and access to the sales figures database.
• embodiments of the present invention allow a single policy to be defined than covers multiple attribute values, minimizing the number of policies that need to be defined as compared to the number of roles that would have to be defined in a role-based system.
• policy 1 of the policy-based system replaces roles 1 and 2 of the role-based system. With fewer policies to evaluate, less memory may be consumed.
• the determination of resources can be performed more quickly.
• both LF-THEN statements in roles 1 and 2 must be evaluated before the role-based system can determine that role 1 applies to user A, but role 2 does not.
• the ELSE LF statement in policy 1 can be bypassed.
• the roles and attributes associated with a user may be assigned by human resources personnel or other organizational employees prior to the user's start date.
• the provisioning of a user may be initiated by calling up a provisioning user interface (screen) on a Web browser connected to an organizational network. This screen would enable human resources personnel to input known roles and attributes.
• the RPM system would then search its stored policies and, based on the user's roles and attributes, determine a set of resources to be provisioned.
• human resources personnel may simply type employee information into a human resources (HR) system database, where the RPM system would automatically pull information from this database through a direct feed and begin the provisioning process.
• HR human resources
• a start date or other date and time information may be entered, and the RPM system can initiate provisioning tasks when triggered by this date and time information.
• the actual provisioning of resources may involve electronic communications and human interaction. For example, an e-mail might be sent to various office personnel to deliver a desk and chair to a certain office by a certain date. Another e- mail might be sent to IT personnel to deliver a computer and telephone to the office by a later date, and then enable a computer account, provide access to various applications and databases, e-mail, and voice mail by yet another date.
• the RPM system may send electronic communications over the WAN to the resource agents for such resources, for example, to add an account, delete an account or modify access rights in an account.
• Such communications are made in accordance with suitable WAN protocol, which, in an Internet environment, is preferably HTTPS tunneling. Outside procurement services companies may also be contacted for some or all of the provisioning tasks.
• the provisioning of accounts maintained by an external system such as an ASP may be facilitated by communications between the RPM system and "agent" software that resides in a server within the external system.
• the "agent" acts as a portal through which accounts from the external system may be managed and accessed.
• a list of these existing resources is maintained by the RPM system. Thereafter, if a user's roles or attributes should change, the policies are re-evaluated and a new list of resources to be provisioned are determined. This new list of resources is compared to the list of existing resources, and users are provisioned or de-provisioned according to the differences in the lists. In preferred embodiments, if a particular existing resource is also in the new list of resources, the RPM system will make no change regarding this resource, rather than de-provisioning then provisioning the resource.
• embodiments of the present invention may also suspend the provisioning of resources, rather than de-provisioning them. For example, if a terminated user has threatened to take legal action against the company, the user's e-mail account may be suspended but not deleted, so that the user cannot access the e-mail account, but the e-mails may nevertheless be reviewed by the company in anticipation of litigation.
• a reconciliation process is performed when the RPM system is first invoked. In reconciliation, the RPM system compares a list of currently provisioned resources with a list of resources that should have been provisioned based on the current state of each user's roles and attributes.
• the RPM system may also maintain attributes of resources.
• Resource attributes play a role where the provisioning process allows for a selection of resources. For example, once a user begins working at an organization, the user may be able to call up the provisioning user interface screen to request optional resources. After entering additional information, the user may be able to select optional resources, provided that the user has certain attribute values.
• user A a marketing manager that travels less than 30% of the time, and is not automatically entitled to a cellular telephone
• User A may call up the provisioning screen and inter a value of "Europe" for the attribute "client location.”
• the provisioning screen may then present user A with a selection of cellular telephones to choose from. If user A selects a cellular telephone less than $200, a "cellular telephone cost" attribute having a value "less than $200" will be associated with user A, and the system may automatically provision user A with that telephone by sending an e-mail order to a cellular telephone provider, for example.
• a "cellular telephone cost” attribute having a value "more than $200" will be associated with user A, and approval may be required.
• an e-mail may be sent to a vice-president, providing the vice-president with access to the provisioning screen and requesting that the vice-president input the approval or disapproval of the telephone.
• the RPM will either order the telephone or send a denial message to the user.
• Similar procedures may be implemented for other types of resources, including resources available from remote sites on the WAN.
• An example policy definition covering this example is as follows: Policy No. Definition
• resource attributes include, but are not limited to, color, features, and manufacturer.
• embodiments of the present invention may require input from another person before provisioning can continue.
• human resources personnel may enter known roles and attributes, such as the new employee's department, at which time the policy may halt the inputting of information into the provisioning screen and instead send an e-mail to the department manager, providing the department manager with access to the provisioning screen and requesting that the department manager input a cubicle or office location. Once this information is provided, human resources personnel are notified, and provisioning of that office with a desk, chair, etc. can resume.
• the policy may require that another person provide some of the new employee's roles, attributes, job descriptions, etc. before provisioning can resume.
• e-mail as a means for seeking information or approval from another person, or ordering resources
• other methods of communication such as providing hyperlinks to Web pages and automated ordering of resources over the Internet using online resource provider order sheets may also be employed.
• the provisioning process may be a sequence of steps, some of which require human intervention such as providing information or authorization. An example of this sequence will now be provided. Referring to FIG. 8, a user wishing to be provisioned with one or more resources may access a provisioning user interface screen 700 from a networked computer.
• the provisioning screen 700 may include explanatory text and boxes or fields into which information may be entered. The user may type information into the fields, or may select from a pulldown menu of fixed choices. For example, fields 702 and 704 for a user to enter his first and last name may be provided, and a pulldown menu 706 of available resources may be provided.
• the provisioning screen 700 may also include fields for optional information, fields for required information that the requesting user does not know (and therefore must be provided by another person), fields for required information (such as approvals) that must be provided by another person, and the like. In preferred embodiments, however, the provisioning screen visible to the requesting user will only contain those fields for information that the user is capable of providing. Continuing the example of FIG.
• the RPM processes the provisioning request by sending the provisioning screen to the manager, sending an e-mail to the manager to access a particular hyperlink to view the provisioning screen, or the like.
• the department manager may see a different provisioning screen 708 from the requesting user.
• the provisioning screen 708 may include additional fields 710 and 712 which allows the manager to approve or disapprove the request, and, if approval is given, which department has given the approval.
• the provisioning screen may then be made known to the IT department, who may see a different provisioning screen 714 from the department manager.
• the provisioning screen 714 may include an additional field 716 which allows IT personnel to designate a particular mail server, which may be dependent on the department information, and which may be beyond the department manager's knowledge.
• software for controlling the optional provisioning process may establish which information is to be provided by an individual, and which individuals have approval or disapproval authority, etc.
• the provisioning process may also determine who can modify information, and which information cannot be modified.
• the provisioning process may also define what information must be added before the provisioning request can be sent to the next person.
• the provisioning request may be sent back to the requesting user for additional information or the modification of existing information (i.e. the modification of a resource request).
• the authorizing authority may change depending on what is entered into the request fields. Thus, there is no one process path through which this request form will flow. The process path may actually branch into different directions, depending on what information is entered into the fields of the request form. A generic name for this flow is called workflow process. Therefore, embodiments of the present invention provide a system and method for provisioning users based on policies defined in terms of user roles and attributes, which minimizes the number of unique roles which must be created.
• embodiments of the present invention to provide a system and method for provisioning users based on policies which allow both "soft” and “hard” resources to be provisioned, as well as resources managed from remote WAN sites and resource bundles.
• Embodiments of the present invention also provide a system and method for provisioning users based on policies which can take various process paths that are established as a result of the entry of user parameters, and may require information or authorization to be provided by another person.
• Further embodiments of the present invention allows particular users to add, delete or modify workflow definitions from a remote WAN site, based on the user's role, policies, attributes and organizational information..
• a first organization 800 provisions resources (not shown) using a first server 802 by interfacing with such resources through the first organization's agents 804.
• a second organization 806 provisions resources (also not shown) using a second server 808 by interfacing with such resources through the second organization's agents 810. Note that in this configuration, two logical servers, and possibly even more physical servers, are being utilized by two independent vendors for the same purpose.
• a first organization 800 also provisions resources; however, rather than provisioning resources using a server under its, the first organization 800 may have its resources provisioned by a third party RPM service provider operating a third party server 820.
• the first organization 800 may interface with the third party server 820 through a network 822, such as, for example, the Internet.
• the third party RPM service provider may interface with the first organization's agents 804 through the network 822 to provision resources for the first organization 800.
• the second organization 806 may have its resources provisioned by the third party RPM service provider using the third party server 820 through the network 822.
• the third party RPM service provider may interface with the second organization's agents 810 through the network 822 to provision resources for the second organization 806.
• both organizations 800, 806 utilize a single logical server 820 operated and controlled by the third party RPM service provider.
• both organizations may take advantage of the efficiency of a single logical third party server 820 operated by a third party over a network 822, thereby removing the costs associated with purchasing and operating a server for resource provisioning activities.
• the third party RPM service provider may function as a data center and provide resource provisioning as a managed service to the organizations 800, 806, whereby the organizations 800, 806 may become customers of the third party RPM service provider.
• the managed service may be provided on a subscription basis, whereby any organization desirous of such services may pay a set periodic fee for all of its resource provisioning needs.
• any organization desirous of such services may pay a set periodic fee for all of its resource provisioning needs.
• the policy of a first company to provide its salespersons with an email account and access to its customer database.
• this first company has chosen to outsource its resource provisioning requirements to a trusted third party RPM service provider.
• Both companies would provide the trusted third party RPM service provider with relevant employee information and the nature of the access rights to be granted to the salespersons of the first company and the employees of the second company. Such information could be provided by both companies to the trusted third party RPM service provider over a network such as, for example, the Internet.
• the trusted third party RPM service provider may maintain such information on its server or servers. This would allow the trusted third party RPM service provider to immediately provision a new salesperson or new employee with the required resources. All that would be required to effect such provisioning would be that each company provide the trusted third party RPM service provider with relevant changes to salesperson or employee information. Based on such changes, the trusted third party RPM service provider could create, change or remove accounts or otherwise modify provisioning on required resources.
• FIG. 11 A A flowchart detailing a method for implementing the embodiment of FIG. 10 is shown in FIG. 11 A.
• a request for provisioning services is received by a third party RPM service provider at step 830. Such a request may be made by one or more companies needing such services. The request may be made via electronic means or by personal contact between the appropriate persons at the company and at the third party RPM service provider.
• the third party RPM service provider receives user information from the company making the request. This information may include, but is not limited to, user name, user number, a list of resources to which the user will have access, the nature of the access rights, and the like.
• This information may be sent electronically from the customer to the third party RPM service provider using a network, such as, for example, the Internet.
• the third party RPM service provider will also receive notification that the user is authorized to access the appropriate resources from the customer at step 836.
• This information may also be sent electronically from the customer to the third party RPM service provider using a network, such as, for example, the Internet.
• the third party RPM service provider provisions the relevant resource or resources for the user via agents. It should be noted that many systems may be provisioned at this step to effect the required provisioning. Such provisioning may also take place over a network.
• FIG. 1 IB A flowchart detailing an alternative method for implementing the embodiment of FIG. 10 is shown in FIG. 1 IB.
• a change in user information is received by a third party RPM service provider at step 831.
• the changes may be received via electronic means over a network, such as, for example, the Internet, or by personal contact between the appropriate persons at the company and at the third party RPM service provider and may include, without limitation, changes in user name, user role, user organization, user title, user location, and the like. Also, such changes may be received automatically. For example, a mechanism may be implemented whereby any changes made to a company's human resources database are automatically sent to or retrieved by the third party RPM service provider.
• the third party RPM service provider determines which changes in resource access rights are needed based on the user information changes received. This may be done independently of the company sending changes in user information.
• the third party RPM service provider obtains any approvals necessary for provisioning changes prior to effecting such provisioning.
• the third party RPM service provider provisions, which may include, without limitation, deprovisioning, the relevant resource or resources for the user via agents. It should be noted that many systems may be provisioned at this step to effect the required provisioning. Also, resources may be provisioned in parallel. Such provisioning may also take place over a network. Once the resource or resources have been provisioned for the user, the user is notified accordingly at step 837 and is then at liberty to utilize the resource or resources in accordance with the provisioning policy established by her employer. In the embodiment of the invention shown in FIG.
• the resources being provisioned may all be contained within a customer's "information technology" space. That is, the resources being provisioned may not necessarily exist at the customer's site, but may be within the realm and under the control of the customer. For example, these types of resources may include, but are not limited to, email, operating systems and databases. Such resources may exist worldwide, but, nonetheless, may still be within the control of the customer.
• An enhancement to the embodiment of FIG. 10 is shown in FIG. 12.
• resources 840 external to the first organization 800 and the second organization 806 may be accessed and utilized by both organizations 800, 806 through a network 822 and provisioned for both organizations 800, 806 by a third party RPM service provider using a third party server 820.
• the third party RPM service provider and the organizations 800, 806 may interface with these resources 840 via agents.
• a charge card account such as, for example, an AMERICAN EXPRESS card.
• both companies have also chosen to outsource its provisioning requirements for this resource to a trusted third party RPM service provider.
• Both companies would provide the trusted third party RPM service provider with relevant employee information, such as, for example, the names of employees who have management positions within their respective companies, the employee numbers of such employees, the charging authority granted to each individual employee, and the like.
• Such information may be provided by both companies to the trusted third party RPM service provider over a network such as, for example, the Internet.
• the trusted third party RPM service provider would then establish the appropriate relationship with the charge card company such that the trusted third party RPM service provider would have the requisite authority to establish accounts on behalf of the companies and provision employees of both companies with charge cards for such accounts through agents.
• the provisioning of employees at any of the companies with a charge card account may be immediate. All that is necessary is that a company notify the trusted third party RPM service provider of its provisioning requirement and supply the trusted third party RPM service provider with the necessary employee information.
• the trusted third party RPM service provider can then establish the account with the charge card company and instruct the charge card company to forward one or more charge cards to the employee of the company for whom the account is being established.
• FIG. 13 Another alternative embodiment of the present invention is shown in FIG. 13.
• any number of companies 800, 806 may use a third party RPM service provider for provisioning resources through agents 804, 810.
• These companies 800, 806 may utilize their own resources and have these resources provisioned through a network 822, such as, for example, the Internet, by the third party RPM service provider using a third party server 820.
• these companies 800, 806 may also be considered vendors of their respective resources and may choose to affiliate themselves with one another and share resources.
• the resources owned and operated by each affiliate organization may be "cross-provisioned" among the affiliated organizations by the third party RPM service provider.
• This embodiment of the invention may also be described as a "resource exchange.”
• the infrastructure may be considered semi-private because, although it is not completely private as the enterprise and ASP embodiments described previously are, it is also not completely open to the public.
• the infrastructure, and, consequently, the resources available within the infrastructure may be open only to those vendors of resources who have chosen to affiliate themselves with other vendors utilizing a third party RPM service provider for purposes of having such resources provisioned by such a service provider.
• a first vendor belonging to a resource exchange i.e., belonging to a provisioning infrastructure
• a second vendor in the same resource exchange provides database access to various consumer lists.
• the first vendor determines it has a need for various consumer lists and decides it would like to obtain the database information controlled by the second vendor.
• the second vendor determines it would like to implement an email system for its employees. Then, upon notification by each company to the third party RPM service provider, the third party RPM service provider may cross-provision the first vendor with the database resource belonging to the second vendor.
• the third party RPM service provider may cross-provision the second vendor with the email system provided by the first vendor.
• the third party RPM service provider may mask the identity of the an employee or employees, which may be original or true identities, by provisioning a "pseudo-account" for the second vendor. Because both vendors are members of the resource exchange, most, if not all, of the information required by the third party RPM service provider for cross- provisioning of the resources for each vendor will already be available to the third party RPM service provider.
• both vendors will typically have entered into an agreement regarding the cross-provisioning of resources, such agreement generally being a condition precedent to becoming a member of the resource exchange, the details governing such cross-provisioning will already have been put in place.
• the provisioning of the desired resources may be immediate once the request for provisioning is made.
• FIG. 13 suppose that an organization in a resource exchange contracts with a charge card company providing that every vice- president in the organization be given access to one of the charge card company's charge accounts.
• each vice-president in the organization may immediately and automatically be provisioned by the third party RPM service provider, through the resource exchange, with a charge card company charge accounts.
• RPM service provider the third party RPM service provider
• the third party RPM service provider can coordinate the requirements of both organizations and expeditiously provision the vice-presidents with charge accounts. For example, the organization might have a policy that says vice-presidents get an annual spending limit of $100,000. The charge account might be set, then, to limit annual purchases for vice-presidents to $100,000. Also, the organization might have a policy that says any single purchase by a vice-president cannot be greater than $10,000 without approval from the president.
• the charge account might be set, then, with a single purchase limit for vice-presidents of $10,000. So, once a role and its attributes have been established in the system, it can immediately be adapted to the provisioning of a resource without further effort by the organization. In this embodiment, a user can also be de- provisioned very quickly. For example, assume a vice-president in the organization is terminated or leaves the organization. Although her paychecks may stop immediately, her charge account could typically remain open until the end of the month. This could be very dangerous for the organization in that the vice-president may still have purchasing power on the charge account even though she is no longer affiliated with the organization.
• FIG. 14A A flowchart detailing a method for implementing the embodiment of FIG. 13 is shown in FIG. 14A.
• a request for provisioning services is received by a third party RPM service provider at step 850.
• Such a request may be made by one or more companies needing such services.
• the request may be made via electronic means or by personal contact between the appropriate persons at the company and at the third party RPM service provider.
• the provision request is made for a resource not owned or operated by the company making the request.
• a company might make a request for email provisioning, but, in actuality, the company might not have an email resource. Accordingly, the company would be looking to an affiliate within the resource exchange to provide email services, and would be looking to the third party RPM service provider to provision such services.
• the third party RPM service provider provisions appropriate resources within the resource exchange for the company making the provisioning request.
• the user is notified accordingly at step 856 and is then at liberty to use the resource according to the provisioning policy of the company and in accordance with an agreement between the company requesting the provisioning of the resource and the company providing the resource for provisioning. Typically, such an agreement would be a condition precedent to becoming a member of the exchange.
• a flowchart detailing an alternative method for implementing the embodiment of FIG. 13 is shown in FIG. 14B.
• a change in user information is received by a third party RPM service provider at step 851. Such changes may be received by one or more companies having such changes. The changes may be received via electronic means or by personal contact between the appropriate persons at the company and at the third party RPM service provider. Also, such changes may be received automatically. For example, a mechanism may be implemented whereby any changes made to a company's human resources database are automatically sent to or retrieved by the third party RPM service provider. Also, in this embodiment the changes may be for users who are provisioned for a resource or resources not owned or operated by the company by whom the user is employed.
• the third party RPM service provider determines which changes in resource access rights are needed based on the user information changes received. This may be done independently of the company sending changes in user information.
• the third party RPM service provider obtains any approvals necessary for provisioning changes prior to effecting such provisioning.
• the third party RPM service provider provisions which may include, without limitation, deprovisioning, appropriate resources within the resource exchange for the company providing changes in user information. Provisioning of multiple resources may be done in parallel.
• Billing for cross-provisioning services among affiliates may take a variety of forms. For example, a transaction fee may be applied by a vendor each time a resource is provisioned. Such fee may be payable to the customer requesting provisioning to the vendor of the resource, with a percentage of such fee payable to the third party RPM service provider.
• a subscription may be paid by a customer requesting provisioning to the vendor of a resource such that all provisioning fees are included in the subscription rate.
• This type of billing arrangement may be attractive to a customer with heavy provisioning needs if such needs can be anticipated.
• Various techniques to facilitate the cross-provisioning of resources among affiliates may be included, without limitation, in the embodiment shown in FIG. 13. For example, to facilitate cross-provisioning of resources in a resource exchange, a
• each role within one affiliate organization may translate to a corresponding role in another affiliate organization. This may be made possible by a translational map that translates roles from one affiliate into another.
• a sales engineer in one affiliate may be referred to as a technical sales consultant in another affiliate. Even though these two positions may be identified differently in their respective organizations, the duties required by the positions may be the same in the context of the exchange.
• the third party RPM service provider may maintain a translational map that coordinates the access rights and entitlements of these two positions between affiliate resources. So, a sales engineer in a first affiliate may have the same entitlement to resources as a technical sales consultant in a second affiliate and vice versa.
• the third party RPM service provider may provide a mapping to standard affiliate organizational footprints or standard policies.
• Another technique used to facilitate the cross-provisioning of resources among affiliates in the embodiment shown in FIG. 13 relates to high level authentication of affiliates. Success of an affiliate resource exchange may require that each affiliate be authenticated with respect to various business and financial aspects of such affiliates, including, without limitation, background checks, credit worthiness checks, cash flow checks, and other aspects of an affiliate's business and financial viability.
• Such high level authentication may be performed by the third party RPM service provider and used in addition to an authentication of identity provided by various techniques including, but not limited to, passwords and multifactor approaches such as PKI and biometrics.
• a third party RPM service provider may provide such identity synchronization within the resource exchange. Such synchronization is made possible from a practical standpoint due to the fact that the third party RPM service provider may function as a data center for all affiliate members of the resource exchange. Thus, all information required to update resource exchange information is available on one logical server and updates can, therefore, be made quickly and efficiently. Yet another technique used to facilitate the cross-provisioning of resources among affiliates in the embodiment shown in FIG. 13 relates to audit trails. It may be advantageous for security, accountability and other reasons for each affiliate of the resource exchange to have a record of each cross- provisioning transaction completed for its own resources by the third party RPM service provider.
• each affiliate of the exchange may also have a record of each cross-provisioning transaction completed for its users of another affiliate's resources.
• a third party RPM service provider may provide an audit trail, i.e., a record of each provisioning transaction, for affiliates of the resource exchange. Such an audit trail may be implemented by a third party RPM service provider since, as before, a third party RPM service provider may function as a data center for all affiliate members of the resource exchange. Thus, all information regarding provisioning transactions may be easily recorded and provided to affiliate members at their request.
• Yet another technique used to facilitate the cross-provisioning of resources among affiliates in the embodiment shown in FIG. 13 relates to anonymity of individuals and organizations interacting with resources.
• identities of the affiliates involved in such interaction may be made anonymous during the interaction process. That is, during such interaction, affiliate identities may be masked out so that the interaction process is not skewed by the identity of the affiliates.
• the identities of affiliates bidding on a resource may be masked out, but a user doing the actual bidding may be assigned some type of unique identifier to be used for all bidding sessions.
• the identities of affiliates bidding on a resource may be masked out and a generic identifier used for only one bidding session may be assigned to a user doing the actual bidding; at subsequent bidding sessions, a different generic identifier may be assigned to the same user doing the actual bidding.
• Such anonymity may be facilitated by a third party RPM service provider since a third party RPM service provider functions as a centralized provider of provisioning services for all affiliate members of the resource exchange.
• identities of the affiliates may be masked at the discretion of the affiliates by the third party RPM service provider, such identities remaining anonymous if an affiliate so chooses.
• FIG. 15 Another alternative embodiment of the present invention is shown in FIG. 15.
• any individual organization of the general public 860 may use a third party RPM service provider for provisioning resources, as opposed to vendors providing resources that are provisioned for affiliate use in a resource exchange.
• the third party RPM service provider provides the infrastructure to allow any individual organization of the general public requiring provisioning services to obtain such services, thus providing a public provisioning infrastructure.
• This configuration supports customers without resources to utilize the resources of a resource exchange or other external resources that are part of a public provisioning infrastructure.
• the third party RPM service provider may provide any individual organization of the general public 860, which includes, without limitation, users, organizations and affiliates, with a "ticket” subsequent to the verification of the user's identity.
• the "ticket” may associate the user with entitlement, policies, attributes, roles and rules in connection with the provisioned resources.
• An organization may have, for example, an "organizational footprint" that defines which of the positions in an organization are entitled to various resources and also defines the level of access to and utilization of those resources to which the particular position is entitled. For example, if a person in an organization is a salesperson, the ticket may give the salesperson access to every resource to which the salesperson is entitled based on the rules defined in the organizational footprint.
• Tickets may be authenticated and verified by a trusted third party RPM service provider. Attributes for tickets may vary widely. A ticket may be transferable, it may exist for a specific length of time, or it may have various access rights associated with it. A ticket may exist for one person, several persons, or an entire organization. For example, suppose a law firm has a need to use a resource such as an information database. Assume that the law firm enters into an agreement with the information database resource provider and also enters into an agreement with a trusted third party RPM service provider to provision its employees with access to the database.
• the trusted third party RPM service provider will generate a ticket for such access.
• Each lawyer in the firm would then get a ticket for access to the database in accordance with firm policy.
• the entire firm may receive one ticket for access to the database.
• the ticket may be good for a set period of time and may provide each attorney with certain access rights with respect to the database.
• the law firm may analyze usage and cost associated with the database and modify the access rights on the ticket. Continuing with this example, assume a new attorney joins the law firm.
• a request for provisioning services may be received by a third party RPM service provider at step 870.
• a request may be made by an individual organization in the general public needing such services.
• the request may be made via electronic means or by personal contact between the appropriate persons at the organization and at the third party RPM service provider.
• the third party RPM service provider allocates appropriate space on its server to accommodate the data processing needs of the organization making the service request.
• the third party RPM service provider receives user information from the organization making the request. This information may include, but is not limited to, user name, user number, a list of resources for which the user desires access, the nature of the access rights, and the like.
• This information may be sent electronically from the organization to the third party RPM service provider using a network, such as, for example, the Internet.
• the third party RPM service provider will then provision the user with the requested resources at step 876.
• the user is at liberty to use such resources pursuant to agreements entered into between the third party RPM service provider and the individual organization and the resource provider and the individual organization.
• the embodiment of FIG. 15 may be likened to a hub and spoke configuration, wherein the third party RPM service provider is the hub and groupings of affiliations or individual organizations in the general public exist at the end of each spoke. In this embodiment, all levels of access may be permitted within the confines of the public provisioning infrastructure.
• a non-computing resource such as a charge card account exists within a resource exchange of affiliated companies.
• an individual organization in the general public who is not a member of the resource exchange desires to be provisioned with such charge accounts, it may enter the infrastructure by requesting that a trusted third party RPM service provider generate a ticket for it that provides it with access to the charge accounts in the exchange.
• a graphical diagram showing various levels of embodiments of the present invention is shown in FIG. 17.
• provisioning level 880 various organizations 881 may obtain resource provisioning from a third party RPM resource provider.
• various resource vendors 883 may be part of a resource exchange, sharing resources with other affiliates 883 within the exchange.
• an individual organization 885 may obtain access to resources within the infrastructure, subject to receipt of a provisioning ticket and appropriate identity authentication.
• the embodiments shown in FIGS. 9-17 may be used in connection PKI, i.e., an infrastructure providing identification authentication and certificates.
• PKI i.e., an infrastructure providing identification authentication and certificates.
• the identity, privacy and nonrepudiation of users of embodiments of the present invention which includes, without limitation, companies, organizations, vendors, and affiliates, as well as members of the general public, may be assured. Once an identity is assured by PKI, provisioning of a resource for a user may occur.
• a provisioning infrastructure may be coupled with a PKI such that identity is authenticated and resources are provided based on the identity and the relationship between the identity and the provisioning policy of an organization making a resource available to a user.
• PKIs are well known in the art and will not be described in detail here.
• PKI may be part of the infrastructure utilized by a third party RPM service provider when providing its provisioning services, it may also exist as a provisionable resource within a resource exchange or a public provisioning infrastructure.
• embodiments of the present invention relate to systems and processes for provisioning resources to computer users, where the resources are accessible over a wide area network, such as the Internet.
• resources are provisioned based on pre-defined policies, roles organizational information and attributes.
• a system environment according to an embodiment of the invention is shown in Fig. 19, wherein a resource 910 is connected through or with a resource agent 912 and a firewall 914 to a wide area network (WAN) 916.
• the WAN 916 comprises the Internet.
• the resource 910 may comprise any suitable resource accessible over the WAN 916, including, but not limited to managed resources such as databases, email systems.
• the resource 910 is shown as a database for a managed database service.
• the resource agent 912 comprising software running on a computer for maintaining and administering user accounts for users of resource and operates as described above with respect to resource agent 902 of Fig. 18, to store information relating to authorized users, such as passwords, identification information and access rights information.
• the resource agent 912 controls access to the database to allow authorized users access to the database, but inhibit unauthorized users from accessing the database.
• a resource agent is the enRoleTM product produced by ACCESS360 of Irvine, California, the assignee of the present invention. Similar to the configuration shown in Fig. 18, the resource 910 and resource agent 912 are located at a common network site, referred to below as the first site. In further embodiments, the agent 22 may be located at a different site relative to the resource 910.
• the resource 910 and resource agent 912 are each located at a secure site, where access to the resource may be securely controlled by the agent.
• An RPM system 918 is also connected to the Internet 916, through a firewall 920.
• the RPM system 918 is located at a second network site, which may be remote from the site or sites of the resource 910 and resource agent 912.
• the RPM system 918 may comprise any suitable system for controlling the allocation of resources to a defined group of users.
• the users within the defined group may be users connected to the Internet though other Internet links, such as user's Ul and U2 in Fig. 19.
• the users within the defined group may be users in the same local area network (LAN) 34 with the RPM system 918, such as user's U3, U4 and U5 in Fig. 19.
• the RPM system 918 may be implemented with software, hardware, firmware or combinations thereof.
• the RPM system 918 is implemented with software running on a gateway computer for the LAN 922.
• the RPM system 918 may be implemented on other computers in the LAN 922 or at a different WAN site relative to the LAN.
• the RPM system 918 comprises software, hardware, firmware or combinations thereof for provisioning users with resources based on policies, roles, organizational information and attributes.
• the RPM system 918 employs a platform computer system coupled for communication with a plurality of user computers, administrator computers, external systems, databases and directories, third party service providers, managed services and system administrators and other entities over the LAN 922 and WAN 916, depending upon the needs of the system.
• an organization may provision, or allocate, services to a user within the organization based on defined policies, organizational information, attributes, and the role of the user in the organization.
• the policies, or rules may be pre-defined for the organization based on the needs of the organization and incorporated into the system.
• the policies may be flexible enough to account for the various roles within the organization and the services each role requires. For example, assume an organization hires a new employee in the capacity of System Administrator.
• a pre-set policy for the organization provides that each employee receives regular telephone service, a regular telephone, and an e-mail account
• the RPM system 918 will automatically notify the appropriate parties to set up a regular telephone account and an e-mail account for the System Administrator and deliver a regular telephone to the System Administrator's office.
• a pre-set policy for the organization is that each System Administrator has access to all system databases.
• the RPM system 918 will then automatically grant the System Administrator access to all system databases.
• the same organization hires a new employee in the capacity of Outside Salesperson.
• the RPM system 918 automatically notifies the appropriate parties to set up a regular telephone account and an e-mail account for the Outside Salesperson and deliver a regular telephone to the Outside Salesperson's office.
• the RPM system 918 automatically denies access to these databases by the Outside Salesperson.
• the RPM system 918 handles these actions automatically based on the role of the person within the organization and policies that are pre-defined for the organization.
• the policies may be based on the needs of the organization and the requirements of each particular role within the organization, such that resources may be provisioned to each user to meet the needs and the requirements of the user's particular role in the organization.
• resources that are provisioned by the RPM system 918 include resources accessible over the Internet 916.
• the RPM system 918 includes or employs at least one processor programmed to communicate with the resource agent 912 over the Internet and through the firewalls 26 and 32, to provide account administration.
• account administration functions preferably include adding a user account, deleting a user account and modifying information regarding a user account.
• the RPM system 918 will automatically communicate with the resource agent 912 to add a new account for the new System Administrator.
• the RPM system 918 will automatically communicate with the resource agent to cancel that System Administrator's account.
• the RPM may also communicate other information relating to user accounts, for example, to modify access rights for an employee who's role has changed within the organization. In this manner, a user's access rights may be modified to increase or decrease access rights, based on the user's needs within the user's new role. Because the RPM system 918 and the resource agent 912 are located at different sites on the WAN 916, communications between these entities must be compatible with WAN protocol and must be able to pass firewalls 904 and 920.
• the RPM system 918 employs a suitable protocol for Internet communications, preferably HyperText Transfer Protocol (HTTP) and, more preferably a secure HTTP connection, such as HTTPS. Any suitable format, such as XML may be employed.
• HTTPS HyperText Transfer Protocol
• Any suitable format, such as XML may be employed.
• a suitable WAN protocol such as HTTPS
• HTTPS HyperText Transfer Protocol
• ESP encrypted socket protocol
• the ability to provision remote resources can significantly increase the flexibility and utility of the RPM system 918.
• the RPM system 918 With that capability, not only can the RPM system 918 provision resources that are local to the RPM (e.g., located in the same LAN as the RPM), but resources located virtually anywhere in the world and accessible over the Internet may be provisioned. While the illustrated embodiment shows only one resource 910 and resource agent 912 accessible over the WAN 916, preferred embodiments operate with a plurality of resources and resource agents.
• the RPM system 918 communicates with each resource agent of each resource to provide account administration functions as described above with respect to resource 910 and resource agent 912.
• the RPM system 918 operates with workflow definitions. Such workflow definitions may be added, deleted or modified by a user having a specialized role, for example, supervisor.
• the workflow definitions may be added, deleted or modified from a location remote from the RPM SYSTEM 918, such as a remote site on the WAN 916. More specifically, with reference to Fig. 20, the RPM system 918 includes a workflow engine 930 which operates with a database or storage 932 of workflow definitions WDFl-WDFn. Using a role-based system as described above, the RPM system 918 provisions resources, such as access rights, to users Ul, U2, U3, U4 and U5, based on predefined policies, user roles, organizational information and attributes. In addition, the RPM system 918 provides a user U6 having a specialized role, with access rights which allow that user to access, add, delete, or modify workflow definitions within the workflow database.
• resources such as access rights
• the user U6 is located at a site on the WAN 916 which is remote from the WAN site at which the RPM system 918 is located.
• the remote site is provided with a computer with suitable software, such as browser software, for communicating over the WAN 916 with a web server 934 in the RPM system 918.
• suitable software such as browser software
• the user U6 may log into the RPM system 918 from the user's computer.
• the user U6 may be located anywhere that has an Internet connection and, thus, need not be located at a computer local to the RPM system 918.
• the RPM system 918 operates with a plurality of workflow definitions and the user U6 has a role which, under the role-based provisioning rules of the RPM system 918, allows the user U6 to add, delete or modify one or more pre-determined workflow definitions, but not all of the workflow definitions within the database 38.
• another user U7 has a specialized role which, under the role-based provisioning rules of RPM system 918, allows the user U7 to add, delete or modify one or more pre-determined definitions.
• the pre-determined workflow definitions which user U7 may access may or may not include some or all of the workflow definitions that U6 may access.
• the user U6 may have a supervisory role that allows access to add, delete or modify workflow definition WDFl, while the user U7 may have a broader supervisory role that allows access to add, delete or modify any of the workflow definitions WDFl-WDFn.
• the user U7 may have a role which allows access to add, delete or modify workflow definitions WDF2- WDFn.
• any suitable number of users may be provided with access rights to add, delete or modify predefined groups of workflow definitions.
• Resource usage in an RPM system may be excessive, moderate or minimal.
• a dormant resource may be any resource, or any account on that resource, that has not been utilized for a given period of time under circumstances defined by the rules or policies that have been established for that resource and for users of that resource.
• various rules and attributes may be associated with each user in the system. According to embodiments of the present invention, when establishing a usage policy, these rules and attributes may be used in conjunction with a particular resource such that an RPM system may determine when a resource or an account on that resource is considered dormant, or when usage of that resource is excessive, and what activity should be taken as a consequence thereof.
• an RPM system may take action based on rules that define when a resource, or an account on that resource, is dormant or is being used excessively, based on the activity of the resource or account and the various rules and policies that have been established for that particular resource or account.
• a generalized embodiment of the present invention is shown in FIG. 21.
• a resource usage policy is defined at step 940. This policy is implemented in the RPM system and controls action taken in response to resource usage within the system.
• the system provisions users on the system with resources according to various data and user attributes and in accordance with company policy. Users then have the ability to use resources on the system. Usage of the resources on the system is then monitored by the system at step 944.
• Step 946 Data related to system users or resource usage may be input into the system at step 946.
• step 948 usage and external data that has been monitored or input is sent to the RPM system where it is analyzed according to the usage policy.
• the system may determine that a change in provisioning of the resource is required at step 950.
• a user is re-provisioned with the resource at step 942. This may include, but is not limited to, giving the user enhanced rights to the resource or eliminating the user's rights to the resource.
• the nature of the resource usage and user attributes may trigger a change in the usage policy.
• the policy may be re-defined at step 940, and the system may continue thereafter in a like fashion.
• a system administrator who has an account on a system residing on a local area network, has not logged on to the system in six months.
• that account may be considered dormant.
• appropriate action may be taken for that account.
• This action may be based on the rules and policies that have been established for the system and for the system administrator's particular account, and may include a wide range of actions, such as, without limitation, taking no action at all or disabling the account.
• FIG. 22 A flowchart detailing another example of resource usage management is shown in FIG. 22. Assume a company salesperson has not used her cellular telephone in three months. Also, assume that, because a salesperson would typically use a cellular telephone regularly, possibly even daily, the company might institute a policy that renders cell phone resources dormant if a cellular telephone account is held by a salesperson and has not been used in more than one month. At step 960, the system retrieves cell phone usage data regarding this salesperson from the relevant cellular telephone resource.
• the system would query the appropriate agent, which in turn retrieves the data from the resource or its own internal storage mechanism and responds with the data to the system.
• the policy may be, in this particular circumstance, to notify the salesperson's supervisor so that an investigation regarding the reasons for the inactivity of the cellular telephone account may be determined.
• the company may disable the cellular telephone account altogether or take appropriate action falling somewhere in between these alternatives.
• FIG. 23 A system according to an embodiment of the present invention by which an RPM system may reconcile dormant resources is shown in FIG. 23.
• an RPM system 970 interfaces with a managed resource 974 via an agent 972.
• the agent 972 maintains information regarding utilization of the resource 974.
• the agent 972 may maintain such information in a variety of ways, such as, for example, by logging each access to the resource 974 in a table.
• the resource 974 is sophisticated enough, such activity information may be stored in the resource 974.
• the agent 972 may simply extract usage information from the resource 974. This may be the case if the resource 974 is, for example, an operating system, which typically will track the amount of usage for each account on the system.
• FIG. 23 A system according to an embodiment of the present invention by which an RPM system may reconcile dormant resources.
• the RPM system 970 may query the agent 972.
• the agent 972 will respond to the RPM system 970 by delivering to it the requested utilization information.
• the RPM system 970 may request information from the agent 972 at various times, and the frequency with which the RPM system 970 makes a request to the agent 972 for information may be modified by the RPM system administrator. For example, assume an engineer of a company has an account on the company network using a networking operating system.
• the operating system may maintain information relating to the engineer, including, but not limited to, an associated user i.d., the department within the company to which the engineer belongs, and the work group within the department to which the engineer belongs.
• the operating system may also maintain a log detailing each time the engineer utilizes the operating system and for how long the engineer utilizes the operating system.
• the agent from time to time or when directed, may query the operating system for such information and store the information in a table, database, or other storage element so that the information is readily available to the RPM system. When the RPM system queries the agent to determine whether a resource is dormant, the agent may present to the RPM system the requested information.
• the following is an example of pseudo-code to implement a situation similar to the preceding example:
• Embodiments of a usage policy may be designed such that the RPM system overall has tremendous flexibility. Policies may differ between types of users as well as between types of accounts. Also, a period of dormancy may be defined differently from account to account.
• a cellular telephone agent is the interface between a cellular telephone resource, which may be, for example, a cellular telephone service provider, and an RPM system.
• the agent may periodically retrieve billing information from the cellular telephone resource, which may include, for example, cellular telephone usage time.
• the RPM system which periodically reconciles all cellular telephone accounts in its system, may request usage information from the agent. By using the requested information and reconciling that information with the policy that has been established for the cellular telephone resource and the users of the cellular telephone resource, the RPM system may determine whether a particular cellular telephone account has become dormant and what action to take in such case.
• a policy for the preceding example may be implemented as shown in the following example pseudo-code:
• the RPM system would direct appropriate personal to cancel the account and notify the user of such cancellation.
• One method by which to determine whether cell phone usage is related to sales of the company products would be to enter a sales call code prior to making an actual sales call.
• tremendous flexibility can be designed into the system, allowing company management to tailor policies to each particular resource based on a variety of parameters. For example, assume a vice- president of sales and marketing is out on maternity leave but remains in contact with her staff via her cellular telephone.
• the vice-president may not access the networking operating system used by the company for six weeks; however, she may remain in contact with company personnel during her maternity leave, but may go for periods as long as two weeks without accessing her cellular telephone account.
• the company considers any account on the networking operating system to be dormant if it has not been accessed in two weeks unless special circumstances apply, such as an account holder being out on maternity leave.
• the company considers cellular telephone accounts to be dormant if those accounts are not accessed for one week unless the account holder is a company executive, such as a vice-president.
• pseudo-code representing policy instituted by the company regarding dormant resources may be as follows: IF ((last_access_operating_system > two weeks)
• policies may be designed such that the overall RPM system provides a very rich environment in which to establish rules based on a company's philosophy regarding how a resource should be managed by virtue of the fact that the system may ascertain when a resource or an account on a resource was last accessed and by virtue of the fact that various attributes exist for each account. This allows system behavior to reflect company policy. Further, the system can be easily modified.
• a company or organization may monitor its system and fine tune it until the system is operating in a manner acceptable to the company.
• resource usage policies in an RPM system allow companies and organizations to recognize usage and access patterns of their managed resources. For example, in addition to monitoring usage and access of an individual cellular telephone account, all cellular telephone accounts within a company or organization may be monitored. Thus, overall usage and access patterns may be detected and resource usage policies may be implemented in accordance with such patterns. For example, suppose that all cell phone usage within a company or organization drops dramatically during the period between Christmas and New Year's Day every year. Using this information, a company or organization may reflect this information in a usage policy in its RPM system and modify typical responses to such usage accordingly.
• This particular policy may be extended to other periods of time and other usage and access patterns.
• a company or other organization that takes action on a dormant account may observe a response from the user community generated by these actions.
• a company or other organization may easily ascertain whether such action was. an overreaction or an underreaction based on feedback received from the users of the dormant resources.
• policy may be quickly modified if the company or organization feels that a modification is warranted based on user response to the action taken.
• a company or other organization may take action on an account based on average use of the account.
• a company institutes a cell phone usage policy that requires all cell phone users to use their cell phone accounts for at least one hour on average each day over a prescribed period of time, such as thirty days, as opposed to a policy that requires only general account use within a prescribed period of time, such as thirty days.
• a prescribed period of time such as thirty days
• an account user were to not use his cell phone for a significant portion of the month, for example, twenty-five days, then, at the end of the month, unless the cell phone user could log enough hours during the last days of the month so that the average usage equates to one hour each day, the account may be considered in violation of the policy and appropriate action may be taken.
• Such a policy may prevent negligence or laziness by company employees.
• a usage policy may be instituted such that too much usage on an account is monitored.
• a usage policy may require that no cell phone account be used, on average, more than eight hours each day.
• the company instituting the policy may take appropriate action on the account.
• a usage policy may be instituted in an RPM system that monitors a type of usage.
• a usage policy may be instituted that monitors all access to a database and determines what type of database access occurs on each account. If, for example, the system determines that a particular account always reads from the database and never writes to the database, the system, according to the usage policy instituted for the database, may give that account read-only access to the database. Should the account holder require write access to the database after the account has been rendered read-only, the account holder may have to notify management and the system administrator to re-establish write access to the database.
• a usage policy may be instituted such that usage of user accounts is tolled under certain circumstances. For example, if a particular account user were to take a vacation, account access for this user would drop to zero.
• a usage policy may be instituted that allows account users to notify the system of periods of known non-use on accounts. The system may then toll usage activity for such periods. Such notification may be coordinated with company scheduling services and calendering programs, thereby incorporating account usage into company schedules.
• usage policies may be extended to any managed resource. For example, usage policies may be applied to credit card accounts, standard telephones, databases, and virtually any resource used by a company or organization that may be managed and provisioned. The advantages of having a usage policy in an RPM system should now be apparent. A usage policy in an RPM system may provide flexibility, security and cost savings.
• Flexibility may be achieved in the varying policies that may be implemented using various attributes of account holders and resource users along with company philosophies regarding when an account on a resource should remain open.
• seventy percent of all cellular telephones owned and operated by the company are used by company salespersons every day.
• daily cellular telephone usage drops to twenty percent.
• the company may generally consider a cellular telephone to be dormant if its average daily usage drops below seventy percent
• a company may consider a cellular telephone to be dormant if its average daily usage drops below twenty percent.
• action that would normally be taken in response to such low cellular telephone usage may be avoided during times of low usage, as reflected in the usage policy.
• This type of policy may be implemented at the discretion of the company or organization utilizing the resource, and may be made as strict or as liberal as desired. Cost savings may be realized by eliminating accounts that are not being accessed. Generally, a company or organization would not want to incur the costs associated with maintaining an account if that account is not being used. In a usage policy, an unused account may be eliminated when a company or organization feels it is most cost effective to do so. Security may also be heightened by allowing a company or organization to eliminate open, and therefore vulnerable, accounts in a timely and effective manner.
• an RPM system may include an identity policy.
• An identity policy in an RPM system provides rules that allow the system to uniquely identify each user within the system.
• An identity policy according to an embodiment of the present invention may include rules that determine how users in an RPM system are identified within the system and within each resource managed by the system.
• An identity policy may also determine how users in multiple managed resources are identified within and across the multiple resources. On any particular resource, an identity must be unique so that a user of that resource may be uniquely identified and not confused with other users of the same resource.
• An identity policy may provide rules for creating an identity for a user of a system resource from the user's attributes, including, but not limited to, the user's name and the user's role within an organization, and, further, may provide the capability to utilize different combinations of attributes to formulate a unique identity.
• an identity policy according to an embodiment of the present invention may also be flexible enough to combine a user's attributes in such a way that a reasonable user identity may be generated for a particular user in the event some of that user's attributes conflict with another user of the resource.
• an identity policy according to an embodiment of the present invention will not only take into consideration attributes of the user for whom the identity is being generated, but also attributes of other users of the resource.
• a user identity for a resource may be generated according to an embodiment of an identity policy as shown in FIG. 24.
• a resource user's attributes are obtained by an RPM system. These attributes may be obtained in a variety of ways. For example, assume a new employee in an organization has completed an employment application.
• the completed employment application will generally contain a variety of user attributes, including, without limitation, the employee's full name, home address, telephone number, social security number, and the like. These attributes may be used by the RPM system when establishing an identity for this employee on system resources. Furthermore, the role within the organization for which the employee was hired may also be a source of user attributes. For example, the employee may be a part of an engineering organization, working within a test and measurement group, and may be employed in the position of technician. All of these attributes may also be obtained by the RPM system. The user's attributes may be entered into the RPM system by a data entry clerk or other person.
• the RPM system generates an identity for the user for a particular resource to be utilized by the user and according to an established identity policy.
• An identity policy may be formulated according to the desires of the organization using it, and may include the identity rules of the resource for which a user identity is being generated. For example, assume an identity policy for a LAN assigns user identities using the first initial of the LAN user's first name followed by the LAN user's last name.
• the user identity as determined by the identity policy would be "jwilliams.”
• identity a check is made at step 984 to determine whether the generated identity creates a conflict, i.e., whether another user of the resource in question has already been assigned the generated identity. If the generated identity has not been previously assigned, the generated identity is then assigned to the user at step 986. If, however, the generated identity has been previously assigned, the RPM system returns to step B to determine a new identity in accordance with the identity policy.
• the identity policy for the LAN described above assigns user identities using the first initial of the LAN user's first name followed by the LAN user's middle initial and last name in the event that an identity formed from the LAN user's first initial and last name is already taken. Then, if the LAN user's full name were John Mark Williams, the user identity as determined by the identity policy would be "jmwilliams" in the event "jwilliams" had already been assigned.
• Sample pseudo-code for the examples described above in reference to FIG. 24 is shown below:
• a random number may be appended to the end of an already-assigned USERID (e.g., jwilliams3579), or the number appended to the end of an already-assigned USERID may be incremented by one (e.g., if jwilliams 1 is already assigned, try jwilliams2).
• FIG. 25 A method of assigning user identities across multiple resources using an identity policy according to an embodiment of the present invention is shown in FIG. 25.
• a resource user's attributes are obtained by an RPM system.
• the RPM system generates an identity for the user for a particular resource to be utilized by the user and according to an established identity policy, which may include the identity rules of the resource for which a user identity is being generated, as was done in relation to FIG. 24.
• an established identity policy which may include the identity rules of the resource for which a user identity is being generated, as was done in relation to FIG. 24.
• a check is made at step 994 to determine whether the generated identity creates a conflict. If the generated identity has not been previously assigned, the generated identity is then assigned to the user at step 996. If, however, the generated identity has been previously assigned, the RPM system returns to step B to determine a new identity in accordance with the identity policy.
• the RPM system determines whether additional resources will be utilized by the user.
• identity generation may stop at step 1000. If the user will be utilizing additional resources, an identity is generated for those resources at step 992 according to the identity policy, which may include identity rules of each additional resource for which a user identity is being generated, and the process continues.
• the identity policy may include identity rules of each additional resource for which a user identity is being generated, and the process continues.
• Each resource may have its own requirements for user identities and thus the RPM system identity policy may take these requirements into consideration.
• an identity would be generated for each resource. If both the LAN and the company database allow user identities to contain alphanumeric characters, it may be possible to assign the same identity for the user to both resources.
• an identity policy for an RPM system attempts to assign user identities by using the last name of a user followed by the first initial of the user's first name.
• the user identity assigned for each of these resources may be, absent a conflict, "williamsj.”
• some resource identity requirements may make it impossible to assign the same user identity to all resources being manage by the RPM system.
• an identity policy may be written to generate a single identity for resources with compatible resource identity requirements.
• a user identity may be generated and checked for uniqueness against all of the compatible resources until an identity is found that is unique for all of the compatible resources.
• FIG. 26 A flowchart for such an identity policy is shown in FIG. 26. An identity policy in an RPM system would obtain a list of resources to be provisioned to a user at step 1010.
• the identity policy would also obtain attributes of the user for whom resources are being provisioned.
• the RPM system generates a user identity to the user for all resources in the list. The identity is based on the user attributes and is a first attempt to generate an identity compatible with all the identity requirements of the resources on the list. Once a first attempt has been made in generating and assigning an identity to the user, the system checks the identity at step 1016 to determine whether the identity has been previously assigned in any of the resources on the list. If the identity has been previously assigned, another identity is generated for the user at step 1018 and is subsequently checked again for uniqueness at step 1016. If the identity is unique, the process may end at step 1020 and the identity may be assigned to the user.
• FIG. 27 A system of assigning user identities using an identity policy according to an embodiment of the present invention is shown in FIG. 27.
• An RPM system 1030 maintains records 1032 of all accounts on the system, including, without limitation, personal information regarding the various users on the system as well as a list of all resources utilized by the users and the associated identities of the users on each particular resource.
• the identity 1034 is sent to the resource 1036 through an agent 1038 when the resource 1036 is provisioned for the user.
• the user may have an identity particular to the RPM system itself, which may or may not be identical to identities assigned to the various resources utilized by the user.
• the identity of a user particular to the RPM system itself may contain whatever information deemed necessary by the system operators to identity the user and associate the user with all resources utilized by the user. For example, in small organizations, it may be sufficient to implement an identity policy that identifies a user on the RPM system by the user's first initial followed by the user's last name. Thus, for a user named "John Williams," the user's identity on the RPM system would be "jwilliams.” However, this simple identity policy may be insufficient for larger organizations. For larger organizations, an identity policy may identify users on the RPM system by first initial, last name, company organization, and position within the company.
• a user on the RPM system named "John Williams" who works within an engineering organization as a technician may have an identity on the RPM system such as "jwilliams, engineering, technician.” It may be of no consequence to an RPM system that a user has accessed a particular resource. However, at some point previous to a user's access to a resource, all relevant user information related to that resource may either be entered into or stored in the RPM system, including, but not limited to, the user's identity on that resource and, if applicable, the user's password for that resource.
• the resource may be cognizant of nothing about the user except that the user has an account on the resource and has, associated with that account, certain relevant information, such as, for example, an identity and a password.
• the RPM system may know detailed information about the user, including, without limitation, the resources being utilized by the user as well as the identities of the user on those resources.
• a user of a single resource may have multiple accounts on that resource. For example, assume that a system administrator for a LAN utilizes a resource on two levels, one being personal, the other being administrative. Because the accounts are used for different purposes, from an administrative perspective it may be desirable that the system administrator access the LAN using two different identities. Thus, if the system administrators name is "John Williams," his personal identity on the LAN may be "jwilliams" while his administrative identity may be "jwilliams_admin,” depending on the identity policy implemented by the company employing the system administrator. Sample pseudo-code for a portion of this example follows.
• identities may be established without user interaction. Once attributes of a resource user have been obtained by an RPM system, an identity may be generated according to the identity policy, without further information from the user. Thus, identities may be generated, for example, for an employee even before the employee begins working with an organization if enough attributes for the employee have been entered into an RPM system. According to further embodiments of the present invention, an identity policy may be designed to be flexible enough to adapt to collisions in identity. Using an identity policy, an RPM system may generated alternative identities in the event of a conflict without querying the user and engaging the user in an interactive and iterative process. Once the user's attributes are obtained, the identity generating process may be automated.
• user identities may be tailored to the particular user an a variety of levels. For example, assume that an organization would like user identities on the resources used by the organization to reflect the nature of the user's position within the organization. Thus, for an engineer in an organization whose name is "John Williams,” an identity policy in an RPM system may generate as his identity “jwilliams eng.” Likewise, for a secretary in an organization whose name is "Mary Smith,” an identity policy in an RPM system may generate as her identity “msmith_sec.” According to further embodiments of the present invention, an identity policy within an RPM system may generate user identities in a variety of areas. For example, an identity policy may generate an identity for a digital certificate, a digital key, laboratory equipment, office hardware, or a credit card account.
• an RPM system may include one or more password policies.
• a password policy in an RPM system according to an embodiment of the present invention may restrict certain passwords from being utilized by users on the system.
• a password policy according to embodiments of the present invention may also require users to formulate passwords that are acceptable to each resource in the system and that comply with company or organizational policy on passwords generally.
• a password policy according to embodiments of the present invention may also combine password rules for each resource within the system into a unified policy applied across all resources within the system.
• a password policy according to embodiments of the present invention may recognize conflicts in password syntax in such embodiments.
• a password policy according to embodiments of the present invention may also eliminate rule sets that provide minimal protection from hackers, thereby rendering the overall system vulnerable to breaches of security.
• a password policy may provide for the automatic generation of passwords that are in compliance with such policy.
• a password may be formulated in accordance with embodiments of the present invention as shown in FIG. 28.
• a user of a resource in an RPM system inputs a desired password.
• This password may be any password chosen by the user so long as it conforms to the password policy implemented in the RPM system.
• the user will be cognizant of such policy and choose a password accordingly. However, this may not always be the case, and the user may input a password that does not comply with the password policy of the system.
• a step 1042 a check is made to determine whether the password chosen and input by the user complies with the password policy implemented in the system.
• the system accepts the password at step 1044. However, if the password is not in compliance with the system password policy, a new password must be entered again at step 1040 and the process is repeated until a password that complies with the system's password policy is entered by the user.
• the system may notify the user of such rules. For example, if one of the rules of the password policy for a particular resource were that all passwords must be at least six characters in length and a user attempted to enter a password only four characters in length, the system may respond with the following notification: "A password must be at least six characters in length.
• the user will know the password policy's rule for password length and, hopefully, formulate a password in compliance with this rule.
• a list of password policy rules may be given to the user prior to the user entering a password for the first time.
• the password entered by the user may already be in compliance with the password policy without further notification to the user by the system.
• the system may automatically generate a password allowing the employee to enter the system as shown in FIG. 29.
• the system may generate a password for the employee following the rules set forth in the password policy.
• the rule for generating passwords for employees who have not yet entered the system may be that the password will consist of the first initial of the employees first name, followed by a period, followed by the employees last name.
• the system's password policy may also impose the restriction that all passwords must be at least six characters in length, including special characters such as a period, but not greater than ten characters in length.
• the system may automatically generate the password "j.williams" for use by the employee when entering the system for the first time.
• this password is in compliance with the rules set forth immediately above for passwords in the RPM system of this example.
• the system's password policy may implement another rule, for example, that truncates the employee's last name in the event the auto-generated password exceeds ten characters in length.
• the system would automatically generate the password "j.stevenso" for use by the new employee when entering the system for the first time.
• an additional rule in the password policy may be that if the auto-generated password is less than six characters, the employee's first name, rather than the employee's first initial, shall form the first part of the password.
• the password "john.lee” would automatically be generated by the system. This password is in compliance with the password policy.
• Additional rules may be included in the password policy to accommodate various situations which arise in the auto-generation of passwords.
• the password is given to the employee for whom it is intended at step 1052. This may be done in a variety of ways. Typically, the password is given verbally to the employee by the system administrator. Once the employee has the auto-generated password and is ready to enter the system, the employee may enter the auto-generated password into the system and access the system at step 1054. Some systems do not require that users change their passwords from the auto-generated password supplied to them by the system and, in such systems, some users may continue to use as their password the same auto-generated password that was initially supplied to them by the system.
• step 1056 the password that has been chosen by the employee is checked by the system to determine whether the employee's chosen password is in compliance with the password policy implemented in the system. If the chosen password is in compliance with the password policy, the password is accepted at step 1060.
• a different password must be entered at step 826 and the process repeats until the employee enters a password that complies with the system's password policy.
• the embodiment of the present invention referred to in FIG. 29 may be modified in a variety of ways. For example, it would not be uncommon for employees using system resources to occasionally forget their passwords. In this event, a system administrator may be notified by an employee who can no longer remember his or her password. In some embodiments, a system administrator or other person may ask the employee some qualifying question to verify the authenticity of the employee in an effort to maintain security.
• the system administrator may ask the employee to recite her social security number or some other question in order to verify the identity of the employee. If the employee responds to the qualifying question properly, the system administrator may instruct the system to auto-generate a password for the user as shown at step 1050 in FIG. 29. Next, the password may be given to the user at step 1052. Because the employee may already have accounts in use on the system, the system may email the password to the employee if that option is available. The user would then enter the password to get into the system and the process in FIG. 29 would continue as before.
• a password policy according to embodiments of the present invention may allow companies or organizations implementing such policies to place various restrictions on passwords chosen by users of the system. For example, as has been discussed previously, passwords may be restricted in length.
• a password policy may impose a rule that all passwords in the system be at least six characters, or at least six characters but not greater than ten characters.
• a password policy may impose the requirement that all passwords in the system contain at least one special character, such as a punctuation mark or other non- alphanumeric character.
• Many other embodiments for restricting passwords in a password policy are possible. For example, a password policy according to embodiments of the present invention may require that certain characters not be used.
• a password policy may require that certain characters must be used.
• a password policy may require that all passwords contain a period ".” in order to be valid as a password.
• limitations may be placed on repeated characters. For example, a rule in a password policy may require that a character be repeated no more than twice.
• FIG. 30 shows a basic layout of three rows of keys on a computer keyboard 1070.
• This sequence corresponds to the home keys 1072 of the keyboard when typed from left to right and is frequently used by system resource users as an easy and quick way to enter a password into the system.
• Such passwords because they are easy and quick, are easily discovered by hackers and, consequently, compromise system security.
• a password policy may restrict such sequences from being used as passwords.
• Sample pseudo-code implementing such a restriction, as well as other restrictions related to keyboard sequences, may be as follows.
• the first line in the above pseudo-code restricts a password from being the sequence of home keys on a computer keyboard as typed from left to right.
• the second line restricts a password from being the sequence of alternately typed home keys, starting with the "j" key.
• the third line restricts a password from being the sequence of quasi- horizontally typed keys, starting with the "z” key and returning to the "x" key after the last key in the quasi-horizontal row, "1," is entered.
• Many other keyboard sequences are possible, and a password policy may restrict against any sequence desired. For example, a password policy may restrict a sequence of any five keys in a row.
• a password policy may restrict passwords that contain, for example, personal information.
• embodiments of a password policy may prohibit use of a user's first or last name in a password.
• embodiments of a password policy may also prohibit use of a user's first or last name reversed in a password.
• a password policy may prohibit using "nhoj" as a password or part of a password.
• a password policy may also restrict password reuse on a resource.
• Further embodiments of the present invention may restrict password reuse on all resources managed by the RPM system. For example, an RPM system may require that all users on the system change their passwords periodically, say, every six months. Assume a user in an RPM system has an account on a networking operating system and an account on a company database. If the networking operating system and the database were to have rules regarding passwords that were incompatible with one another, a user of both resources would have separate passwords for each resource.
• a user may use the password previously used for the networking operating system as a new password for the database and vice-versa. This makes password selection easy for the user but is typically poor policy overall for the system in that the passwords, in essence, haven't changed — they have merely been reassigned. Such reassignment makes it easier for hackers to enter the system, thereby compromising system security.
• a password policy according to an embodiment of the present invention may restrict reuse of this type such that a password used for one resource in the system may not be used for the same or another resource at a later date.
• a password policy may include rules regarding international characters and special characters.
• Any character for example, any Chinese character or the like may be included in the rules of a password policy.
• special characters or international characters may be defined by the organization implementing a password policy.
• a special character is any character that is not included in a standard ASCII character set.
• special characters may be any character so designated by the company or organization implementing a password policy, rather than any character that is not included in a standard character set as used in the United States.
• password policies according to embodiments of the present invention may be implemented internationally. Any character that may be entered into the system may be designated as a special or non-special character. For example, if a particular Chinese glyph is considered by a company as a special character, it may be so designated.
• a system may implement embodiments of a password policy that provide different rules for different countries.
• a password policy may, for example, implement one set of special characters for the United States and another set of special characters for China or another foreign country.
• a password policy may, for example, implement one set of rules for the United States and another set of rules for China or another foreign country.
• password rules sets particular to various resources may be combined into one password policy in an RPM system as shown in FIG. 31.
• a first resource 1080 such as, for example, a networking operating system, may include a first set of rules 1084 that place restrictions on passwords for access into the first resource 1080.
• a second resource 1082 such as, for example, a database, may have a second set of rules 1086 that place restrictions on passwords for access into the second resource 1082.
• the first set of rules 1084 and the second set of rules 1086 may be combined into a third set of rules 1088 that form a password policy 1090 implemented in an RPM system.
• Any number of rules sets particular to any number of resources may be combined into a password policy.
• a password policy may be a combination of rules for passwords established by a plurality of resources.
• a company or an organization implementing a password policy may implement a password policy that is more restrictive than the mere combination of rules for various resources. Indeed, some resources may have no rules or restrictions regarding passwords. Referring again to FIG.
• the company or organization implementing the password policy 1090 may feel that the rules required for the first resource 1080 and the second resource 1082 do not place enough restriction on the types of passwords users may have.
• the password policy 1090 may implement additional rules and restrictions that are not required by either the first resource 1080 and the second resource 1082 resource. For example, assume that the company or organization implementing the password policy 1090 wants to require that each password contain at least two special characters.
• a password policy 1090 may require that, in addition to all passwords being at least six characters in length and less than or equal to ten characters in length, two of those characters must be special characters, such as, for example, the following: !, @, #, $, %, ⁇ , &, * or the like.
• special characters are possible and a company or organization may define any character to be a special character.
• the previous characters may be special characters, or a company or organization may define punctuation marks or international characters to be special characters.
• Sample pseudo-code implementing this policy would be as follows.
• a password policy implemented in an RPM system may also detect conflicts in syntax between resources on the system.
• the first resource 1080 and the second resource 1082 allowed any alphanumeric character to be included as part of the password policy.
• a third resource (not shown), such as, for example, a PBX, required that all passwords by numeric only. It would, therefore, be impossible to formulate a password satisfying the first resource 1080 and the second resource 1082 as well as the third resource.
• the password policy 1090 would generate two passwords for users who utilize the first resource 1080 and the second resource 1082 as well as the third resource.
• a password policy according to an embodiment of the present invention may provide for passwords that may be utilized across all resources in a system
• a password policy according to an embodiment of the present invention may also implement rules providing for the fewest number of passwords possible given conflicts between password rules of various resources on a system.
• rules sets of the password policy may become overly restrictive.
• a password policy may be implemented in an RPM system such that it automatically detects such overly restrictive password rules sets, sometimes referred to as "weak" password rule sets. For example, referring again to FIG. 31, assume the first resource 1080 requires that all passwords be at least six characters in length.
• the second resource 1082 requires that all passwords be no more than six characters in length. If the password policy 1090 were to combine these rules sets into a third rule set 1088, all allowable passwords in the system would be exactly six characters in length, a six character password being the only type of password that would simultaneously satisfy the rule set of the first resource 1080 and the rule set of the second resource 1082. Such a limitation on passwords would provide little security against hackers, and a company or other organization implementing the password policy 1090 may design a less restrictive rule set. Referring to the immediately preceding example using FIG.
• FIG. 32 A method for determining weak, or overly restrictive, rule sets according to an embodiment of the present invention is shown in FIG. 32.
• the embodiment shown comprises a Monte Carlo method, a numerical simulation method using random numbers.
• the system determines the restrictions on passwords (a tentative password policy) based on a combination of the rule sets of all resources in the system and any additional rules imposed by the organization utilizing the RPM system. Once the tentative password policy has been determined at step 1102, the system generates random passwords at step 1104. Each password generated at step 1104 may be checked at step 1106 to determine whether a generated password falls within the group of allowable passwords for the system.
• the password policy is too restrictive, i.e., it is too "weak," and that too few passwords are available within the confines of the restrictions, thereby making it easy for a hacker to determine a password and enter the system.
• the password policy is revised such that it is less restrictive, thereby allowing more passwords and making it more difficult for a hacker to determine a password and enter the system. If, however, after cycling through a predetermined number of randomly generated passwords, one or more do fall within the group of allowable passwords for the system, it may be determined that the password policy is not too restrictive and testing may end at step 1110.
• a password is chosen at random. If the chosen password falls within the group of passwords the system will allow, it may be determined that the password policy is not too restrictive and is adequate for its purpose. If, however, the chosen password does not fall within the group of passwords allowed by the system, another password is chosen at random and checked to determine whether it falls within the allowable passwords for the system. This process may continue until a randomly chosen password is allowed by the system within the number of tries determined by the company or organization implementing the password policy to be acceptable. For example, a password policy may provide that if a randomly chosen password is not allowed by the system within 500 tries, the password policy is too restrictive.
• the number of tries may be any number deemed suitable by the company or organization implementing the password policy.
• Monte Carlo methods are generally computationally inexpensive as opposed to performing a traditional analysis on a password policy to determine whether it is too restrictive.
• Monte Carlo methods are generally fast and reliable.
• Other embodiments using a Monte Carlo method to determine whether a password policy is too restrictive are possible. For example, in the embodiments previously described, if a randomly generated password satisfies the tentative password policy within a certain number of tries, the password policy is presumed to be not too restrictive, even though the randomly generated password may have been a "lucky guess" that happened to satisfy a password policy that is, in fact, too restrictive.
• a fixed number of randomly generated passwords may be tested for compliance with a password policy in an RPM system. If the number of allowable passwords within the fixed number generated equals or exceeds a percentage determined by the company or organization implementing the password policy, it may be determined that the password policy is not too restrictive. Alternatively, if a randomly generated password satisfies the tentative password policy within a certain number of tries, the process may be repeated one or more times to gain confidence that the allowed password was not simple a "fluke.” As an alternative to a Monte Carlo method, according to another embodiment of the present invention, a traditional analysis may be used to determine whether a password policy is too restrictive.
• FIG. 33 A system by which an RPM system establishes passwords according to an embodiment of the present invention is shown in FIG. 33.
• an RPM system 1120 interfaces to a managed resource 1124 via an agent 1122.
• the agent 1122 maintains, among other things, information regarding passwords used to enter the resource 1124.
• the agent 1122 may maintain such information in a variety of ways, such as, for example, by maintaining an account password table. Alternatively, such information may also be stored in the resource 1124 and communicated to the agent 1122 upon a request by the agent 1122.
• FIG. 33 A system by which an RPM system establishes passwords according to an embodiment of the present invention is shown in FIG. 33.
• an RPM system 1120 interfaces to a managed resource 1124 via an agent 1122.
• the agent 1122 maintains, among other things, information regarding passwords used to enter the resource 1124.
• the agent 1122 may maintain such information in a variety of ways, such as, for example, by maintaining an account password table. Alternatively
• the RPM system 1120 may notify the agent 1122 and give the password to the agent 1122.
• the agent 1122 will notify the resource 1124 and give the password to the resource 1124, thereby permitting the user to access the resource 1124 with the password.
• Embodiments of the present invention relate to systems, devices and methods for the modular development of agents for accessing managed resources using an agent development kit (ADK).
• ADK agent development kit
• Such systems, devices and methods for the modular development of agents allows developers to share work, understand or debug another's agent software, or take over the development of another's agent.
• the ADK contains a standardized set of software modules for performing certain functions, wherein the set of software modules is developed in accordance with the features common to any agent for managing resources.
• the present invention provides a set of "building blocks" that a developer may use to quickly, efficiently, and consistently produce uniform agents for managing resources, with a minimum of code. For example, by utilizing certain protocol-specific modules, a developer can transform a protocol-specific "add user" message into a protocol-independent message. The developer can also write code that calls certain functions to extract data needed for the "add user" request from the protocol-independent message, and sends this data to the resource being managed. A completed agent will include the software modules and functions, the developer's code, and a copy of the API for the managed resource. As illustrated in FIG.
• an FTP protocol 1134 is used to communicate between the RPM system 1130 and third party service providers or managed services (collectively identified as managed resources 1136) through the agents 1132.
• the RPM system 1130 uses the FTP protocol 1134 to send requests to an agent 1132, and the agent 1132 will use the FTP protocol 1134 to send responses back to the RPM system 1130.
• the FTP protocol message format is basically a packet or file.
• the agent 1132 reads this packet or file sent by the RPM system 1130, extracts the relevant data, and calls an API typically provided by the managed resource 1136 to convert the file or packet into a request. Note that the RPM system 1130 does not directly access the managed resource 1136.
• an agent 1132 according to embodiments of the present invention comprises several major elements.
• the agent includes one or more libraries 1140 of software modules, provided as part of an agent developer's kit (ADK) (discussed hereinafter), an agent program 1142 (the code written by the developer), and an API 1144 for the managed resource 1136.
• One library contains protocol plug-ins 1154 for communicating messages 1146 between a client (e.g., an RPM system server) and a server (e.g., a server for a managed resource).
• a message 1146 in the form of a request from the RPM system can be communicated using a number of protocols, including, but not limited to, file transfer protocol (FTP) and Transmission Control Protocol/Internet Protocol
• the libraries 1140 include software modules for each protocol.
• the protocol plug-in library 1154 includes an FTP software module 1148, a TCP/IP module 1156, and a generic X protocol module 1162, indicating that other protocols that may be supported.
• a protocol-specific module in the protocol plug-in library 1154 associated with that port extracts the relevant information from the communication, making the message protocol-independent, and maps the content of the message into a format that the remainder of the agent 1132 can read.
• entities that produce RPM systems and agents may create new protocols and write corresponding protocol-specific modules for the agents to enable communications between the RPM system and the agents.
• an agent can be sold to a third party, who can create a new protocol and write a new protocol-specific module for the agent.
• Another library is the Enterprise Resource Management API (ERMA) library 1158, or message abstraction library.
• ERMA Enterprise Resource Management API
• One module in the ERMA library 1158 dynamically loads the protocol plug-ins 1154.
• other software modules in the ERMA library 1158 are used by developers to abstract messages from the source (e.g. the RPM system server).
• the ERMA library 1158 contains software modules written in view of the features that any agent for managing resources would require (e.g., add, delete user, etc.).
• the software modules contain messaging or routines used to access the content of the message according to the format defined by the protocol plug-in modules.
• the ERMA library 1158 thereby provides a layer of protocol abstraction for the agent program 1142.
• the Interface library 1160 is the interface between the agent program 1142 and the abstracted message, and includes activity logging facilities 1152 and configuration data, as well as the message data itself.
• the agent program 1142 To access the data abstracted by the ERMA library 1158, the agent program 1142 must make API calls to various functions in the interface library 1160, which may, in turn, call the appropriate protocol-independent routines in the ERMA library 1158 (e.g., add user) to extract the add user information from the message, regardless of the protocol of the initial message 1146.
• the appropriate protocol-independent routines in the ERMA library 1158 e.g., add user
• preferred embodiments include an encryption and decryption software module 1150 within the interface library 1160.
• the agent 1132 includes a copy of the API 1144 for the managed resource associated with the agent. Within the API 1144 are function calls to perform any type of request specified in the message 1146 (e.g., add, modify, delete, or search).
• the agent 1132 also includes an application program interface (API) 1144 specific to the managed resource 1136 for communicating with the managed resource 1136.
• API application program interface
• An example use of the agent of FIG. 35 will now be described. Assume, that a client using an RPM system sends a message 1146 to the managed resource 1136 through an agent 1132.
• the message 1146 could be an add, modify, delete, or search request, for example.
• a protocol-specific module in the protocol plug-in library 1154 extracts the relevant information from the communication, so that the message is now protocol-independent.
• the agent program 1142 determines the type of request specified in the message, and calls one or more functions in the interface library 1160, which call modules in the ERMA library 1158 specific to the request to extract from the message the data necessary to perform the request.
• the data might include who the message is from, the account number, the attributes to be added, and the like. For example, assuming that the managed resource 1136 is the NT operating system, an add request would require the user's name, a user ID, a home directory, and a group name. In another example, if a modify request is received to change a user's home directory, new home directory information is contained in the message.
• the agent program 1142 will call the encryption decryption module 1150 to perform the necessary encryption or decryption.
• the activity logging module 1152 may be called.
• Developers include persons associated with the RPM system, independent contractors, or persons associated with the managed resource. Regardless, the goal of any agent developer is to develop an agent program 1142 which allows an RPM system to control access to a particular managed resource. In embodiments of the present invention, the developer need not know the details of the software modules in order to write the agent program 1142. From the developer's perspective, the developer need only know what function the software module performs, what parameters it needs, and what values it returns.
• two software modules within the interface library 1160 perform activity logging and encryption or decryption.
• the developer need only understand how to properly call these modules in order to write an agent program that performs their intended functions.
• the agent program 1142 After calling various functions within the interface library 1160 to extract and perform certain operations on the message data, the agent program 1142 then calls appropriate functions in the API 1144 specific to the request, and passes the data to these functions.
• the API 1144 then communicates the request to the managed resource 1136.
• the managed resource 1136 may communicate a message back to the RPM system when the request has been completed.
• Preferred embodiments of the present invention take advantage of the fact that all agents for managing resources share a set of common features.
• the features common to all agents for managing resources must first be identified.
• a set of libraries containing software modules must be developed to enable a developer to write an agent for managing resources capable of performing all of the identified common features.
• an activity logging software module 56 (see FIG. 35) can be developed. Thereafter, if a developer wants to enable activity logging, rather than writing activity logging code from scratch, the developer can simply call the activity logging software module 1152 from within the agent program 1142.
• the activity logging software module 1152 may receive some variables, perform activity logging, and then pass the result back to the main agent program 1142. It should be understood, however, that there is a not necessarily a one-to-one correspondence between the common agent features and the software modules. In other words, some common agent features may be realized only by writing agent code that calls multiple software modules. For example, if a developer wants to enable the adding of a user account, rather than writing the code from scratch, the developer may need to call several software modules from within the libraries. When executed, these software modules perform the add user request. Although some common agent features have already been mentioned above, a more complete list of agent features will now be described.
• Every agent for managing resources must have the ability to receive requests from an RPM system to add, delete, modify, suspend, and restore user accounts, and search application databases.
• separate functions for extracting data necessary for performing an add, delete, modify, suspend, or restore user account request from the incoming message are included in the interface library 1160.
• activity logging is the function of maintain real-time status of the various activities performed by the agent by means of a log file.
• the agent can be configured to maintain a certain size log file. For example, the agent can be configured to keep a certain number of log files, and when this limit is reached, the oldest log files may be overwritten with new log file information.
• Activity logging is mainly for the benefit of the managed resource administrator or RPM system administrator.
• an activity logging function 56 is included in the interface library 1160.
• Another common agent feature is message authentication and authorization.
• an agent receives a message from the RPM system, embedded within the message is information identifying the user that sent the message, and information related to the user's authorization level. Authentication is the function of determining that the message came from an expected source, and authorization is the function of determining that the user has the right to perform the request contained within the message.
• an authentication and authorization function 1164 is included in the interface library 1160.
• Another common agent feature is the message protocol.
• requests from the RPM system may be communicated using a variety of protocols, including FTP, TCP/IP, and the like.
• the protocol of the incoming message is determined based on the ports 1170 through which the information is received.
• a server for the managed resource 1136 always listens for messages using a particular protocol on a particular port. Every personal computer (PC), mainframe, or Unix based system includes an Internet Assigned Numbers Authority (IANA) daemon, which assigns a port number to each protocol (e.g., port 1000 is assigned to a particular protocol). The server will then listen to port 1000 for messages communicated using that protocol.
• IANA Internet Assigned Numbers Authority
• each agent 1132 provides a consistent API interface among a number of operating system platforms, including, but not limited to, NT, Unix, Linux, AIS, and the like.
• each agent 1132 will have a separate protocol plug-in library 1154 and ERMA library 1158 for each operating system supported.
• the interface library 1160 will use the same function calls to the ERMA libraries for each operating system.
• the agent 1132 when each agent 1132 is shipped, the agent 1132 is configured for the particular operating system of the resource to be managed. Install files for a particular operating system may be provided with the product, and the user will be instructed to run the install files to configure the agent 1132 for the particular operating system. After configuration, only that portion of the agent 1132 specific to the particular operating system will be enabled.
• the API 1144 for each managed resource is written specifically for the operating system of the managed resource.
• each managed resource would employ a different API, written specifically for a particular operating system. Because the managed resource and the operating system being used can be determined in advance of completing the agent 1132, the API 1144 written specifically for that operating system can be copied into the agent 1132, and the developer's agent program 1142 can be written specifically to be compatible with, and call, that API 1144.
• Agents 1132 also have common configuration and registry settings, which are the operational parameters that the agent 1132 must receive and confirm before execution of the substantive portions of the agent program 1142 can proceed.
• a configuration setting indicates the protocols that the agent 1132 will support. Thus, all configuration data must be the same among all agents. Registry settings include access information.
• a configuration and registration function 1166 is included in the interface library 1160.
• Another common agent feature is internationalization, which is the capability of agents to handle user requests in multiple languages, and support these languages through the API. For example, an agent written for Windows NT should allow English-text RPM system requests to flow through to an English-text version of Windows NT, and also allow Chinese-text RPM system requests to flow through to a Chinese-text version of Windows NT. The English language uses
• ASCII strings American Standard Code for Information Interchange
• All characters in the English language can therefore be represented in 255 characters or less.
• Non-visual characters such as line feeds and tabs are represented by byte values ranging from zero to 31.
• the printable ASCII characters are represented by byte values ranging from 32 to 127.
• Extended ASCII which includes graphical characters and special characters such as umlauts, are represented by byte values ranging from 128 to 255.
• Other languages require two bytes, which can represent 68,536 characters.
• Most operating systems support two-byte encoding.
• UTF-8 encoding is a way to represent any character in the world in one to four bytes of data, depending on the language.
• the agent 1132 supports receiving UTF-8 encoded characters in one to four bytes.
• an agent 1132 can support receiving Chinese characters from a Chinese-based RPM system, provided that the API for the managed resource supports internationalized strings.
• the developer of the agent for the Chinese-based RPM system will know in advance what type of UTF-8 coding (e.g., three-byte UTF-8) the agent will be receiving.
• Most APIs support UCS-2, which is a two-byte format.
• an agent program 1142 can be written to include a call to an internationalization function 1168 to map the UTF-8 coded characters into the UCS-2 format, provided that the managed resource supports UCS-2.
• the agent program will call the appropriate "get string" function in the interface library to extract a character in the proper format.
• an RPM system sends a request to the agent 1132 using Chinese characters, and that the communication protocol is TCP/IP.
• the request would be converted by the TCP/IP protocol software module 1156 into protocol-independent data.
• the request is still in Chinese characters.
• the agent program 1142 was written to expect Chinese characters, it will process the data in Chinese.
• the agent program 1142 is written to expect Chinese characters, it will process the data in Chinese.
• the agent program 1142 is in UTF-8 and it is known that the managed resource will only accept UCS-2
• the internationalization API 1168 for performing UTF-8 to UCS-2 conversions will be called by the agent program 1142.
• Another common agent feature is installation and packaging. The packaging of agents should be as similar as possible.
• An installation program may also be provided to a managed resource administrator along with the completed agent 1132, to install the agent 1132.
• Each agent 1132 should use the same installation software so that the installation process is consistent from agent to agent.
• the present invention provides a set of "building blocks" that a developer may use to quickly, efficiently, and consistently produce uniform agents for managing resources, with a minimum of code.
• a RPM system sends a request to an agent, it is in the form of a protocol data unit (PDU).
• PDU protocol data unit
• Protocol Data Unit (e.g., add, modify, delete, search)
• Type (e.g., user)
• Name e.g., user ID
• Operation e.g., add, modify, ⁇ delete, search
• Name (e. g., directory access)
• the PDU contains an "operation” value such as an add, modify, delete, or search operation.
• the PDU also contains sub-objects called entries, which have two types of parameters, "type” and "name.”
• the "type” parameter further identifies the request, and may contain values such as "user” (identifying the type of entity that made the request), while the "name” parameter contains the requesting user's LO.
• Each entry contains also one or more objects called attributes, which further identifies the request.
• An attribute has two values, "operation” and "name.”
• the "operation” value can be, for example, add, modify, or delete, while the "name” value can be, for example, "directory access.”
• the add, modify, or delete operations at the PDU level described above, may be different that the add, modify, or delete operations at the attribute level.
• the "operation” value may be a "modify” request, while at the attribute level of that same PDU, in order to carry out the modify request, it may be necessary to "add" a particular attribute.
• An attribute may also contain one or more values associated with the request. Several attributes may be contained in each entry to facilitate changes to multiple attributes within the same request.
• a RPM system may provide a user with a graphical form containing fields for entering the above-described information.
• the developer will register callbacks or triggers with the agent, which instructs the agent on how it is to be "awakened" when a particular request is received.
• the API function call For example, the API function call:
• Type_of_request erma_get_entry_type(entry) (3)
• Attribute erma_get_entry(entry) (6)
• the agent in line 1 the agent will pass the PDU to my_modify_handler.
• an entry will be read from the PDU.
• the type of request will be read from the entry.
• the user name will be read from the entry.
• Line 5 represents a loop, and within the loop, in line 6, each attribute in a particular entry will be read, and in line 7, each attribute will be processed by calling the function process_attribute.
• various APIs may be called, for example, to perform specific operations such as add, delete, modify, and search.
• a developer can write an agent program that calls various software modules and allows an RPM system to control access to a particular managed resource.
• the task of writing an agent program is not performed in a vacuum.
• the developer may be provided with other materials that facilitate the overall agent development process.
• the libraries and materials together constitute an agent developer's kit (ADK).
• ADK agent developer's kit
• the developer may be provided with a variety of templates that facilitate generation of documents typically generated at each step of the development. Available templates may include, but are not limited to, a Marketing Requirements Document (MRD), a functional specification from which design of the agent may occur, and an agent design specification from which the agent may be coded or developed.
• MRD Marketing Requirements Document
• the ADK may include a kit installer for loading the ADK into the agent developer's environment, a suite of test cases that may be used to certify an agent against designated functionality and interface standards, and methods for gaining access to lab environments, drivers or other test or certification methods and tools.
• the ADK may include a complete set of documentation and training materials. These may exist in hard copy, or may be implemented such that they are available on-line.
• Documentation may include, but is not limited to, an overview of the ADK and the agent development process, system context, an interface description (such as protocols, messages, security, and the like), a description of the API, including, without limitation, usage, calls, variables, and the like), sample implementations, such as code listings with comments, and other knowledge base elements, such as suggestions, frequently asked questions, examples, etc.
• the ADK may include processes and standards that facilitate efficient agent development with consistent levels of quality. These processes may include, but are not limited to, contractual requirements, documentation requirements, coding standards, metrics, certification requirements, and other processes and standards as may be deemed necessary for the efficient development of agents.
• embodiments of the present invention provide systems, devices and methods for the modular development of agents for accessing managed resources using a standardized set of software modules for performing certain functions, wherein the set of software modules is developed in view of the features common to any agent.
• Embodiments of the present invention also allow protocol-independent agent development, enable developers to work faster and more efficiently due to the prefabrication of the software modules, and allow developers to share work, understand or debug another's agent software, or take over the development of another's agent. While the invention has been described with reference to its preferred embodiments, those skilled in the art will understand and appreciate from the foregoing that variations in equipment, operating conditions and configuration may be made and still fall within the spirit and scope of the present invention which is to be limited only by the claims appended hereto.

Applications Claiming Priority (19)

Publications (1)

Family

ID=27578762

Family Applications (1)

Country Status (3)

Families Citing this family (20)

Family Cites Families (3)

• 2002
  • 2002-01-28 JP JP2002561749A patent/JP2005503596A/ja active Pending
  • 2002-01-28 EP EP02717378A patent/EP1364331A1/de not_active Withdrawn
  • 2002-01-28 WO PCT/US2002/002411 patent/WO2002061653A2/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events