Monday, August 5, 2013

[OBIEE 11g] User Able To Log-In Even With Invalid (Or No) Password In OBIEE 11g





User able to log-in even with Invalid (or no) password in OBIEE 11g




With the release of Oracle Business Intelligence (OBIEE) 11g, the 'old' (read: OBIEE 10g) way of authenticating users has been deprecated, mainly - authenticating a user's credentials via the repository which i've outlined in this post . At its core, 10g authentication was accomplished using init blocks that populated the :USERS and :GROUPS session variables in the repository.

OBIEE 11g, on the other hand, authenticates via authenticators in weblogic such as Oracle Internet Directory.


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 behavior. 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.






No comments:

Post a Comment