AUTHENTICATION ... 2
Step 1:Set up your LDAP server... 2
Step 2: Set up your username... 4
WRITEBACK REPORT ... 8
Step 1: Table structures... 8
Step 2: Import Tables into BI Admin. ... 9
Step 3: Creating the custom Message ... 11
Step 4: Create the writeback report... 13
Step 5: Clean up table ... 17
Using the Write Back Report ... 18
AUTHORIZATION: Setting the Group for each user ... 21
Step 1: Create the Session Variable ... 21
Step 2: Create the Data Source ... 23
Step 3: Edit the Target Data... 26
Step 4: Execution Preference ... 27
USING AUTHENTICATION ... 28
This entry will discuss how to utilize OBIEE 10g capabilities to authorize and authenticate your users. Authentication will be administered by an external LDAP solution, while authorization will be controlled in the datawarehouse and administered using writeback capability.
AUTHENTICATION
Step 1:Set up your LDAP server.
In the admin too go to Admin Security Action New LDAP Server
Enter all the appropriate information in the General Tab.
On the Advanced tab, if you are using MS AD, then the default UserName attribute should be sAMAccountName. Otherwise, check with your LDAP Admin.
Step 2: Set up your username
Manage Variables
Go into Session Initialization Block.
There should be an init block called Authentication. Open this. If this does not exist, create it.
Click Edit Data Source to open the data source window. From the data source drop down, select LDAP. Click Browse. This will show all of the LDAP servers that you have set up. Select the appropriate one.
Once the Data Source is set, click the Edit Data Target Button. This will open the Variable Target Window. Click New. Here, you want to create a new variable, called USER. This is a special variable in OBI Admin. Once the variable name is entered, Click OK, to get back to the Variable Target Screen.
Here you want to enter the LDAP username variable. In our case it is sAMAccountName. Click OK.
Your user authentication is now being administered by the LDAP server.
WRITEBACK REPORT
Step 1: Table structures
Nothing really needs to be done to the admin tool, aside from making sure the tables you need are imported. I created 2 tables. One was a dimension table, in case we want to store user information (full name, email, etc)
CREATE TABLE "OLAP_DW"."USER_AUTH_DIM"
("PRIMARY_KEY" VARCHAR2(200 BYTE), constraint user_auth_dim_pk Primary Key (PRIMARY_KEY));
insert into user_auth_dim values ('X');
For now, I populated this table with ‘X’ and then populated the foreign key in the
security table with ‘X’ as well. In a real life scenario, the user auth dim table might have the username as a PK, then full name, email, DOB, or other useful information. For this exercise, I just wanted to include a dimension table, s don’t read too much into the contrived way that the tables are joined. If you were building this to solve a real authentication and authorization problem, it would look much cleaner.
The other table was a table that stored security information:
CREATE TABLE "OLAP_DW"."USER_AUTH"
( "USERNAME" VARCHAR2(200 BYTE),
"USERNAME2" VARCHAR2(200 BYTE),
"RESPONSIBILITY" VARCHAR2(200 BYTE),
"FOREIGN_KEY" VARCHAR2(10 BYTE),
constraint user_auth_pk Primary Key (USERNAME), constraint user_auth_fk Foreign Key (foreign_KEY) references user_auth_dim(primary_key));
This Table should be populated with your users, and their responsibilities. For example:
insert into user_auth values ('MAKARBM', 'MAKARBM', 'GLUSER', 'X');
You will also need to add a null value record into the table. This is so entries can be added into to the write back report.
insert into user_auth values ('USERNAME', NULL, NULL, 'X');
You’ll see why the two username fields re necessary once we start to update this table through the application.
Step 2: Import Tables into BI Admin.
Import the tables into the BI Admin tool. The primary key in the user_auth table is
“USERNAME”, in the USER_AUTH_DIM table, it is “PRIMARY_KEY”. The
“FOREIGN_KEY” in the user_auth table is a foreign Key. Then, create the physical joins in the BI Admin tool.
The defaults for the connection pool should allow for write back as long as the username you are connecting with has write privileges to the tables you will be writing back to.
Also, you should make all the tables that you are writing back to non-cacheable. Writing stale data back to a table is probably not the best idea.
Create a business model and the same joins.
Finally, pull these objects into a presentation layer so they can be seen as a subject area.
Step 3: Creating the custom Message
Create an XML file similar to the following:
<?xml version="1.0" encoding="utf-8"?>
<WebMessageTables xmlns:sawm="com.siebel.analytics.web/message/v1">
<WebMessageTable lang="en-us" system="WriteBack" table="Messages">
<WebMessage name="UserAuth">
<XML>
<writeBack connectionPool="Connection Pool Olap">
<insert>INSERT INTO USER_AUTH VALUES('@{c0}', '@{c0}', '@{c1}', 'X')</insert>
<update>UPDATE USER_AUTH SET RESPONSIBILITY='@{c1}' WHERE USERNAME='@{c0}'</update>
<postUpdate> commit </postUpdate>
</writeBack>
</XML>
</WebMessage>
</WebMessageTable>
</WebMessageTables>
Everything Highlighted above can be changed to match your individual report.
Everything else should stay the same.
<WebMessage name="UserAuth">
You can set UserAuth to anything. It does NOT need to match system name or the report name. You will use this later to let the report know how it should write back to the tables.
<writeBack connectionPool="Connection Pool Olap">
Connection Pool OLAP is the name of my Connection Pool in the BI Admin tool. Make sure the name of your connection pool is unique within your Physical Layer.
<insert>INSERT INTO USER_AUTH VALUES('@{c0}', '@{c0}', '@{c1}', 'X')</insert>
The insert attribute should hold the SQL for your insert statement. This will fire when the where clause of your update statement finds a null value (which is why we need 2 username fields in our auth table). The values it will insert refer to the values of the report. We will find these when we create the report, then come back to this file later.
<update>UPDATE USER_AUTH SET RESPONSIBILITY='@{c1}' WHERE USERNAME2='@{c0}'</update>
This is how the report will update a specific field.
**If either INSERT or UPDATE needs to be left blank, make sure to put a space between the tags, as in “<update> </update>”, NOT “<update></update>”
<postUpdate> commit </postUpdate>
If your system down not auto commit after an update, this line will cause the system to perform an explicit commit.
Save this file as “anything”.xml in the “OracleBI\web\msgdb\customMessages” directory
Step 4: Create the writeback report
Log into OBIEE with a username that has access to the Subject Area created for user authentication. Click Answers, then select the Subject Area you just created
Create a report using the USERNAME2 and RESPONSIBILITY fields
Go to the results page, and click on the write back button
The write back box will open. Click the enable write back check box. Template Name will be the name you entered before in the custom message file. In our file above we used: <WebMessage name="UserAuth">, so in this case, UserAuth. Once write back is enabled on a report, the results view changes.
There is now a C0 and C1 in the upper left hand side of each column. Go back into your custom message file, and enter these in the update and insert commands. In the custom message file above, they are already correct. Make sure to enclose the variable in single tick marks if it is a string (ex: ‘c0’). For example, our update clause should be:
UPDATE USER_AUTH SET RESPONSIBILITY='@{c1}' WHERE USERNAME='@{c0}'
The last thing you need to do before saving your report is to enable both fields to be write back fields. Click on the edit column format for each field and change the Value
Interaction to write back in the column format tab.
Finally, the users that need write back capability should be granted the privilege. Go into settings Administration Manage Privileges
At the very bottom of the page, grant the appropriate access, Write Back to Database, to anyone who needs it.
Step 5: Clean up table
For clean up purposes, add this to the table CREATE OR REPLACE
TRIGGER USER_AUTH_DELETE AFTER UPDATE ON USER_AUTH
REFERENCING OLD AS old NEW AS new BEGIN
DELETE from USER_AUTH where responsibility is null and username2 is not null;
END;
Now, when the Responsibility is deleted, the entire row will be deleted on update.
Using the Write Back Report
To create a user, just enter the name in the null field along with the responsibility and hit update.
To modify a user, just change the responsibility field and hit the update button
To delete a user, we can make the responsibility field null. Because of the trigger we set on the user_auth table, this deletes the record.
Once the field is deleted, hit the update button to see the results.
AUTHORIZATION: Setting the Group for each user
So far, we have users being authenticated by LDAP, and we have a report that will let Administrators control what group users belong to.
We need to make sure a few things are complete before that is possible
1) Usernames that will be controlled by LDAP need to be removed from the Admin security manager.
2) Roles need to be created in the Admin tool, and groups need to be created in the presentation layer.
3) The Responsibility and Usernames should be entered into the user_auth table.
The responsibilities entered in the table need to match the Role created in the Admin tool AND the group created in the presentation layer.
Step 1: Create the Session Variable
In the Admin tool, go into Manage Variables.
There should be an authorization block already available from the pre-built. If there is not, create a new init block, and call it Authorization.
Step 2: Create the Data Source
Click on Edit Data Source. From the Data Source type dropdown, select Database, and enter the query seen below in the Default initialization string text box.
Next to Connection Pool, click Browse. From the pane on the left, select the correct connection pool to user for the query.
Once complete, the init block data source should look like this:
You will not be able to test this query, since it relies on a run time variable. If there is a concern that this is not working correctly, hard code :USER to a specific value (in our case MAKARBM, and test. This will ensure that your connection information, table, and field names are all correct.
If this is tested, the query should return two fields. The first is variable name. The second is the correct value. This query returns the value “GROUP”, and the value found in the responsibility field. Click OK.
Step 3: Edit the Target Data
This brings us back to the Init Block Screen. We need to Edit the target data so that it is set to row_wise initialization. Row wise initialization takes the first field as a variable, and assigns the value found in the second field to that variable. Remember in the Authentication, we created a USER variable. Here, the GROUP variable is created on the fly.
Another important point here is that the :USER and :PASSWORD variables are the only variables that can be reference this way. These refer to the USER and PASSWORD that the user entered upon login. Normally, variables are referred to as
VALUEOF(NQ_SESSION.USER), where USER is the variable.
Step 4: Execution Preference
Finally, we want to set the Execution Preference. Click the edit execution preference button, and add a new initialization block by clicking ADD. Then select an init block that should be executed before this one. In our case, we want the authentication block to be completed before the authorization block is complete.
.
USING AUTHENTICATION
Now we can log into OBI. This is what the USER_AUTH table looks like.
The GROUP Variable will take in all the groups listed, separated by a semicolon.
Now when log in as MAKARBM, I see the the following listed in “My Account”
It picked up GLUSER, but not GLADMIN. That’s because I never added GLADMIN as a group. If I update the User Auth Table:
Then login again, I see both Groups are attributed to that username
