Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member184468
Active Participant

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.
3 Comments