11g, 12c, 19c, admin, obiee, security, standard configuration

Many times I come across posts and emails asking for help on specific configuration changes or questions asking for help achieving certain things.

Long story short – you can over-complicate everything if you don’t look at what the standard gives you efore going off and hacking / scripting things in an uncontrolled fashion that will come back to haunt you when you patch or upgrade.

Case in point: Implementing new, custom links which should react to standard security privileges.

As in: Adding a link is documented by Oracle, but how can you make this link react to standard privileges which are tied to your Application Roles?

Oracle provides the out-of-the-box functionality of custom links since several years with all the usual bells and whistles. Problem is, that by far not all options are documented in detail with examples. Top tip here: guess what you will never have everything in the documentation, so the important thing is where to look for more information.

Enter the XSD! Every configuration XML comes with an accompagning XSD style sheet which maps all elements and attributes that the XML supports. Find that XSD and you have all the documentation you could ever want. Following the example of making links dependent on OOTB security privileges:


Here we see one of our administrators (prodney) logged in and seeing two custom links rendered. The “SampleApp V607 Index” and the “Custom Link” which is a link to the documentation. Now we don’t want non-admin users to be able to access the documentation link. So how do we go about this?

The customlinks.xml controls the rendering of custom links as described in the official documentation: https://docs.oracle.com/middleware/bi12214/biee/BIESG/GUID-FF6954BA-2DE0-4422-BA58-05F32936F4FF.htm#BIESG3738

That XML file itself is goverened by the customlinks.xsd file. In there we find the following information on the privilege usage:

<xs:attribute name="id" type="xs:string" use="required" />
<xs:attribute name="iconSmall" type="xs:string" use="optional" />
<xs:attribute name="privilege" type="xs:string" use="optional" />
<xs:attribute name="src" type="xs:string" use="optional" />

Now let’s look back at the documentation and an

<link id="l1" name="OTN" description="OTN open in new window" src="http://www.oracle.com" target="blank" >
   <locations>
      <location name="header" />
   </locations>
</link>

My customlinks.xml says the following for the “Custom Link” one:

<link id="l2" name="Custom Link" description="Instructions on how to insert a custom URL on OBI EE headers" src="http://docs.oracle.com/cd/E23943_01/bi.1111/e10541/answersconfigset.htm#BIESG3738" target="blank" iconSmall="common/info_ena.png">
    <locations>
        <location name="header" insertBefore="home"/>
    </locations>
</link>

Nice. Now let’s add 1 and 1.

“id” and “source” are both attributed of “link” just like privileges which gives us the necessary indication of how to use it.

<link id="l1" name="SampleApp OTN Page"  [skipped...] privilege=" hmm what goes here=?! ">

For the content of the “privilege” attribute we simply refer back to the documentation again:

<link id="l1" name="SampleApp OTN Page"  [skipped...] privilege="privileges.Access['Global Admin']">

Which puts the whole entry in the customlinks.xml to this:

<link id="l2" name="Custom Link" description="Instructions on how to insert a custom URL on OBI EE headers" src="http://docs.oracle.com/cd/E23943_01/bi.1111/e10541/answersconfigset.htm#BIESG3738" target="blank" iconSmall="common/info_ena.png" privilege="privileges.Access['Global Admin']>
    <locations>
        <location name="header" insertBefore="home"/>
    </locations>
</link>

Restarting things will now give me the same resutl for my administrative user “prodney”:

And the correctly secured result for my non-admin user “testuser01”:

Piece of cake.

11g, 12c, application policies, OBI, permissions, security

So we know that 12c made some small changes in the security area – the most well known being “BI Administrator” being renamed to “BI Service Administrator”.

This can cause some issues when importing 11g BAR files with old “BI Administrator” roles but set “security model=false” during import. Well this isn’t what this post is about but still something you may want to remember 😉

What this post IS about is the little weirdness which is happening in Application Policies and the Permissions you can grant to a policy and its principals.

Let’s look at the permissions granted to “BI Service Administrator”. There’s two set of rights which look suspiciously similar:

Can you spell “redundant”?

Ok let’s turn this upside down and create a new application grant for a “close to Admin”-type set of rights:

Searching by “Permission Class” oracle.security.jps.ResourcePermission yields 14 results.

Funny enough we don’t find all four of the permissions in the screenshot above. Two catalog permissions are present – “oracle.bi.presentation.catalogmanager.manage” and “*” for the oracle.bi.catalog permission type. “*” for oracle.bi-repository isn’t there though. Hmmm. Let’s search by “Resource Type” and try to find the four in question one by one.

Why hello there. Not only do we find all four but also a nice little remark on the two known ones: Legacy Permission from BI 11g

So it seems that those two are about to get dropped and be replaced by the new “*” resources. But why is only one of the two new permissions visible when searching by “Resource Class” when it seems to actually HAVE the correct resource class assigned to it?

Smells like something needing a little fix. Most important though: going through permissions by resource type and checking the ones labeled as “Legacy 11g” is a good idea in order to not be relying on things on their way out of the product…