With both IDM 4 Advanced and Standard Edition, Self-Service Password reset is available to end-users who forget their Novell eDirectory password. Assuming that you are synchronizing the eDirectory/Universal Password as is to connected systems with IDM drivers (aka Integration Modules), life is good, so you can extended Self-Service Password Reset to connected systems.
In Reality, it is natural to synchronize Universal Password with systems like Active Directory, but how about systems that don’t support the AD complexity? So in reality, we often end up with multiple passwords for each user, even if in theory we could synchronize all those passwords to the same value.
We will briefly discuss 2 approaches, one for when you have Advanced Edition or RBPM (and workflow support) and one when you don’t.
1- When you have IDM 4 Advanced Edition.
Well, that one is easy (now). If you fire up Designer, and create/edit a Provisioning Request Form, you will notice a new Form Control of type Password. So you can create a No Approval workflow (aka a Form) that allows the user to input a new password for a specific system, and you associate this field with an eDirectory attribute (through DAL) that you use at the driver level to reset the password on one or more connected system(s). You can get creative here, and use a Web Service call (Integration Activity) if your connected system or application is a Web Service endpoint that supports password resets.
2- When you have IDM 4 Standard Edition, or IDM 3.x without RBPM
I will now describe one way to custom add support for Application Password (aka Secondary Password) Self-Service Reset within User Application.
First, you need to extend the schema. Create an Auxiliary Class that contains an attribute, e.g. MyAppPassword, of type Case Exact String.
Second, Create a Standalone JSP that allow a user to Authenticate using LDAP, and Modify the value of MyAppPassword, then deploy on JBoss(if you are using JBoss to run User App).
Third, login to User App as portal admin account, go to Administration, Page Administration, create a new page, Select Content, then add iFrame portlet (don’t require authentication) that points to your JSP.
Now, a User who is authenticated in User App can access this Application Password reset page. With the config I used, the user must re-authenticate, but that can be presented as a security feature before submitting a password reset to an application. Of course, it is expected that one or more driver(s) will pick-up the new value for MyAppPassword and propagate the new password to the connected system(s).
Figure 1: Deploy war containing JSP to JBoss server.
Figure 2: Create new Page, then Select Content.
Figure 3: Use iFrame Portlet, and provide URL for JSP.
Figure 4: Login as a regular user(with modify rights to MyPasswordApp attribute).
See the new item in Navigation Bar.
Figure 5: JSP Form for resetting the password.
A Validate button has been added to check new password vs application specific complexity rules(defined in JSP). I have also included error support for login credential.
That’s it. This is a quick and dirty way to add support for a Secondary Application Password to Self-Service in User App, and customization is performed in the JSP itself. Of course, using IDM 4 AE and the new Password Control would provide a cleaner and evolvable solution (iFrame Portlet may go away in future releases), but as a quick temporary solution, this may do the job.
You can download and edit the war file containing the JSP below.
The MyApp.zip file also includes the JSP. You can customize the JSP, replace the one if the war, and deploy to a J2EE server.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.