SAP BOE Security Model Patterns

Security Modelling is concerned with two areas: authentication – establishing who the user is, essentially the logon process and authorisation – controlling user access to different areas of the system. This article discusses four different design patterns for authorisation security models that can be used in SAP BusinessObjects Enterprise.

In SAP BusinessObjects Enterprise (BOE) we use the Central management console (CMC) to define our security model and we can grant or deny access to a vast array of options and features throughout the system from controlling which documents can be viewed to what features within an application can be utilised – download to Excel in Web Intelligence, for example.

It is great that there is such a large degree of control however the downside is that it is then very easy to create a security model that becomes overly complex and difficult to manage. In particular we find that several settings can conflict with each other and say prevent a user from being able to view a document and in these situations it can then be very difficult to determine which setting needs to be changed.

It is therefore important to develop a security model that is well defined, documented and tested in order to avoid such issues as described above. This article looks at four different security model design patterns, describing the advantages and limitations of each.

Review of Security Modelling

A previous article introduced the idea of a BI application where development is focused on the application as a whole rather than just cranking out reports and universes. One of the key benefits of this approach is in security modelling as we can build security models for each application.

The security model of a BI application is concerned with three distinct areas,

• User access – which users are allowed access to the application
• Data access – what data is exposed through the BI Application
• Functional access – what the users can do with this data

The security model patterns described below focus on these three areas.

Type I. A Simple Group Structure

This is the most basic of security models to implement and we only concern ourselves with functional access. We deliberately disregard user and data access as essentially we are deploying a single BI application.

As such it should only be utilised for small tactical deployments although it is possible to convert this model to a Type III model (discussed later).

Overview

This model consists of a hierarchy of groups that control functional access. This model does not provide any means of segregating user and data access and this then means that all users are allowed to access all data.

The Everyone group has minimum access – essentially not much more than logon. We then create a series of groups that are built in a hierarchy below Everyone where they inherit and extend the rights of the parent group. In the example diagram below we have a group ‘Basic’ that inherits rights from everyone and in this group we can extend rights to say allow users to view documents. We then add further groups each inheriting and extending rights until we have a group that provides full rights to a user. Users are then placed in these groups.

This is known as a hierarchy structure of increasing rights due to the fact that as we move down the hierarchy we increase the rights available to the users who are members of the groups. It is possible to have a hierarchy structure of decreasing rights where we start with the Everyone group providing full access and then the child groups reduce more and more rights. This decreasing rights model does have one significant area of risk. When a new user is created in BOE they are automatically placed in the everyone group by default. Then a system administrator is required to manually put them into their correct group. If a user is not moved then they remain in the Everyone group with full rights to the system, this is quite a significant risk and for this reason this decreasing rights structure is rarely used.

The diagram above is an example where we have 4 different functional access groups however you can have more or less than this depending on your requirements. Also shown in the illustration is an example of having two advanced groups providing different functionality – here it is access to one of two modules.

The table below is an example of the functional access provided by the above illustration.

Group	Rights
Everyone	• Logon to InfoView only and no other modules • access to basic docs such as ‘getting started’ guide
Basic	Inherits rights of Everyone group and extends the following • view reports created by IT or other users. • View Xcelsius dashboards • Can print, download reports
Intermediate	Inherits rights of Basic group and extends the following • Refresh reports
Advanced Web Intelligence	Inherits rights of Intermediate group and extends the following • Can create new Web Intelligence documents
Advanced Voyager	Inherits rights of Intermediate group and extends the following • Grants access to the Voyager OLAP module

Consumer / Creator Model

The simplest Type I model is a consumer/creator model where a user is either a consumer of reports or a creator of reports. For example if our BI system is limited to purely operational reporting we make use of this model where all users are consumers and IT staff are creators.

Here the Everyone group grants rights to view and refresh reports and from this we have a child group “Creator” that extends rights and allows users to create and edit reports.

Advantages of the Type I Model

• Simple
• Low cost of development
• Easy to maintain and troubleshoot

Limitations

• No application and data access segregation – all users have access to all data

Type II Model – Simple Model with Separate Application Access

The Type II model addresses the lack of application separation in the Type I model by defining separate groups for each application. In order to keep the complexity at a minimum we also reuse these groups to define functional access so that each group then defines both application and functional access. Note there is no inheritance in this model other than default inheritance from Everyone group.

Overview

The illustration below is an example of two applications each defining two functional levels.

Each group separately defines user access, functional access and data access.

The functional access can be different for each application, that is, the “basic” users for one application can have different functional access to “basic” users in another. However this can also lead to having to duplicate security settings between groups in different BI applications – if a functional group (say Basic) is the same for both applications then we still need to create two “Basic” groups, one for each application.

Users are expected to only be added to a single group and should not exist in two. This is due to the possibility of conflicting functional security rights between groups. This then limits a user to only be able to access one application.

Due to this limitation and further restrictions listed below this type of model should only be used where the is only two or three BI applications being deployed and there is a need for separate security models.

Advantages

• Simple
• Low cost of development
• Easy to maintain and troubleshoot
• Separation of BI applications
• Different functional access in different applications

Limitations

• A user can only ever access one application
• Can lead to duplication between groups in different BI applications
• Users ending up in two groups by mistake may have unexpected access rights
• Can quickly lead to having to create and maintain a large number of groups

Type III Model – Separating Functional Access Groups from Data Access Groups

The Type III model is probably the most common model to implement as it has the right balance between flexibility and cost of development and maintenance. Here we have 2 sets of groups: one that defines functional access and one that defines application access. A user is then a member of one of the functional groups and one or more application groups; this then defines overall access.

Functional Groups

We first define the required functional access groups in the same manner as we have for the Type I model. In the example illustrated below we have 3 functional groups of Basic, Intermediate and Advanced where again we have an inheritance model of increasing rights. This, along with the Everyone group defines the ‘baseline’ security model. Users will be a member of at most one of these 3 groups, if a user is in more than one then the resolved access will be that of the more advanced group.

BI Application Groups

We also create user groups that define separate BI Applications. The BI application itself defines data access, that is, it controls access to reports and universes that comprise the application. Users can belong in one or more of these groups.

A user then belongs to one functional group and one or more application groups. It should be noted that a user can then only have the same functional access across applications, that is if a user is a “Basic” user in one application they must also be a Basic user in any other application they have access to. A second similar point is that each application must reuse same functional access model, that is, we can’t have two Basic groups with different functional access in two different applications.

Advantages

• Flexible model
• Easy to interpret what access a user has by examining group membership
• Easy to promote user functional access without impacting application access.
• User can access multiple applications as required

Limitations

• All applications must use same functional access model – “Basic” in one application is same as Basic in another
• A user can’t have different functional access in different applications – i.e. user can’t be Basic in one application while Intermediate in another.

Type IV Model – Separation of functional and data access control

The two limitations of the Type III model are addressed by the Type IV model where we define a functional group hierarchy within each application.

Overview

The first groups created below Everyone define the different BI Applications. These groups control the data access in the same manner as we have in our Type III model. Below each of these we create a functional group hierarchy in the same manner as we have already seen above.

In the diagram above we see two applications A and B and below these we have defined a functional group hierarchy. Note, each application has a unique hierarchy that does not necessarily duplicate functionality across applications

Users are placed in the functional groups, they do not need to be placed in the “application” groups as the functional groups will inherit the access rights of the application groups.

An alternative is to drop the first functional group and include the functional access rights of this group with the application group so that you can have users existing within the application group.

Note, it is not possible to fully separate functional access within the current version of BOE which at time of writing is XI3.1. For example, it is not possible to allow a user to edit the SQL in one application but not another. This is because this right is defined on the BOE Web Intelligence application rather than within a public folder and it is the public folders that are used to separate the applications.

Advantages

• Allows segregation by application for both data access and most functional access
• Retains a simple hierarchy model for functional groups
• Different applications can have different models
• Users can have different functional access in different applications.

Limitations

• No scope for reusing a functional group between applications – each application created must also define from scratch a functional model even if it is exactly same as another application
• Can be confusing to users who have access to multiple applications but having varying degrees of application access.
• Not currently possible in BOE XI3.1 to have full separation of all functional access between applications.

Conclusions

Above we looked at four different types of security models. This is by no means the only four types you can every implement but it should give you an idea of what considerations should be made when implementing security. Certainly it should never be implemented in an ad hoc fashion and some diligent requirements analysis and testing is essential in order to have a successful implementation.

The table below summarises the four different security models and describes when best to use each one.

Model	Advantages	Limitations	When to Use
I	Simple Low cost to development and test Low cost to maintain and support.	No application segregation – all users can access same data	Single application deployments Prototypes BOE System not expected to grow in size – no new applications
II	Simple Low cost to development and test Low cost to maintain and support Separation of BI applications	Repetition between groups A user can only ever access one application Users ending up in two groups by mistake may have unexpected access rights Can quickly lead to large number of groups as number of applications grow	Deployments limited to 2 or more separate applications BOE System not expected to grow to more than 4 or 5 applications
III	Flexible model Easy to interpret what access a user has by listing group membership Easy to promote user functional access without impacting application access User can access multiple applications as required Separate access control for functional and data access requirements Standardises functional access across applications Medium cost to develop and maintain	All applications required to use same functional access model Changes to functional access require by one application will impact other applications A user can’t have different functional access in different applications	Medium to Large sized deployments
IV	Allows segregation by application for both data access and most functional access Retains a simple hierarchy model for functional groups Different applications can have different models Users can have different functional access in different applications	No scope for reusing a functional group between applications – each application created must also define from scratch a functional model even if it is exactly same as another application Can be confusing to users who have access to multiple applications but having varying degrees of application access. Not currently possible in BOE to have full separation of functional access between applications	Medium to Large sized deployments requiring a finder degree of control of application specific functional access.