This is a summarization of some security principles I came up with for some business users. Hopefully others trying to figure some basics behind the security in the CMC will find this useful. Our basic security model was a closed system of increasing rights.
Explanation of BO Access Levels: In Business Objects there are some pre-defined access levels. These access levels grant rights to objects (i.e. folders, reports, universes, connections). Depending on the object type the rights available will differ. Even so Business Objects maintains the names of these five access levels wherever they exist. When possible it is preferable to use these access levels for ease of administration. These access levels are called Full Control, View on Demand, Schedule, View and No Access. When our requirements cant be met by using one of these pre-defined access levels we will have to build a customized access level. The administrative problem with these customized levels is that they are not reusable. They have to be redefined at every level they need to be separately applied at. For each folder the administrator would have to go into the rights section, assign the pre-defined right that most closely approximates the rights he wants to give. From there he will have to change the setting to advanced and modify the individual rights settings by clicking the different radio buttons. This will have to be repeated for each folder, even though the same settings are being applied in each instance. Rights assigned under the various Business Objects applications have no pre-defined access levels and always have to be uniquely defined every time you want to specify them for a given group or user.
Explanation of General Principles of the BO Security Model: When it comes to adjusting rights there are three main choices for any right. You can explicitly grant the right, explicitly deny the right or leave it unspecified. As a rule any rights left unspecified are denied. The No Access level is a good example of how this works. When No Access is universally declared, such as is the case with the everyone group, all rights are set to not specified. As long as they are never granted by inclusion into another group they will remain denied, but it does not stop the user from picking them up by belonging to other groups. Users can belong to multiple groups and can inherit conflicting rights. If a user has been granted and denied the same right by membership in two groups the denial will take precedence. It is a typical best practice when setting up Business Objects security to leave rights unspecified when they are not intended to be granted to a given group. In this way when a user belongs to multiple groups the user will get the least restrictive set of rights. Therefore we very rarely explicitly deny rights because it is contrary to the model of aggregate increasing rights. Of course there may be exceptional situations where this is deemed necessary, but this can be dealt with on a case-by-case basis.
Explanation of the Concept of Inheritance within the BO Security Model: In Business Objects subfolders by default inherit the rights of their parent folders. All objects within these folders also inherit the same set of rights. This is the case so that administration of rights may be simplified. They are specified at only one point, but applied to many. However, if rights are specified at a level below the parent, the specified rights override the inherited rights. If we have a business case where we want to grant access to subfolders exclusively to a smaller group than the group that is assigned to the top level folder this rule can be used to accomplish this and still keep folder-level inheritance in place for all other subfolders. We could assign the primary top-folder group No Access to the sub-folder and that would over-ride any level of access that would have normally been given them by virtue of inheritance from the top-level folder. However, there is administrative overhead in this case. There is another case that would even involve more administrative overhead. Say we want to give a user access to one sub-level folder but none of the other sub-level folders. As a rule they would have to have access to the top-level folder. You would restrict access to all other sub-folders beneath the top-level folder by going into each and specifying No Access for the group. Also keep in mind that in this case as new subfolders were built out the administrator would need to remember to keep propagating the No Access setting to these new subfolders. In both of these cases it would be preferable from and administration work-level POV to create a new top-level folder and build out a group that specifies rights to that. In all cases you are going through about the same work to create the new group. However, if you create a new top-level folder you do not have to modify the primary group that already exists for the other top-level folder. This is the trade off of top-folder expansion vs. administrative work that the business needs to take into account when specifying folder structures to manage content. The other obvious simplification would be to reduce the content segregation in the first place. Every time content needs to be segregated at least one group needs to be created to accomplish this. Also, for each role envisioned for the content (i.e. Power User that can run the report and Data Consumer that can only view-pre-run reports) an additional group will need to be created for each folder or folder set to which this role needs to be applied to.
ryanmonson 
(BOB member since 2005-03-01)
