Skip to Content

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:

/wp-content/uploads/2012/07/cma2_116406.jpg

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. 

/wp-content/uploads/2012/07/cma3_116407.jpg

To map this value to your users, click on the User Attribute Management link in the CMC

CMA1.jpg

Click on the “Add new Custom Mapped Attribute button”

/wp-content/uploads/2012/07/cma4_116427.jpg

In the screen you are presented, select the source of the attribute, in our case it will be LDAP:

/wp-content/uploads/2012/07/cma5_116428.jpg

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.

/wp-content/uploads/2012/07/cma6_116429.jpg

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:

/wp-content/uploads/2012/07/cma7_116432.jpg

However applying a filter on country will limit my results to the value of the user’s attribute:

CMA8.jpg

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:

/wp-content/uploads/2012/07/cma9_116433.jpg

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:

/wp-content/uploads/2012/07/cma10_116434.jpg

Let’s now add a Rows security restriction on the Customers table

/wp-content/uploads/2012/07/cma11_jpg_116435.png

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:

/wp-content/uploads/2012/07/cma12_116436.jpg

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.

To report this post you need to login first.

23 Comments

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

  1. Manfred Schwarz

    Hi Greg,

    This is a great post ! Wonderful.

    Can you share your knowledge about how to find the names of the Attributes in a Win AD environment. Your screenshot for LDAP showed Country as “Locality (I)” but you inserted just “Locality”. Is there a list for Win AD and LDAP ? If you search for BAPIADDR3 there are some good lists available.

     

    Another point – is it possible to pass SI_VARIABLES to BW Queries (prompts)?

    Best regards

    Manfred

    (0) 
    1. Greg Wcislo Post author

      You can just download an LDAP browser, google “free ldap browsers” and you’ll get a few hits, those will allow you to explore your Active Directory or LDAP identity store including the various attribute names.  Not all LDAP stores will be the same, and yours may be customized. 

      (0) 
      1. Manfred Schwarz

        Hi Greg,

        Thanks for this information. I will try with the ldap browser. What about the possibility to use SI_VARIABLES in conjunction with BW Queries (BICS Interface) ? Do you have experience or use cases here ?

        (0) 
        1. Vamsi Krishna

          Manfred,

           

          First of all as BICS does not use Universes so it is not applicable. Second, even with OLAP UNV universes, some of the funtions (@ forumulas) does not work as they are meant for only Relational sources.

           

          I hope this anwsers you question.

           

          Vamsi

          (0) 
  2. Virsdnana Virsdnana

    Hi Greg,

                       Excellent blog! I have a qn though – Are there any limitations to the number of attributes that can come in?

     

    Thanks

    Virs

    (0) 
    1. Greg Wcislo Post author

      There aren’t any enforced. If you have 1000’s of users and start adding 100+ attribute, you may see some performance impact in the lookup of those values by the system when you use them.

      (0) 
  3. Denis Sproten

    Thanks Greg, I have been looking for this for a while:

    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.

     

     

    Will check it out right away!

     

    Tip: Sysinternals has an “Active directory explorer”, where you can easily check all the non-standard attributes which are available/specific for your company.

    (0) 
  4. Peerzada Tauseef

    Great Post – Thanks

     

    For those who are interested to see the list attributes available within their Windows AD can use Active Directory Explorer (AD Explorer). You do not need admin access over AD to view the list.

     

    Regards
    Peer

    (0) 
  5. Enterprise Services

    Hi Greg,

     

    Great article on this topic.

     

    The LDAP vs the Enterprise Trusted Authentication (ETA) options have been raised in a planned custom web portal implementaion of BO using a third party identiity product for SSO. From what I’ve read (including other articles by yourself), ETA only does what is says and doesn’t implement any row level restriction per se. I’ll use your “Country” example below in some questions I’d like to ask :

     

    1) Within the LDAP, can the Country be mapped to multiple values so the IDT restriction would equate to say

        

         Where Country IN (‘France’, ‘UK’) ?

     

    2) Using ETA  would the Country mapping have to be done in some sort of a database security table in the universe or mapped manually as suggested in your article ?

     

    3) With ETA, do user (aliases) have to exist in the CMS first so a new external user (unknown to BO) can only log on as say “Guest” with no or limited access ?

     

    4) Can the HTTP header information (if used for authentication) be used if it contained additional country detail (say ‘France’) as a query parameter for a Web Intelligence report ?

     

    5) Finally, is the use of LDAP strictly limited to those defned in the PAM guide, that is, would a Red Hat Enterprise Linux LDAP work (unofficially of course) ?    

     

    Kind Regards

    Neil

    (0) 
    1. Greg Wcislo Post author

      Hi Neil.

      Multiple values for a property are not supported unfortunately (your point #1)

       

      The only way to pass/set these values is from an external identity provider (like LDAP) or setting them directly on the enterprise alias.   You cannot pass them in dynamically through trusted authentication.   However you could always look at the SDK to customize something and set these dynamically if you build your own logon wrapper.

       

      Support is obviously limited to PAM only.   Using an unsupported LDAP provider would probably work as well, there is generally very limited ‘specialized’ vendor code for the various LDAP servers and BI really uses standard LDAP protocol here.

      (0) 
      1. Enterprise Services

        Many thanks for your quick reply (especially on a Friday )

         

        So, In summary for my clarificatiton :

        • A supported LDAP covers all options outlined albeit supporting just a single parameter value
        • Trusted Authentication could be enhanced using SDK customisation in the logon wrapper covering points 2 – 4

         

        Thanks again

        Neil

        (0) 
  6. Krzysztof Gasiorowski

    Is it possible to replace Full Name, and Description with different AD attributes or is it hardcoded to some defaults (Description -> description, Full Name -> ?) ?

     

    Is there any logic in order in which additional attributes are displayed in user properties, or is it random ?

    (0) 
    1. Greg Wcislo Post author

      Not through the AD authentication plugin. The LDAP authentication plugin allows you to define which attributes map to which fields (click on “show attribute mapping”).

       

      I am not sure exactly what affects the display order in the properties page.

      (0) 
  7. Peter Chen

    Thanks, Greg.

     

    I just listened to your great presentation on security at TechEd 2013.  During the session, you had commented that a single TOMCAT server can only handle one type of SSO authentication. 

     

    Yet, in this blog, you mentioned you can pull attributes from SAP or AD in the same time. 

     

    Did I mis-understand what you said at the TechEd2013 session ?

     

    Thanks a lot.

    (0) 
    1. Denis Sproten

      Hi Peter,

       

      SSO – Single Sign-on is the mechanism to pick up existing credentials and re-use them with BI4 (for example your Windows login token). Authentication is the mechanism of checking your credentials against the CMS or 3rd party authentication servers (eg AD Server). They are different steps in authentication process.

       

      Only 1 SSO mechanism can be specified for BILaunchpad, but if you login manually without SSO ( or use BOE/BI/logonNoSso.jsp) all the authentication mechanisms can be used LDAP, SAP, WinAD etc (if configured) by selecting them from the dropdown list of the login page (could be hidden through the BILaunchpad.properties file – authentication.visible).

       

      Hence you can import user attributes from different authentication systems, but have only 1 sso mechanism

       

      Kind Regards,

       

      Denis

      (0) 
  8. Matthias Schneider

    Hi,

     

    some other problem:

    I am using user attributes with enterprise security.

    If i am taking it  as a criteria in the data security policy then executing the corresponding report give me a prompt on executing the data provider instead of taking the right value from the user settings in CMC.

     

    Any idea ?

     

    THX

     

    Mats

    (0) 
  9. Tim Forster

    Hi,

     

    Does anybody know if this applies to Bex authored universes in BI 4.2 as well?

     

    Has anybody tested that already based on Beta or RKT version?

     

    Thanks and regards,

     

    Tim

    (0) 

Leave a Reply