Challenge
Configuring OBIEE to use OVD as an authenticator, allowing user accounts coming from OVD to login into OBIEE.
Most of the blogs you find are talking about integrating OID or AD.
Context
OBIEE 11.1.1.6.0 running on WLS 10.3.5
OVD 11.1.1.6.0 running on WLS 10.3.6.0
Both solutions are running on different machines or at lease different images of a virtualization solution.
Solution
Before starting with the technical implementation, we need to clarify something.
There is no concept of multiple authenticators, the
documentation is clearly speaking of "Using Alternative Authentication Providers". This means that you have 2 choices :
- Use the default authenticator: this is the situation ootb. This means that all users are coming from this default authenticator. Also the BISystemUser and the OracleSystemUser are stored in this authenticator. No other authenticators are in place.
- Use a different authenticator: being it an OID-authenticator, an AD-authenticator or OVD-authenticator or even a SQL-authenticator. In this scenario, your new authenticator needs to be the prime one (first in the list of providers in the WLS console) and needs to have all the users and the BISystemUser. The OracleSystemUser may still reside in the default authenticator.
While the documentation seems to allow you the option to have both providing user information at the same time, be aware this isn't the case. Bug 16568236 has been raised for this (this is a documentation bug!).
Now that we have clarified that fact, we know that when we want to use another authentication provider that we need to go all the way, not just adding the provider to list. The latter just works for any j2ee application, but not for OBIEE and I believe neither for WebCenter.
Here are the steps to perform if you want to use OVD as an "Alternative" authentication provider:
- Configure OVD as a new authenticator in the OBIEE WLS domain. Clearly identify the attributes you want to use as unique identifier for your entity. At the customer we used the sn for the readable name of the groups, while the cn has the unique identifier of the group. OBIEE looks at the name of the group to know which group it is and not the unique identifier. So make sure that you have the right configuration there.
- Here is a part of the realm we used :
<realm>
<sec:authentication-provider xsi:type="wls:oracle-virtual-directory-authenticatorType">
<sec:name>OVDAuthenticator</sec:name>
<sec:control-flag>SUFFICIENT</sec:control-flag>
<wls:host>ovd.contribute.be</wls:host>
<wls:port>6501</wls:port>
<wls:user-object-class>inetOrgPerson</wls:user-object-class>
<wls:principal>cn=orclAdmin</wls:principal>
<wls:user-base-dn>ou=users, dc=contribute, dc=be</wls:user-base-dn>
<wls:group-base-dn>ou=groups, dc=contribute, dc=be</wls:group-base-dn>
<wls:group-search-scope>onelevel</wls:group-search-scope>
<wls:group-from-name-filter>(&(sn=%g)(objectclass=groupofUniqueNames))</wls:group-from-name-filter>
<wls:all-groups-filter>(&(sn=*)(|(objectclass=groupofUniqueNames)(objectclass=groupofurls)))</wls:all-groups-filter>
<wls:static-group-name-attribute>sn</wls:static-group-name-attribute>
<wls:dynamic-group-name-attribute>sn</wls:dynamic-group-name-attribute>
<wls:group-membership-searching>limited</wls:group-membership-searching>
</sec:authentication-provider>
- Remark: in the config.xml file you only see the attributes that do not correspond to the default value. That's why not all attributes are mentioned in here.
- Restart the entire bi-domain
- Make sure that you can see your users and the groups. Also make sure that you can see the group information per user in the WLS-console. It is normal that you can not change the information of the user, nor the group, nor the group-information of the user. These are all read-only information.
- To be able to use users from this authenticator, you need to put all others also on 'SUFFICIENT' and put this authenticator first.
- Identify the BISystemUser.
This user is used for internal communication between the OBIEE components. This user must reside in the Authenticator that is first in the list of WLS. The name of this special user may be anything you want.
- Identify a user in the new OVDAuthenticator. This user doesn't need any role. We call this user's username from now on 'bisystemuser'
- Go to the WLS console
- Go to Security Realms -> myrealm -> Users and Groups -> Users
Verify that the bisystemuser appears in the list.
- Now go to Roles and Policies -> Realm Roles -> Global Roles -> Roles. Click on the 'View Role Conditions'-link of the Admin role.
- Now add the bisystemuser as a condition to the list, by clicking on the 'Add Conditions' button.
In the following screen select 'User' as predicate list and click on 'Next'. Type 'bisystemuser' in the first field and click the 'Add' button. Now click on 'Finish'.
Now the bisystemuser should be added to the condition list.
- Click on the 'Save'-button
- Let's do the same thing for the jms module.
In the WLS console, go to Services -> Messaging -> JMS Modules
- Click on the BipJmsResource-link. Go to the Security-tab and then the Policies tab.
- Now, like with the global roles, add the bisystemuser to the condition list.
- Make sure that there are no pending changes in the WLS console, otherwise activate them.
- Perform the following actions in the FMW console
- Under the WebLogic Domain folder, find the BI-Domain and select it.
- From the drop down menu, select Security->Credentials
Now we are going to define which user and his password to use, to communicate with OWSM.
- Select the record 'system.user', under the 'oracle.bi.system'-folder and click on the 'Edit'-link.
- Now enter the username and password from the bisystemuser.
- Now we are going to put this user in the correct application roles.
- Back on the drop down menu from the BI-domain, select Security->Application Roles
- In the field 'Application Stripe', select 'obi' and then click on the search image. Then select the BISystem application role and click on the 'Edit'-link.
- Now click on the 'Add'-link to add the bisystemuser.
- The last step is to specify which attributes from OVD, OBIEE should use.
- Back on the drop down menu from the BI-domain, select Security->Security Provider Configuration
- Under the Security Stores, click on the +-sign for Identity Store Provider. Then click on the Configure-button.
- Use the Add-link to add the following properties:
- user.login.attr = cn
- username.attr = cn
- virtualize = true
- PROPERTY_ATTRIBUTE_MAPPING = GUID=sn
Not sure this does actually anything, it is just that in our stable situation we had this configured.
- Click on the 'Ok'-button.
- Stop the entire BI-environment and restart it.
- When the bi_server1 server is starting, pay attention to the end. If you see an error, saying that something is wrong with the identity store or the connection to it, then you need to repeat the steps previously mentioned.
- Move existing users to the new authenticator.
At this point, you should be able to log-on with the users coming from your OVDAuthenticator. The following steps are needed, when you already had some users logged-on to the OBIEE server before and you moved them to the OVDAuthenticator. The information for these users in the catalog need to be updated. This can be done by the following steps:
- Clean up existing users from the DefaultAuthenticator
- When you moved your users to the OVDAuthenticator and checked that everything is still working, you can then remove the users from the DefaultAuthenticator.
- Try this out with a couple of users, before performing the big clean-up
- Leave the BISystemUser and the OracleSystemUser in place
- If your users also have weblogic roles, you need to add them to the OVDAuthenticator also. Just ad a role for a user by his name, for example : adding the "Administrators" role to a user.
- There is also an option to completely remove the DefaultAuthenticator. We didn't perform this action.
Lessons learned
- If you do not want to move the BISystemUser, then
- the DefaultAuthenticator and the DefaultIdentityAsserter should be the first in the list
- All providers should be set on SUFFICIENT
- Your ProviderAuthenticator should be put last
- It only works when the users are also in the DefaultAuthenticator
- They don't have to have roles in this authenticator, this can be left in your custom authenticator
- The password is also the one from your authenticator
- They just need an entry in the DefaultAuthenticator
- Conclusion: if you do not want to use provisioning, then this is an unworkable scenario
- If you do move the BISystemUser, then
- your authentication provider should be put first
- all providers should be on SUFFICIENT
- all users need to exists in your provider, also the system ones, so BISystemUser
- No need to have the users in the DefaultAuthenticator
- You need to move the BISystemUser => you need to refresh the GUID's => take care of the catalog and rpd information => backup !!
- Before refreshing GUID's, make sure all users exist in the new authenticator
