Business Intelligence, Delivery Methodology, SAP Business Objects

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.

sec_type_ia
Example of a Type I Security Model displaying a hierarchy of functional 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.

Consumer Creator Type I Model
Example of a Consumer / Creator Type I Security Model

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.

Example of a Type II Security Model displaying two applications with two functional groups
Example of a Type II Security Model displaying two applications with two functional groups

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.

Example of a Type III Security Model where users are members of an functional group and an application group
Example of a Type III Security Model where users are members of an functional group and an application 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.

Example of a Type IV Security Model where each application defines their own functional groups
Example of a Type IV Security Model where each application defines their own functional groups

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.

5 thoughts on “SAP BOE Security Model Patterns”

  1. Hi Al!

    First of all, I found this post very very useful.

    I am implementing a BO platform (BOE XI3.0) in my company and had some trouble when building the security model.

    After reading everything I could online I came to this post you published in SAP Comunity Network Blogs (http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/18728).

    I found this Type III Model quite adequated to my required structure, so I followed the instructions step by step (again thanks very much for the clarity).

    Now, once setup there are a couple of things that are not working as I wish. Maybe I missed something or there´s something else I still need to do:
    1) So I finish ALL the steps and have things set as you described. Next point I guess is to create the users in the system so I go to Users and Groups -> User List and create 3 different users: “Financial_Analysis_User_Standard”, “Financial_Analysis_User_Intermediate” and “Financial_Analysis_User_Advanced”.
    Then I add the first user to these two groups (Standard Users and Financial Analysis Users). Second user added to Intermediate Users and Financial Analysis Users groups and the last one added to Advanced Users and Financial Analysis Users groups.
    This obviously means that for each user in my system I want them to belong to a “thematic” area (Financial Analysis in your example) and be assigned a specific level (Standard, Intermediate or Advanced).
    So I do this with all my users, and therefore after this each user belongs to at least 2 groups (the theme group and level group).
    Fine! But… when I access Infoview with each of these three users, this is the result:
    – “Financial_Analysis_User_Standard”: access, click on Document List and see only “Public Folders” and nothing behind it.
    – “Financial_Analysis_User_Intermediate”: access, click on Document List and see only “Public Folders” and nothing behind it.
    – “Financial_Analysis_User_Advanced”: this one works well: can see the Financial Analysis folder, all the documents and subfolders inside.

    So how I can do to say that a specific user is only standard or intermediate?

    2) A problem with analytics created on the system: when I access with the “Financial_Analysis_User_Advanced” user, I see the Finacial Analysis folder and all the documents. I can view any of them, drill down in WebI documents, refresh Crystal documents, but I can´t:
    – When I create a new WebI document, I select the universe, then I get the WebI rich client, add a query, select the fields and when I click on Run query I just get an empty table. No data, nothing. But I can click on refresh data and I don´t get any error, it seems to be retrieving but the result is just no data. It also correctly saves the document on any public folder I select, and deletes it after.
    – When I want to view an Analytic that is already in the folder I also get the empty analytic. For example, I have some analytics added to a Dashboard. When I open the dashboard, I just see the spaces on the canvas with the name of the chart but nothing else. Same when I individually open each of the analytics.
    – When I want to create a new analytic, I get the “Select the type of analytic you want to create”, I select for example Traffic Light, select Universe Query and get the full list of universes I have. Choose the Measure to display, the dimensions, etc, no problem there but when I click on OK the result is just nothing: an empty screen where I can only read “Traffic Light” and “Add to My Dashboard”, “Edit”, “Email”, “Save” (disabled), “Save As” and the blue refresh button.

    I want advanced users to be able to create analytics, dashboards and webi docs and see the analytics and dashboard contents that are already create.

    What I am missing, any suggestion?

    Thanks a lot for your help 🙂
    Marta

    Like

  2. Hi,
    I found this article very intresting, helpful on understanding security model options in BO.
    We are currently trying to develop a security model for our BO installation: our need will fit in model 3.
    I’d like to ask a question related to security to be applied to our business scenario. We basically have 2 set of users:
    End users: they consume infomration delivered in public folders against scheduled reports; they are not able to refresh reports (via refresh button) BUT they are able to use linked report with refresh on open option enables (to drill to more deatiled report
    Power users: they will consume information as end users + they have the ability to copy reports from public folders into their favorites, modify them and play with data (refresh report data is enabled).

    Having said that here the question: is it a common practice to restrict refresh option to end users and allow them to refresh data only with linked report ? Can these 2 rights be controlled with access levels ? Means, can rights be set up to allow refresh on oopen without having refresh data right enabled ?
    Can this be applied toa folder – subfolder structure where folder is public and subfolder is restrictedn ?

    Thanks a lot for your feedback

    Corrado

    Like

  3. Hi Corrado
    I believe this is possible and your suggestion of using two folders should work – I think it is just a case of putting the view only reports in one folder and on that folder set the rights to the View access level and then the linked reports in a subfolder and set rights to View On Demand.
    I’m not sure if this is common practice or not – personally I prefer to assign functional access globaly – if a user can refresh on report they can refresh all. This keeps the security model simple and makes maintenance and troubleshooting easier.
    Al

    Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s