Management policy rules, or management policies, define actions that are performed as a result of a request occurring in a system. A workflow may apply a policy to one or more objects in a set as a result of a CRUD (Create/Read/Update/Delete) activity. However, no method currently exists for retroactively enforcing a workflow of a management policy rule to objects of a particular set or sets.
Embodiments described herein disclose a system and method to retroactively enforce management policy rule(s) (“MPR(s)”) on objects or resources that are in an “out of policy” state. Also described herein is a system and method that enforce MPRs on resources or objects that are newly included in a set as a result of the definition of the set being modified (i.e., a change in the set's membership filter).
In an embodiment, a workflow of a management policy rule may be retroactively enforced to one or more objects of a target set by identifying the target set, identifying the one or more objects of the target set, determining whether the one or more objects of the target set is in an out of policy state, and automatically enforcing the workflow of the management policy rule to the one or more objects that are in the out of policy state. According to an embodiment, a user or administrator of the system may selectively choose whether to retroactively enforce the new workflow to the objects in the target set or whether to enforce the existing workflow to objects that have been added to a set based on a change to the set's membership filter.
Retroactive enforcement of management policies is accomplished by automatically triggering workflows that are mapped to management policies when: a management policy is created; a final set of a management policy is modified; a new workflow is added to the management policy; and the membership filter or explicit membership of a set referenced by a management policy's final set is modified.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Embodiments of the present disclosure may be more readily described by reference to the accompanying drawings in which like numbers refer to like items and in which:
This disclosure will now more fully describe exemplary embodiments with reference to the accompanying drawings, in which some of the possible embodiments are shown. Other aspects, however, may be embodied in many different forms and the inclusion of specific embodiments in the disclosure should not be construed as limiting such aspects to the embodiments set forth herein. Rather, the embodiments depicted in the drawings are included to provide a disclosure that is thorough and complete and which fully conveys the intended scope to those skilled in the art. When referring to the figures, like structures and elements shown throughout are indicated with like reference numerals.
In an embodiment, a workflow of a management policy rule may be retroactively enforced to one or more objects of a target set. The objects in the target set include objects that currently meet, or at one time did meet, certain criteria. Membership conditions or properties of an object determine, in part, whether the object is part of a given set. The set the object belongs to determines the policies that are enforced on the object and whether the object is in an out of policy state. In an embodiment, an object can be part of more two or more different sets. Thus, when determining what objects and/or sets will be updated based on a changed management policy rule, the system may be configured to only look at sets with objects that will be affected by the update. Alternatively, the system may identify sets having a particular definition (e.g., office location, employee name, employee type etc.).
In another embodiment, a set may define a group. A group may be divided into two categories, a distribution group or a security group. When a group is created, for example a security group, the security group may have an expiry date. In an embodiment, the expiry date cannot be longer than a set period of time (e.g., one year). When the group is created, it may be monitored by a system. The system may monitor the group to determine whether the group has reached the expiry date or whether the expiry date is upcoming (e.g., within the next two weeks). Once the date has been reached, the system expires the group and all policies governing the group are no longer valid. The system may provide to an administrator options to extend the expiry date of various groups.
According to yet another embodiment, retroactively enforcing a workflow of a management policy rule includes identifying the target set, identifying the one or more objects of the target set, determining whether the one or more objects of the target set is in an out of policy state, and automatically enforcing the workflow of the management policy rule to the one or more objects that are in the out of policy state. According to an embodiment the target set or final set specifies the set that the resource must belong to after a request in order for the management policy rule to be enforced. Workflows mapped to a management policy rule are only applied to objects that exist in the management policy rule's final set.
In an embodiment, a user of the system may selectively choose whether to retroactively enforce the new workflow to the objects in the target set or whether to enforce the existing workflow to objects that have been added to a set based on a change to the set's membership filter. In yet another embodiment, and as discussed above, a workflow may be enforced to a set based on temporal restraints (i.e., a predetermined number of days have passed since objects of a set have been given certain privileges associated with the policy rules). In still yet another embodiment, a MPR may have more than one workflow associated with it, with each workflow having zero or more policies. In such an embodiment some of workflows may be retroactively enforced while others may not be retroactively enforced. In still yet another embodiment, when an object has changed or been updated all workflows with their corresponding policies may be identified and run in parallel on the identified object or objects.
The disclosed enforcement of management policies is accomplished by automatically trigging action-based processes that are mapped to the management policies. This may occur when: a new management policy is created; a final set of a management policy is modified; a new workflow is added to the management policy; and the membership filter or explicit membership of a set referenced by the management policy's final set is modified.
An example of requests that trigger action-based processes, and the resulting action, is shown in the following table and will be described in more detail below.
When a request, as indicated in Table 1, is made on a target set or on a management policy rule which warrants a retroactive workflow, only workflows that are associated with the management policy rules that meet certain criteria are triggered. One such example is when the management policy rule's final set does not reference the same set as its current set. In such a case, the management policy is mapping a workflow to a state transition (i.e., enforcing a workflow to an object that is “out of policy”).
Another example of when a request on a set or MPR warrants the triggering of retroactive workflows is when the principal making the request on the set or MPR is a member of the principal set of the MPR that has been triggered. In either case, only state-based workflows that are mapped to the MPR will be run.
When a management policy that maps workflows to a set transition is created, all retroactive workflows that mapped must be applied to each member of the management policy's final set. Thus, the new management policy is enforced on objects that are already in an out of compliance state when the new management policy is created.
In step 120, a determination is made as to whether any workflows in the new MPR are to be retroactively enforced to objects of the target set. In embodiments, in order to identify workflows that can be triggered based on the set an object is in, a specific property, for example, a run on policy update property, may be added to a workflow definition object. In this embodiment, the attribute indicates whether the workflow can be applied retroactively to objects based on set membership (i.e., an object in an “out of policy” state), or if the workflow must be applied to objects as a result of a request.
According to an embodiment, when a workflow is created, the administrator may manually select (through the use of a radio button, check box etc. on a user-interface), whether the new workflow should be retroactively applied. If the new MPR contains any such retroactive workflows, they will be retroactively applied to each object already associated with the target set prior to the creation of the MPR.
If the administrator desires that workflows in the new MPR will be applied retroactively, flow passes to step 130 where all objects in the target set are identified. According to an embodiment, a state of each object is checked to determine whether the object has certain criteria associated with the target set. Continuing with the example from above, step 130 provides that each object associated with the “Full Time Employee” set is identified.
In step 140, a process is launched which enforces each retroactive action workflow mapped to the MPR to each object in the target set. For example, each object associated with the Full Time Employee target set will be given RAS access. Thus, each person or object previously identified as a full time employee prior to the newly created MPR workflow should be given RAS access. In addition, people or objects identified as full time employees and added to the target set after the new MPR workflow was created will also be given RAS access.
According to an embodiment, workflows may be retroactively enforced in a set referenced by an MPR when the MPR's final set does not reference the same set as its current set. Additionally, each MPR may have zero or more workflows associated it with it. Therefore, more than one action workflow may be enforced in step 140.
However, if it is determined in step 120 that the new MPR is not to be enforced retroactively, the method proceeds to step 150. Step 150 provides that the workflows of the MPR will only be enforced against newly created objects added to the target set after creation of the new MPR. Thus, in the example above, only people or objects created and associated with the Full Time Employee set after the creation of the new MPR will be granted RAS access.
When a management policy that maps workflows to a set transition is updated, all of the retroactive workflows that are mapped to the management policy must be applied to each member of the management policy's final set.
In addition to updating the MPR, an administrator may also identify the target set to which the updated MPR is to be enforced against (i.e., Full Time Employee set). The target set identified may be the set to which the MPR previously applied, or alternatively, the set may be an entirely new set.
In step 220, identification of a new workflow to be applied by the MPR is received. This identification may be made by an administrator when the MPR is updated. Alternatively, a system may identify the new workflow to be enforced.
In step 230 a determination is made as to whether any workflows in the updated MPR are to be retroactively enforced against the target set. According to an embodiment, when the workflow is created, the administrator may manually select (through the use of a radio button, check box etc. on a user-interface), whether the workflow will be retroactively applied when it is mapped to the MPR. As stated, there may be zero or more workflows that may be retroactively enforced.
If it is determined that the updated MPR should be retroactively enforced, step 240 provides that all objects in the target set are identified. In step 250 each new retroactive workflow is enforced against each object in the target set.
Continuing the example from above, each object associated with the “Full Time Employee” set will be identified and each object currently in the set will be given an AD user account in addition to having RAS access.
If however, a determination is made at step 230 that the updated MPR is not to be retroactively enforced, the method 200 continues to step 260 which provides that the updated policy will only be enforced against newly created objects added to the target set after the policy has been updated. Thus, objects that currently exist in the target set will not be given an AD account and will only have RAS Access.
In contrast to when a management policy rule is updated and the updated policy is enforced to all objects of the current set, when the explicit membership or membership filter of a set referenced by the final set of a management policy is updated, all of the retroactive workflows mapped to the management policy must be enforced against each of the new members of the set.
In step 320, MPRs are identified which reference the set that need to be retroactively enforced. Once identified, step 330 provides that objects that transitioned to the set (e.g. interns) by the updated filter are to be identified.
Once the objects are identified, the method flows to step 340 workflows of the MPRs that need to be retroactively enforced are identified.
Step 350 provides that the retroactive workflows of the management policy rules are applied to each object that transitioned into the set. As explained, each intern object that existed in the system and transitioned to the Full Time Employee set is given RAS access and an AD user account.
Once the MPR has been updated, flow proceeds to step 370 where identification of the new target set to which the MPR applies is received. Alternatively, in the case where the policy has been updated or changed, the target set may be the same set to which the MPR first, and still does, apply. Continuing the example and as stated above, this step provides that an identification is made that the “Grant FTE entitlements” is going to be applied to the “Part Time Employees” set instead of the “Full Time Employees” set.
In step 375, a determination is made as to whether the MPR is to be retroactively enforced against the objects in the new target set. If yes, flow proceeds to step 380 where all objects in the new set (i.e., the “Part Time Employees” set) are identified. After all objects in the set are identified, step 385 provides that each retroactive workflow that mapped to the MPR is enforced against each object in the target set. Thus, finishing the example from above, each person associated with the “Part Time Employee” set will be given RAS access.
If however the determination is made that the MPR will not be enforced retroactively in step 375, flow proceeds to step 390 and the MPR workflows will only be enforced against newly added objects.
With reference to
In its most basic configuration, computer system 400 comprises at least one processing unit or processor 404 and system memory 406. The most basic configuration of the computer system 400 is illustrated in
Additionally, computer system 400 may also have additional features/functionality. For example, computer system 400 includes additional storage media 408, such as removable and/or non-removable storage, including, but not limited to, magnetic or optical disks or tape. In some embodiments, software or executable code and any data used for the described system is permanently stored in storage media 408. Storage media 408 includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. In embodiments, the capability negotiation methods and wrapper inner methods are stored in storage media 408.
System memory 406 and storage media 408 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (“DVD”) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, other magnetic storage devices, or any other medium which is used to store the desired information and which is accessed by computer system 400 and processor 404. Any such computer storage media may be part of computer system 400. In embodiments, system memory 406 and/or storage media 408 stores data used to perform the methods or form the system(s) disclosed herein. In embodiments, system memory 406 stores information such as management policy rules 414, set definitions 416, and the state of each object of the system 418.
Computer system 400 may also contain communications connection(s) 410 that allow the device to communicate with other devices. In embodiments, communications connection(s) 410 may be used to transmit and receive messages between sender devices, intermediary devices, and recipient devices. Communication connection(s) 410 is an example of communication media. Communication media may embody a modulated data signal, such as a carrier wave or other transport mechanism and includes any information delivery media, which may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information or a message in the data signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as an acoustic, RF, infrared, and other wireless media. In an embodiment, the methods described above may be transmitted over the communication connection(s) 410.
In some embodiments, computer system 400 also includes input and output connections 412, and interfaces and peripheral devices, such as a graphical user interface. Input device(s) are also referred to as user interface selection devices and include, but are not limited to, a keyboard, a mouse, a pen, a voice input device, a touch input device, etc. Output device(s) are also referred to as displays and include, but are not limited to, cathode ray tube displays, plasma screen displays, liquid crystal screen displays, speakers, printers, etc. These devices, either individually or in combination, connected to input and output connections 412 are used to display the information as described herein. All these devices are well known in the art and need not be discussed at length here.
In some embodiments, the component described herein comprise such modules or instructions executable by computer system 400 that may be stored on computer storage medium and other tangible mediums and transmitted in communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Combinations of any of the above should also be included within the scope of readable media. In some embodiments, computer system 400 is part of a network that stores data in remote storage media for use by the computer system 400.
This disclosure described some embodiments of the present disclosure with reference to the accompanying drawings, in which only some of the possible embodiments were shown. Other aspects may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments were provided so that this disclosure was thorough and complete and fully conveyed the scope of the possible embodiments to those skilled in the art.
Although the embodiments have been described in language specific to structural features, methodological acts, and computer-readable media containing such acts, it is to be understood that the possible embodiments, as defined in the appended claims, are not necessarily limited to the specific structure, acts, or media described. One skilled in the art will recognize other embodiments or improvements that are within the scope and spirit of the present disclosure. Therefore, the specific structure, acts, or media are disclosed only as illustrative embodiments. The disclosure is defined by the appended claims.
This application claims the benefit of U.S. Provisional Application No. 61/059,572 filed Jun. 6, 2008 which is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
61059572 | Jun 2008 | US |