Introduction
Between previous versions of Business Objects and the SAP Business Objects XI platform, the vision on security and the complexity of the security has changed a lot. The security has switched from a user-centric model to an object-centric one and from 2 levels of security to many more levels. When migrating to SAP BO XI, one needs to take these drastic changes into account. Within the migration tool set, BusinessObjects provides the administrators with an "import wizard” in which reports, universes, users and even security can be migrated from your previous system to the new BusinessObjects XI platform.
But is this "wizard” migration of security a good idea? And what will happen with the added security features: how easily can they be inserted afterwards in the old security structure on the new platform if you simply migrate using the wizard ? This insight will explain how BusinessObjects administrators can get around this hurdle and make sure that they implement a security structure that is flexible, easy to understand and able to withstand the "curiosity of people” to see all information available in the BI environment.
Object centric vs. user centric
One of the main hurdles to overcome for the BusinessObjects administrators is the switch from a "user centric” to an "object centric” security concept. What is the impact of this change?
The view within the administrator tool has changed a lot with the change of platform. Within Supervisor (BusinessObjects 5.1.x and 6.x) the starting point was the user on the left side of the screen; on the right side, you could see the documents he had access to and when changing the tab the same view for the universe could be fetched. All users could be assigned a predefined role that most of the time was not changed. BusinessObjects had a Generic user, Reporter, Designer, Supervisor, General supervisor and some other profiles that were each represented by their own icon. This meant that you could e.g. easily see that user "Peter”, was a supervisor thanks to the symbol next to his username and that he had access to several categories of reports, individual reports and universes.
Now, the BusinessObjects XI platform organizes security on "objects”. An object can be a report, report folder, category, universe, universe folder, user folder, … . This means that security can be set to a much finer granularity than it could be before. Security can be set for many more levels than within any previous version. This makes the functionality much more powerful, but at the same time also more complex to implement and understand. The user profiles, as used before, are not available anymore and as a result, users cannot be identified at once as being a "reporter” or "designer”.
Within the user centric approach, by selecting a user, you could easily identify the rights someone had for a specific report. In the object centric approach, you cannot see the exact rights someone has for that object, unless you go to visualize the security that is applied to that object. This makes it hard for administrators to identify the exact applied rights to a certain object. This document will help the administrator to identify the security per user.
Securing your environment, one step at a time
From the earliest XI version on, security has been organized in the Central Management Console (CMC). In this CMC everything can be managed, and almost anything you can manage, can be secured. Almost each object in the CMC can be secured, to make sure that no unrightful access is given to folders, scheduling, user creation and so on.
If you take a look at the CMC of BusinessObjects XI 3, you see that more than 10 different types of objects can be secured in the CMC. Putting security on more than 10 items might be overwhelming to many people, but organize yourself and take one step at a time. Start with a conceptual security model in which you get a high level view on how the security should be organized. In later steps, you can then dig into the detailed rights of your security environment.
Figure 1: the BusinessObjects XI 3 Central Management Console
This first step is necessary to create the different user-profiles that were directly available within the Supervisor in the previous version. The advantage of the CMC is that you can refine the user profiles and make more profiles than those that were available in the Supervisor. Next to the naming of the profile, the administrator should give some kind of definition to the profiles, so that the security architect knows how to set security.
Figure 2: an example of User Profile definitions
| User Profile | Description |
| Refresher |
|
| Editor |
|
| Creator |
|
| Designer |
|
| Administrator |
|
In the above table some user profiles are given as an example, but in reality many more profiles can be created and given associated rights in SAP BusinessObjects XI.
Once you have defined the different user profiles, the real work can start: giving specific rights to the user profiles. The next step is to define which user profiles should have access to the different applications. The list of applications can be found in the CMC in the Application part. The easiest way to see how security should be set, and which user profiles are involved, is to create a matrix on the applications, as shown in the example below:
Figure 3: Which user profiles should have access to the different applications? or Who can do what in BusinessObjects XI?
Now that the administrator has defined which profile needs which application, it is time to move on to the next step: which user group, will have access to which group of reports ?
Until BusinessObjects 6.5 the report groups were known as categories; these categories still exist on the XI platform, but report folders are now introduced in addition. The report folders come closer to the "Windows way of working”, therefore it is preferred to use folders from now on, instead of categories.
Organizing your reports in folders and your users in groups has a considerable impact on the security. Administrators have to spend quite some time on organizing the reports and the access to the reports. Within this new security concept, the access to the folders has to be compared to the access to a building: you can have the key to the front door of the building, but not necessarily get access to the apartment on the first floor, or the basement. Inheritance of rights is something that will complicate the security structure. Inheritance of rights will work in 2 directions: downwards for the folders and sidewards for the user groups. Once again, try to visualize the conceptual security structure and take one step at a time.
In the first step, the groups, subgroups, folders and subfolders should be inserted into the matrix. Explicit rights are marked with ‘X' in the matrix. Remember that all subgroups (sidewards) inherit security from their parent group and that all subfolders (downwards) inherit rights from their parent folders. Inherited rights are marked as ‘(X)' in the matrix.
Figure 4: Which user group, will have access to which group of reports?
Once you have a basic matrix with both the explicit and inherited rights, it is time to correct the rights and make them explicit where necessary. E.g. the Northern Sales Group (UG_Sales_North) should only have access to the folder with Sales North, no other Sales Groups should have access to this folder. Please note that if someone should have access to all sub sales folders, new user groups might have to be introduced. Letus complete the matrix for the example in a few easy steps. First, you have to break the inheritance on the UG_Sales group, to make sure that no subgroup will have access to the subfolders. Next you give explicit rights on the folders they will need rights on. Have a look at the matrix below.
Figure 5: Which user group, will have access to which group of reports? - rights made explicit – inheritence broken
Inheritance should only be broken where necessary and where possible you should make use of the inheritance of rights. The advantage of inheritance of rights is that you only have to put security on one level to get the subgroups or subfolders to have the correct security rights applied.
The matrix for the folders and user groups can be used to create a similar conceptual security model on all other levels or items on which you can place security. Here are some examples:
- Who can use which universe? on universes.
- Who can create users or user groups? on user groups.
- Who can use the instance manager? on the instance manager for scheduling purposes.
If you have created security on the top 3 levels (applications, folders and universes) almost 80 % of your environment will be secured. Do you need to put more effort into your security for just a few users with exceptional rules? Everything will depend on how strict your company is on securing Business Intelligence & reporting environments and how much extra effort has to be put into the conceptual security matrix.
Explicit rights : a closed box or all doors wide open ?
From the conceptual model, you can continue setting up the explicit rights for your environment. But what is the best way to proceed?
Within BusinessObjects you have two main options: or you close everything for everyone and open up some specific things where necessary or you leave everything open and just take away some very explicit things. This choice is mainly based on how strict security should be implemented within your company. Most of the time, all rights are taken away and opened up where necessary. This will finally result in a more restrictive environment that will be easier to administer towards the future.
Closing up your environment does not mean that you have to explicitly deny every individual right, but that you have to set the right to unknown. BusinessObjects has introduced the concept of ‘unknown' rights to be able to close up your environment, without explicitly having to deny all rights. The ‘unknown' status of a right actually means that the right is denied until specified differently. This means that if two rights -that you might get from different user groups- conflict e.g. unknown and allowed, you will receive permission to use the object.
Whenever a right is explicitly denied, it will be denied always and everywhere. Within the security setup, the denial of rights thus should be used with the necessary precautions.
The next step : from conceptual model to implemented security
Once your conceptual model has been set up, it is time to assign detailed rights for each intersection in the matrix. This implies that all steps for building the conceptual model should be repeated to replace the ‘X' in the matrix with a specific right to an application, folder, universe, user group or any other item which you can secure and have described in the conceptual model.
Let us start with the first step: What are the specific rights of the user profiles? Before we can proceed to giving the necessary rights, the user profiles should be created within the user groups of BusinessObjects. To make your life as an administrator a little bit easier, make sure that you can identify the "user profile groups”; in a best practice you can give them a prefix (e.g. PRO_).
From BusinessObjects XI 3 onwards, the different specific rights can be stored and named into access levels. These access levels contain all specific settings for a certain profile (e.g. Refresher), for a specific object (e.g. Applications). The access levels should enable the administrator to identify the group of specific rights (=access level) to appoint to a user group. Giving a good name to your access level is important since it will let you identify the applied security in a glance.
Storing the specific rights in access levels is an advantage for the administrator: he has to define the specific rights only once. Afterwards he can use the access level when appointing the actual security, which helps him save time. In previous versions of the BusinessObjects XI software, the specific rights could not be stored in access levels; for each individual point to secure, you had to check or uncheck all specific rights for that security level. Documenting your specific security rights was crucial: the security had to be identical for your different profiles over the different folders. It is still wise to always store or document the specific rights in a separate file; you never know what might go wrong in your security environment or what might happen to your access level.
Best practice is that the lowest rights, or rights that are applicable for every user, are given to the "Everyone” group. The highest rights should be given to the "Administrator” group. This does not mean that every individual crossing in the matrix (every ‘X') should receive an individual access level. Try to find the common points in order to simplify the security setup and limit the number of access levels. BusinessObjects will show all possible rights for all different levels within one access level. Try to use the rights on the level you are creating your detailed security on (e.g. do not use folder rights on the application level), otherwise your access levels will become too complicated to maintain.
Figure 6: Access level on applications, an example.
Once all specific access levels needed have been created, you can create a new matrix, where the ‘X'-markers are replaced by the specific access levels as shown in the example below.
Figure 7: specific access levels appointed to users groups
After implementation in the BusinessObjects Central Management Console, the result has to be inserted for each individual application. In the example below, a completed security view on the SAP Business Objects Web Intelligence application is shown.
Figure 8: implemented security on the Web Intelligence application
he next step is to set the security rights on the folders. To do so, the question to be answered will be: Who can do what in the folder he has access to? The answer to this question will be partially based on the user role someone will have within the folder. A creator can have other rights on the folders than a refresher; the creator, for example, might add extra reports in the folders whereas the refresher will not.
To have a clear view on the profiles having access to the folder, the conceptual model should be extended with the user roles resulting in a "conceptual model bis”, with the user profiles inserted. In this example, the Sales North user group and the Sales South user group, will receive one or more individual creators, the East and West Sales group will receive a common report creator.
Figure 9:The profiles added into the conceptual model |
The groups ending in _creator (or the profile name), will be part of both the user groups and the profile or application group. From the folder group, the rights on what the user can see will be inherited, and from the profile groups the user will inherit the application rights. When the "conceptual model bis” is validated, the same exercise for individual rights (as made for the applications) can be done for the folder rights.
Figure 10: individual rights on the final conceptual security model
All these steps have to be repeated for the supplementary items you have secured in the conceptual model, to have a complete secured and tied up environment.
Here are some more questions to answer in order to complete your security:
- What are the rights I need on the universes I have access to?
- What specific rights do I need on connections I can use?
- What should I be able to do within user groups?
Conclusion
Securing a BusinessObjects environment on the XI platform, whether it is an XI r2, XI 3 or even the future BO 4 version, is a complex process, which needs to be well thought through. There is no unique way to secure a BusinessObjects environment, but using some "best practices” and starting from a good overview on what has to be secured (who has access to what, and with which rights?) is a good start. The only way to secure your environment in a proper manner is to take your time and take one step at a time in defining and implementing the security.
Within the security setup, documenting the complete environment is most probably the most important "best practice”. Never forget that your report environment is variable and that security might change due to the growth of your applications, reports, users or folder structures. Therefore the administrator task does not stop once the security has been initially set up. Every change, even a small one, should be carefully documented both in the conceptual and in the actual, implemented security model.
