Oracle BI EE 11g & Oracle ADF - Part 1 - Understanding Security Integration

Over the past few months myself and Mark have written about some major BI EE 11g new features. In addition we had also covered how the security has changed from BI EE 10g to 11g. But what we have not yet covered in detail is how much Oracle ADF or the Oracle Fusion Middleware has influenced most of the features in BI EE 11g. In addition, there are always lingering questions like why do we need Application Policies, Can we create new custom policies, how are these policies stored and how do policies influence application roles in BI EE security.

There is always a need to extend BI EE's capabilities as not all customer requirements can be satisfied by BI EE alone. For example, customers might require a custom Write Back application(due to obvious native write-back limitations) page to be built using ADF. But again the custom page might have its own security framework (Groups & Roles). Till BI EE 10g, though we can create custom ADF pages, there was no way to sort of integrate the security. But in 11g, we now have a unified framework which alleviates many common security issues. Lets try to understand this in detail by building a custom ADF application.

Before we start building the application, lets do a quick recap on 3 main security stores in BI EE. As Mark mentions here, the 3 stores are based on the Oracle Platform Security Services (OPSS) standard. They are the Credential Store, Identity Store and the Policy Store. Just to give an overview before building the application

Credential Store:

This is nothing but a physical encrypted file that will contain all the one time credentials required by BI EE to authenticate into other systems. It is arranged in the form of Credential Maps and Credential Keys.

Identity Store:

This store denotes the users and groups used by BI EE. It denotes LDAP or Weblogic native LDAP depending on what is used.

Policy Store:

Policies are nothing but various entry points in an application that can be secured. For example, we might have many pages in an application and each page might require different security. These pages do not correspond to BI EE pages (any ADF application page) as security of BI EE UI is handled by Presentation Services and hence does come under the purview of Policy Store.

With that overview, lets start of by creating a simple application using Oracle JDeveloper 11.1.1.3. We will be creating 1 page in this application which will basically be a simple tabular report. We begin by creating an application named BIEEADFSecurity.

This application will contain 2 projects. One is the Model which will hold the business components like View Objects, Entity Objects etc. The other is the ViewController which will have the UI components like JSP pages etc.

In the Application Resources area, create a new database connection to the HR schema.

Right click on the Model project and then create a new Business Component - Entity Object.

Use the HR database connection and use the EMPLOYEES table for creating the Entity Object.

Accept all defaults till the View Object screen. ensure that creation of the View Object and Application Module are selected.

After creating the Entity Object, create a new JSF page from the ViewController project.

Give the page a name as ViewReport.jsp

Drag and Drop the EmployeesView1 view object to the ViewReport.jsp. Choose ADF Table as the View.

Open up the adfc-config.xml and then drag/drop the ViewReport.jsp to this page.

Now right click on the adfc-config.xml and click on Run to run the application.

So far, we have just created the application. Currently this application does not have any security in it. But there is one credential that we used for connecting to the database (HR schema password). Lets find out where this gets stored. If you navigate to the JDeveloper work directory, you can find a file called cwallet.sso. This is the file that contains this credential and hence this acts as a credential store for this application.

Now, to our application lets add some security. To do that we go through the ADF application configure Security wizard.

Let's choose the ADF Authentication & Authorization option. Also, we will choose the HTTP Basic authentication for the front end jsp page.

Lets make the application more secure by choosing no automatic grants i.e. no page will become visible unless appropriate privileges are applied.

If you notice, in the last step we will see all the individual files that contribute to the security of this application.

We will cover these files in detail a bit further below. For now, lets assign some security to the ViewReport.jsp page. To do that, we go to the Application Roles menu (this is now enabled as we have enabled the ADF security by performing the above 4 steps)

If you notice there are 3 sub-menus. One of the Users, the other for Enterprise Roles and the third for Application Roles. Enterprise Roles are nothing but Weblogic Groups or any provider specific groups. Remember, we haven't deployed this application yet to weblogic. So, the provider for us in this application is a file based provider. Lets now create a User called ReportUser and assign a password.

Then lets go to Application Roles and add a Role called ReportUserRole.

Similarly, lets create an Enterprise Role called ReportUserGroup.

Lets now go to the ADF policies and then for the ViewReport.jsp page lets try adding the application role.

As you see, we now have 2 pre-defined roles that is part of any ADF application i.e. authenticated-role and anonymous-role. These 2 roles are inherent to ADF and hence cannot be modified. This is the same authenticated-role that we see in BI EE 11g.

Also we now have a pre-defined policy as well. After creating the policy assign the ReportUser user to the ReportUserGroup. In the same way assign the ReportUserGroup to the ReportUserRole.

Lets now run the application again and login as the ReportUser. The user should be able to see the table view jsp page.

So far, we have built a standalone application where we have the complete security defined (Users, Groups, Roles & Policies). Lets see where these security artifacts get stored. There are 2 files in a standalone application called jazn-data.xml and jps-provider.xml.

1. jazn-data.xml - Stores the Application Role to Policy mapping. Also stores the Role to Group/User mapping along with the usernames/passwords & groups. In effect, this is the file that is basically the Policy Store & Identity Store of this application.

2. jps-provider.xml - This acts as the default provider for the standalone application. This will contain the details of the location of the Credential Store, Identity Store and Policy Store files. Also, this basically is the fundamental file that determines all the security used in the application.

Lets now look at the content of these files. First up is the jazn-data.xml.

As you see, this contains the GUIDs of each user, the credentials, user-group mapping details, role-group mapping details etc. Lets now look at the contents of the jps-provider.xml file.

This is pretty clear from a standalone application standpoint. What if we try deploying this on to a weblogic container having BI EE. Lets now do that and see how the security artifacts merge. There are three things we need to know before migration

1. Generally Credential Store migration is done through an ANT script. The reason for this is, in our target BI EE instance, we already have a cwallet.sso file(which has BI EE specific credentials). So, we need to add these credentials instead of overwriting the file. In our case, i will bypass the ANT script process by converting the database credentials to point to an MDS data store (as against the JDBC URL) to make it simple.

2. Policy Store gets migrated automatically. The deployment process will merge the security artifacts in jazn-data.xml of the standalone application to the system-jazn-data.xml of the weblogic instance.

3. Identity Store migration again is generally not needed as we will be recreating the users/groups in the Weblogic default LDAP provider.

So, lets double click on the Application Module and then add a new Business Configuration so that the application will refer to a JNDI instead of a JDBC URL within weblogic.

Add a new configuration and make it to point to the JNDI(leave it as default). Also make this as the default configuration.

Now before deployment, create a new JDBC data source in weblogic (With the same name/JNDI as the above configuration). This is done from the weblogic Admin Console. The JNDI should point to the HR schema. This is done to avoid storing in the HR schema credentials into the Credential Store.

Now lets go to the application and then click on the Configure Security Deployment.

Let's uncheck the Credentials & Users/Groups option so that we migrate only the policy store.

We can now deploy the application directly to BI EE Cluster as shown below.

After a successful deployment, you can see that application in Weblogic as well as BI EE Enterprise Manager.

If we now navigate to the Security of this application, you can see that the new roles that were part of the application will now be appearing inside the EM.

If we now add the Weblogic user to the Role, this user will be able to navigate in the application. This entire exercise basically shows us how OPSS has been adapted by Oracle Fusion Middleware and how that has been propagated to BI EE. There are 4 roles which are pre-defined i.e. BIAuthor, BIConsumer, BIAdministrator and BISystemUser. We cannot define new policies as they are pre-defined. But we can create copies of policies (but rarely required as Policies themselves are at the lowermost grain). If we now look in the system-jazn-data.xml, we can see the new roles that have been merged.

This goes on to show that we can now make external applications run in the same JVM of the Managed Server thereby making the security management a lot easier especially when we are deploying multiple applications.

In the part 1, i have covered how the security integration works from an application perspective. In the next part, i will cover another new feature which is the integration of BI EE with ADF View Objects to provide real time reporting.