BusinessObjects XI_ Security Made Easy

7/30/2019 BusinessObjects XI_ Security Made Easy

http://slidepdf.com/reader/full/businessobjects-xi-security-made-easy 1/7

20/12 BusinessObjects XI: Securit made eas

ww.element61.be/e/resourc-detail.asp?ResourceId=219

by Jorn Van den DriThursday, May 12,

RELATEDCOMPETENCE

SAP Business Wareh

SAP BO Upgrading &

SAP BO Performanc

SAP BO ImplementaTransfer

SAP Business Objec

Business Objects BI Services

Business Objects EI

BusinessObjects 6.5

SAP Business Objec

SAP Business Objec

Business Objects BuIntelligence Technol

SAP Business Objec

Business Intelligence

Functional PerformaExpertise

PM & BI Audit

PM & BI Roadmap

home competences elementary team knowledge base careers news & events company contact us site search

english | neder

research & insights

webcasts

books

case studies

BI-kipedia

history of performance

management

useful links

BusinessObjects XI: Security made easy

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 fe tched. 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 t ime also more complex to implement and understand. T he 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 ident ify t he rights someone

had for a specific report. In the object cent ric approach, you cannot see the exact rights someone

has for that ob ject, un less you go to visualize t he 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

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 eve

managed, and almost anything you can manage, can be secured. Almost each object in the CMC can be secured, to mak





, , .

If you take a look at the CMC of BusinessObjects XI 3, you see that more than 10 different types of objects can be secur

Putt ing security on more than 10 items might be overwhe lming to many people, but organize yourself and take one step

with a conceptual security model in which you get a high level view on how the security should be organized. In later step

dig into the detailed rights of your security environment.

Figure 1: the BusinessObjects XI 3 Central Management Console

click to enlarge

The first thing the administrator should ask the organization is: what tpe of user will get access to the Bu

environment?

This first step is necessary to create the different user-profiles that were directly available within the Supervisor in the p

The advantage of the CMC is that you can refine the user profiles and make more profiles than those that were

Supervisor. Next to the naming of the profile, the administrator should give some kind of definition to the profiles, so th

architect knows how to set security.

Figure 2: an example of User Profile definitions

User Profile Description

RefresherRefresh ex isting report

see report instances

Editor

edit existing reports

no changes to report query

add in own variable

Creator

editor rights

edit queries

create new reports

…

Designer

creator rights

create connections

create new universe

edit universe

Administrator All rights

In the above table some user profiles are given as an example, but in reality many more profiles can be created and given a

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

define which user profiles should have access to the different applications. The list of applications can be found in

Application part. The easiest way to see how security should be set, and wh ich user profiles are involved, is to create

applications, as shown in the example below:

Figure 3: W hich user profiles should have access to the different applications? or Who can do what in BusinessObje





Now that t he administrator has defined w hich profile needs which application, it is time to move on t o the next step: whic

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, bu

are now introduced in addition. The report folders come closer to the "Windows way of working”, therefore it is preferred

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

some time on organizing the reports and the access to the reports. Within this new security concept, the access to the fo

compared to the access to a building: you can have the key to the front door of the building, but not necessarily get

apartment on the first floor, o r the basement . Inheritance o f rights is something that will complicate the security structure

rights will work in 2 directions: downwards for the folders and sidewards for the user groups. Once again, try to visualize

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

matrix. Remember that all subgroups (sidewards) inherit security from their parent group and that all subfolders (downward

from their parent folders. Inherited rights are marked as (X)' in the matrix.

Figure 4: W hich user group, will have access to w hich 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

necessary. E.g. t he Northe rn Sales Group (UG_Sales_North) should only have access to t he folder with Sales North, no ot h

should have access to this folder. Please note that if someone should have access to all sub sales folders, new user groups

be introduced. Letus complete the matrix for the example in a few easy steps. First, you have to break the inheritance o

group, to make sure that no subgroup will have access to the subfolders. Next you give explicit rights on the folders they

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 brok





Inheritance should only be broken where necessary and where possible you should make use of the inheritance o f rights.

of inheritance of rights is that you only have to put security on one level to get the subgroups or subfolders to have the

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

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 t he instance manager for schedu ling purposes.

If you have created security on the top 3 levels (applications, folders and universes) almost 80 % of your environment will

you need to put more effort into your security for just a few users with exceptional rules? Everything will depend on h

company is on securing Business Intelligence & reporting environments and how much extra effort has to be put into

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 wa

Within BusinessObjects you have two main options: or you close everything for everyone and open up some specifi

necessary or you leave everything open and just take away some very explicit things. This choice is mainly based on how

should be implemented w ithin your company. Most of the time, all rights are taken away and opened up where necessary

result in a more restrictive environment that will be easier t o administer t owards the future.

Closing up your environment does not mean that you have to explicitly deny every individual right, but that you have to

unknown. BusinessObjects has introduced the concept of unknown' rights to be able to close up your environment, w

having to deny all rights. The unknown' status of a right actually means that t he right is denied until specified differently.

if two rights -that you might get from different user groups- conflict e.g. unknown and allowed, you will receive permiss

object.

Whenever a right is explicitly denied, it will be denied always and everywhere. W ithin the security setup, t he denial of rig

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

steps for building the conceptual model should be repeated to replace the X' in the matrix with a specific right to an app

universe, user group or any other item w hich you can secure and have described in the concept ual model.

Let us start with the first step: What are the specific rights of the user profiles? Before we can proceed to giving

rights, the user profiles should be created within the user groups of BusinessObjects. To make your life as an administ

easier, make sure that you can identify the "user profile groups”; in a best practice you can give the m a prefix (e.g. PRO_)

From BusinessObjects XI 3 onwards, t he different specific rights can be stored and named into access levels. These acce





all specific settings for a certain profile (e.g. Refresher), for a specific object (e.g. Applications). The access levels sho

administrator to identify the group of specific rights (=access level) to appoint to a user group. Giving a good name to you

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 on

he can use the access level when appointing the actual security, which helps him save time. In previous versions of the

XI software, the specific rights could not be stored in access levels; for each individual point to secure, you had to chec

specific rights for that security level. Documenting your specific security rights was crucial: the security had to be id

different profiles over the different folders. It is still wise to always store or document the specific rights in a separate file; y

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. Th

should be given t o the "Administrator” group. This does not mean that every individual crossing in the matrix (every X') shindividual access level. Try to find the common points in order to simplify the security setup and limit the number of

BusinessObjects will show all possible rights for all different levels within one access level. Try to use the rights on th

creating your detailed security on (e.g. do not use folder rights on the application level), otherwise your access levels w

complicated to maintain.

Figure 6: Access level on applications, an example.

click to enlarge

Once all specific access levels needed have been created, you can create a new matrix, whe re the X'-markers are replaced

access levels as shown in the example below.

Figure 7: specific access levels appointed to users groups

click to enlarge

Aft er implementation in the BusinessObjects Central Management Console, the result has to be inserted for each individuathe example be low, a completed security view on the SAP Business Objects Web Inte lligence application is shown.

Figure 8: implemented security on t he Web Intelligence application

click to enlarge

he next step is to set the security rights on the folders. To do so, the question to be answered will be: Who can d

folder he has access to? The answer to this question will be partially based on the user role someone will have withi

creator can have other rights on the folders than a refresher; the creator, for example, might add extra reports in the f

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 r

a "concept ual model bis”, with the user profiles inserted . In this example, t he Sales North user group and the Sales South

receive one or more individual creators, the East and West Sales group will receive a common report creator.

Figure 9:The profiles added into t he conceptual model





Tweet

The groups ending in _creator (or the profile name), will be part of both the user groups and the profile or application g

folder group, the rights on what t he user can see will be inherited, and from the profile groups the user will inherit t he a

When the "conceptual model bis” is validated, the same exercise for individual rights (as made for the applications) can b

folder rights.

Figure 10: individual rights on the final conceptual security model

click to enlarge

All these steps have to be repeated for the supplement ary items you have secured in the concept ual model, t o have a co

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 versioprocess, which needs to be well thought through. There is no unique way to secure a BusinessObjects environment, b

"best practices” and starting from a good overview on what has to be secured (who has access to what, and with whi

good start. The only way t o secure your environment in a proper manner is to t ake your time and take one step at a time

implementing the security.

Within the security setup, documenting the complete environment is most probably the most important "best practice

that your report environment is variable and that security might change due to the growth of your applications, reports,

structures. Therefore the administrator task does not stop once the security has been initially set up. Every change, ev

should be carefully documented both in the conceptual and in the actual, implemented security model.

« back

Advisory | IBM Business Intelligence & CPM | SAP Business Intelligence & CPM | Microsoft Business Intelligence | Interim Management | Hosting home |

2009-2012 | copright b element61 | all rights reserved





Documents

BusinessObjects XI_ Security Made Easy