Configuring BI Publisher to use OVD as authenticator

This post will show the steps to configure OVD as authenticator for BI Publisher i.e users accounts coming from OVD can login to BI Publisher.

Below steps need to be followed to accomplish the same:

Open the BI Domain console and navigate to Realms-> myrealm->Providers. Below page is displayed(OVD Authenticator will not be listed there as we need to configure the same):

Now click on New to configure OVD Authenticator:

Provide a name for Authenticator and Type as OracleVirtualDirectoryAuthenticator  as displayed in the screenshot above. Click OK to save.

Once the Authenticator is created, we need to provide configuration parameters for the same as below:

Under Configuration->Common, select Control Flag as SUFFICIENT.

Now click on Configuration->Provider Specific to provide the other configuration parameters as below:

Provide the below details and click SAVE to save the configuration:

Host, Port, Principal, Credential, Confirm Credential, check SSL Enabled, User Base DN, User Object Class, Group Base DN, Dynamic Group Name Attribute

RESTART THE ENTIRE BI-DOMAIN.

Once the system is restarted, navigate to Security Realms->myrealm->Users and Groups and search if BISystemUser appear in the list as shown below:

Now navigate to Roles and Policies->Realm Roles->Global Roles->Roles->Admin and click on View Roles Conditions:

Click on Add Conditions, select User from drop-down, click Next. Now enter BISystemUser in User Argument Name and click Add to add it to the conditions list and then click Finish and then click Save on below page to save the changes.

Now the similar thing needs to be done for JMS Module. Navigate to Services->Messaging->JMS Modules

Click on BipJMSResource. Navigate to Security Tab and add the condition for BISystemUser there as below:

Now, open EM console and do the following changes there:

Navigate to Weblogic Domain->bifoundation_domain and select it. From drop-down select Security->Application Roles. In the field Application Stripe, select obi and then click the search image, click the BISystem application role and click Edit Link. Once the user is successfully added, it will appear in the list as below:

Now select Security->Security Provider Configuration from drop-down. Now expand the Identity Store Provider and click on Configure Button and the add the following properties[user.login.attr = cn, PROPERTY_ATTRIBUTE_MAPPING = GUID=sn, username.attr = cn, virtualize = true] and click OK to save the configuration:

Now Restart the entire BI-environment and check the logs of bi_server1 for any possible errors related to Identity Store, else we are good to go.

Now take a user from OVD and try to authenticate into BI Publisher, user should be able to authenticate.

Manually Revoking a Resource Object using Database

Have you ever had a Resource Object stuck in a Pending or Provisioning state that you just couldn't do anything about? This happens a lot when first setting up a Resource Object and running Revoke before you create the Revoke tasks. The status will stay on "Provisioned" but all the tasks inside will say "Cancelled" and there's nothing more you can do to it. If you only allow one instance that user is now stuck.

To revoke a struck Resource Object, first we need to search the Resource Object which user has, along with their statuses and necessary keys required later to revoke the RO. Below is the query:

select oiu.oiu_key, oiu.obi_key, oiu.orc_key, ost.ost_status, obj.obj_name, obj.obj_key,oiu.req_key
from oiu inner join ost on oiu.ost_key = ost.ost_key inner join obi on oiu.obi_key = obi.obi_key

inner join 
obj on obi.obj_key = obj.obj_key where oiu.usr_key=(select usr_key from usr where usr_login='USER ID');

Look at the results and find the line that has the stuck object and save the OIU_KEY and the OBJ_KEY.


Next we need the key for this Object's Revoked status. Each Object has it's own set of Status Codes, so to find the ones for our object above, run this query and replace OBJ_KEY with the OBJ_KEY number from the first query above:

select * from OST where obj_key = 'OBJ_KEY';

Look at the results and find the line where the OST_STATUS is "Revoked" and save the OST_KEY.

Next we will update the Object Instance, and set it's status to the new key. If you want to see the current record in it's bare naked form run this (Replace OIU_KEY with the OIU_KEY from the first query):

select * from oiu where OIU_KEY = 'OIU_KEY';

You will see in the results the OST_KEY column. This is the current status of your Resource Object. This is what we are going to change to the new status. So let's run this query, replacing OST_KEY with the OST_KEY from the second query and OIU_KEY with the OIU_KEY from the first query:

update oiu set ost_key = 'OST_KEY' where oiu_key='OIU_KEY';


Perform a Commit and that's it. Pull up the resource profile for the user in the web console and you should see the status for that resource object is now "Revoked".