A new feature available with BI 4.0 Feature Pack 3 is the ability to import & manage extended user attributes. This is accessible in the CMC:
These extended attributes can be used for filtering and applying security at the universe (.unx) level.
For example if your LDAP server has an attribute called “Country”, you can make use of those values, and filter content in your report based on the value of the Country attribute for any given user, or outright set security so that someone from Canada cannot read content from Germany, and vice versa.
The filtering & security will be set up using the Information Design tool.
Let’s walk through a sample scenario here.
Let’s say I have some users, one residing in the United States, the other in France.
While I can represent this membership through user groups, although in some cases this extended information such as region, country, and department can also be stored in your Active Directory or LDAP server. You may not always have groups configured to represent these extended attributes.
With BI4 Feature Pack 3, you can now reference and consume these extended attributes from your external identity store such as SAP, AD, LDAP, as well as manage these directly for the BI ‘enterprise’ users.
To do so, you must first configure your authentication plugin in and enable the attribute binding options:
Previously, this option would allow you to import the full name and email address, and we have now extended this to do much more.
Once you have enabled this setting, you will need to know the attribute names that you wish to query. In this LDAP example which is a screenshot from my LDAP server, I have an attribute called “Locality” which will be used for country.
To map this value to your users, click on the User Attribute Management link in the CMC
Click on the “Add new Custom Mapped Attribute button”
In the screen you are presented, select the source of the attribute, in our case it will be LDAP:
A quick explanation of the values.
The Name is what will be used in all the UI where you interact with this in the BI tools.
The Internal name is referenced by the internal SDK, and the Information Design Tool.
The Attribute Source name is the attribute value from our LDAP server mentioned earlier.
Once this is done, you can run a user update in the LDAP authentication plugin, or logon as one of the LDAP users to validate that your users have been updated with the appropriate values. In order for the various attribute sources to appear, you must have the authentication plugin correctly configured and enabled. To validate, look at a user’s properties page.
You can now see that the name we defined “Country” has the value from the LDAP server which is stored under “Locality”.
Great! So now what?!
Let’s say I want Jean-Luc’s reports to only contain data for his region, France.
If I first logon to Information Design Tool with Jean-Luc as the user account and run a query on my universe with no filters, I’ll get everything returned:
However applying a filter on country will limit my results to the value of the user’s attribute:
The value we input here is @VARIABLE(‘SI_COUNTRY’) to make use of the custom mapped attributes. Recall that this is the internal name that was set when we created the attribute mapping in the CMC.
If we view the details of our resulting query to see what happens behind the scenes, we’ll get the following:
Where this can become even more useful beyond filtering is during in applying security. Suppose you don’t want users to view data outside their region, as defined by the “Country” attribute in our example.
In the security builder of the Information Design Tool, Insert a Data Security Profile:
Let’s now add a Rows security restriction on the Customers table
Make sure you assign this security to an appropriate group, you can do this for ‘Everyone’, and save your universe.
Now if we logon again with our Jean-Luc user, whose attribute value to ‘Country’ is “France”, our query will always be limited to this value only, and I will not be able to access data for other countries:
If Jean-Luc relocates to the USA, assuming the underlying attribute is updated, their security access will automatically get updated as well, and their data will be filtered to “Germany” only.
While the feature is primarily intended for taking advantage of information in your existing Identity Provider like your LDAP directory store or your Active Directory, you can set this on Enterprise users, and you can also use the SDK to access & set these values.
Failover:
You will notice that you can set multiple attribute sources for any single custom attribute, for example you can configure both your SAP authentication plugin and your AD plugin to pull in the value of Country. The priority of each source is defined when configuring authentication. If a user has an alias for an authentication source, the system tries to take the attribute value from that source, even if the value is empty. If unsuccessful, the system uses the next available source for which the user has an alias. In other words, if I have both SAP & AD configured, with SAP having priority, the value from AD will be pulled in only if my user does not have an SAP user alias, or if they do have an SAP user alias but the attribute points to a non-existing attribute on the SAP system.
About SAP system attributes.
The functionality is limited to the BAPIADDR3 SAP Structure. You can view this information and more if you enter the Structure name BAPIADDR3 into the relevant SAP transaction such as SE11 or SE80.
- SAP Managed Tags:
23 Comments
