Skip to Content

Long time SAP Business Intelligence customers will be familiar with the product’s support of using external identity providers for authentication to the BI system, such as external SAP systems, Active Directory or LDAP. 

I will go over some new improvements delivered in BI4 which should please the system administrators in this area.

The improvements are two-fold.  The first is around performance, and second, around giving you more control.

Let’s take LDAP as an example.  Previously, when a user logged into the BI system, The Central Management Server (CMS) would validate the user against the LDAP server, and validate the user’s group membership.  The group membership tree would be loaded in memory, and updated periodically.  If you had more than one CMS, each CMS would keep its own memory cache of this information, and update it periodically, putting more stress on the LDAP server.

With BI4, this group information is persisted into the BI repository database, and is shared by each CMS, which means you no longer have more than one CMS getting the same information.

We have also given you the ability to schedule when the updates are run, so that you can make these updates outside of business hours for example.  Again if you look at the LDAP configuration options, you will see a new entry for scheduling LDAP updates, where you can control when these updates are run.  These will not run automatically, so you do need to schedule these in order for the updates to execute.

This is what the scheduling options looks like, and you can even set an end date if you wish.

The SAP authentication options have a similar scheduling option that you will find on the User Update tab:

The SAP updates are split into updating roles, and updating users who are members of those roles.  Again you must set up the scheduling in order for the updates to occur.

As previously mentioned, even when you have a large cluster, you only need to schedule this once, and the information will be persisted in the BI repository and each CMS will use this information.

There is one behavior change that results from persisting the group information in the BI repository.  If you disable the authentication plugin, all rights evaluations will still count the groups that came from this security plugin. 

For example if the group “Sales” was imported from LDAP and ‘Sales’ was given rights to a folder containing reports, then any user who is a member of the ‘Sales’ group will still have access to this folder.  Of course when you disable the LDAP security plugin, no LDAP users will be able to authenticate, but if you have created an “Enterprise” user and added them to this LDAP group, this group will still be treated as a valid group in BI.

To summarize, this small change will put less load on your identity store, and it will give you much more control over when your identity store is queried by the BI system.

  • Improved performance in BI, does not require back & forth communication between BI servers and external identity provider like LDAP or AD.
  • Persistence of group membership in the BI repository instead of querying the identity providers with each request allows sharing of this information between multiple CMS servers in clustered environment.  Only one synchronization needs to be done instead of multiple ones.  Less load on your identity provider.
  • More control – ability to schedule group membership & user updates on each security plugin.
To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Arvind Pandalai

    Hi Greg,

    The article is really good. The explanation around session persistence for CMS actually made it a bit confusing for me; hence I thought of asking the question.

    Persistence of group membership in the BI repository instead of membership allows sharing of this information between multiple CMS servers in clustered environment

    So here it seems as though in 3.1 and lower versions, were all the sessions being transffered to a primary CMS and then to secondary CMS? If yes, how was this being performed and how does the CMS or CMS Db comes to understand at any given point of time?

    My knowledge on admin is limited and hence need your help to understand the behavior in a more appropriate manner.

    Thank you

    (0) 
    1. Greg Wcislo Post author

      This seems to have been an incomplete sentence on my part.  I’ve made a small update, but the benefit here is that by persisting the group membership on the CMS, we do not need to send queries from each CMS for each logon to get the user’s group membership.

      The session management between CMS servers with respect to failover is not affected here.  The CMS reaches out once to validate the user against your identity provider.  After that, the session is with the BI system.   Your actual session is an object stored in the repository (this is how you can see the sessions logged into BOE from the CMC because the system is able to query the CMS). 

      (0) 

Leave a Reply