OBIEE 11g, on the other hand, authenticates via authenticators in weblogic such as Oracle Internet Directory. This guide actually covers OID authentication in OBIEE 11g .
The OBIEE 10g method for authentication still exists in 11g, and unfortunately it is still possible to configure 11g init blocks so that the query does not check the password of the user.
For example:
SELECT USER_ID FROM USERS WHERE USER_ID = ':USER'
would just check the user id and not the password was correct but not check the password. In a scenario where such an INIT block exists and is set to act as an authentication block, this can lead to users being able to log in with any (or no) password. It can also lead to some apparently odd/inconsistent behaviour. Consider the scenario where Users A and B both exist in OID which is set as the primary identity store. But User B also exists in a database which is referenced by an INIT block as described above. Both try to login using the wrong password. User A will simply fail. However, while User B will fail Authentication against OID, because the BI Server knows there is an Authentication INIT block set, it will then attempt to run that for each of them and in the case of User B, because their username is in the USER_ID column of the USERS table, they will be allowed in as the INIT block query apparently succeeds, even though it does not in fact correctly check the user’s password.
There is no 'fix' for this other than to force username validation for init blocks that use the :USER block or completely avoid using the :USER session variable.
Oracle has acknowledged this in security document 1359798.1
keywords: OBIEE 11g security, data level security, initialization blocks, USER session variables, weblogic authenticators,
We are using 10g and would want to know if we have to give the users the Standalone url - how can we allow them using their correct password?
ReplyDelete