October 13th, 2011 by Ragnar Wessels
Since the release of OBIEE 11G, one of the questions asked relates to what most people consider a fairly basic bit of functionality: how can a user change his/her own password ?
The simple answer is that, out of the box, this is not (yet) supported in the 11G release, unless the user has administrative privileges on the weblogic server.
This leaves :
- Asking an administrator to do it.
- Granting more privileges on the BI stack, allowing them to log into the weblogic console and modifying the password there.
Neither of these methods is very flexible since it requires 3rd party intervention on some level to make it happen. Worse, administrative access would have to be granted to those users, defeating in large part the purpose of the security infrastructure.
One option would be to create a set of WLST scripts that, to some degree, hide the administrator credentials, but that option requires users to run scripts outside of the web front-end. It works but it’s hardly intuitive or user-friendly.
This post will explore a method that would enable users to do this themselves, directly from within Analytics, without the need to divulge any higher privileged credentials.
Since the introduction of OBIEE 11G running on weblogic an extensive API is available containing the functionality that is already present in the enterprise manager and weblogic console. Part of this is the Mbean tree that OBIEE uses to manage its configuration. This Mbean tree can be browsed using the Enterprise Manager. Each of the Mbeans in this tree relates a part of the stack and exposes methods to either get or set bits of the configuration. Of interest in this case are the Mbeans relating to the Authenticators. More specifically, in the case of a default installation, the DefaultAuthenticator linked to the myRealm security provider.
Logging into the enterprise manager gives us its exact name and exposed methods:
From here we can invoke the ChangeUserPassword method and change the password for a user.
In order to leverage these Mbean methods outside of the Enterprise Manager a simple java class can be built, using the aforementioned API.
The steps to be taken in this class are:
- create a connection to the Mbean server
- call the password change method in the appropriate Mbean
I used Jdeveloper 11G R1 for this.
So far so good. I can now change the weblogic password by calling the java class and verifying success by logging into Analytics with the new password.
In order to make this class available from within the OBIEE dashboards I’ll use a feature that was introduced in OBIEE 11G: the ability to consume web services. This is possible in 10G as well but some jiggery pokery is required to get this to work. OBIEE 11G on the other hand has this functionality by default.
First I have to expose the class as a Web Service. In order to do so I have to create a Web Service out of it and deploy it to an application server in the form of a war file. The good thing is that no additional installation or configuration is required since I already have a full fledged application server at my fingertips viz. weblogic.
A few clicks in JDeveloper later and it is deployed to the Admin server where it’s visible under the deployments:
A quick test in Jdeveloper verifies that it’s working as advertised.
Now all that remains is to create an action item, call the webservice and place it on a dashboard somewhere.
1. Create a new action item in Answers
2. Point it to the WSDL descibing my ChangePassword web service
3. Make it prettier by setting prompts, messages and a few of the other options
4. Put in on a dashboard.
And there we are. Any user can now change their password from the within Analytics, without being exposed to any administrative credentials.
To finish, this consideration:
The Web Service can hardcode the weblogic password to connect to the Mbean server. Obviously this is not ideal since, should it be used to change the weblogic password itself, the webservice would stop working. This means that the weblogic user has to be treated as the exception.
One way of dealing with this is to not use username/password authentication but rather use config- and key files to authenticate the weblogic user. The Web Service in that case would have to regenerate these files each time it’s used to change the weblogic password.
But there’s an
app API call for that.
Unfortunately we can’t send the code or make it available as it’s for a client project. But all that you need is actually in the screenshots, and it’s also documented well in the WLS docs. Sorry about this.