SSO password push to another database

Question

We are about to enforce password expiration times at our company, which as of now we do not use. Currently, when a user chooses to change their password, we have modified the link to point ot a procedure which first updates the SSO password using calls to the DBMS_LDAP package, and then reaches across a db link to a stored procedure on another oracle database which issues an "alter user ... identified by ..." command to sync the passwords in that database.
This isn't an issue currently because without a password expiration change being enforced, user only change passwords through the Portal app. However, now that there is an expiration warning involved, the user is prompted to change their password at the SSO level before they are authenticated into Portal. The form which handles this is
$ORACLE_INFRASTRUCTURE_HOME/j2ee/OC4J_SECURITY/applications/sso/web/jsp/password.jsp
Looking at this file, I wasn't able to come up with what it might be calling so I would know what to modify. Any ideas?

Answer 1

AMN wrote:
1. Do you change passwords for portal users in the SSO or for the schema users in the DB?
a. alter user SOMEONE idetified by SOMEPASSWORD works for db schema users. and you do not make a schema user for each portal user; or do you or have you? Portal users are different from the schema users.
2. In all of 10g Portals, you can change passwords for portal users by directing them to a default Change Password utility in the oiddas (oid delegated administration service/ self service console) which is accessible at http: //yourdomain.com:7777/oiddas. (use this port number).
3. for a custom change password utility for your company, explore DMBS_LDAP packages for changing user password attributes in OID.
4. this above file (password.jsp) is mentioned in the deployment specific pages that you can write for your own custom application. these pages are login, change password and logout pages. for that purpose, read the chapter given in this link. basically, you write your own pwd.jsp in the change pwd page and mention it in the sso.properties.
1> Yes, we do create schema users for each Portal user. The home-brew Java apps hook into the db directly. The portal offers a framework for accessing the cgi scripts.
2> True, but this will not push password changes to the schema users.
3> We have a custom change password procedure which first does all the DBMS_LDAP stuff, and then calls a procedure across a DB link to do the ALTER USER ...
4> Actually I found this which outlines a method for modifying the INFRASTRUCTURE_ORACLE_HOME/sso/conf/policy.properties file to point to custom login/password URLs. While we're already using a custom login (not through this framework though I'm thinking of adopting it now that I know it exists), I created a custom password change file based on the password.jsp which doesn't allow them the option of changing their password and simply tells them "your password is about to expire" or "has expired" and then allows them to click OK to be shuffled into the main framework of Portal where they will be back into our customized solutions. It works to our needs, and from what I can tell, further customizations would require changing the ChangePwdServlet, which is way out of bounds.
Just for background, this portal environment was set up in 2007, and I inherited it here at this company when I joined 6 months back as a DBA. I've not worked with it before and in that time I've got he basic admin stuff down and have staged Production to a new test environment with new hosts/ips (kind of a tricky process as I would learn). As I'm learning, not all the customiztions are outlined in the documentation and some that are can be difficult to find, which is why in this area OTN has been a great help. Especially when trying to understand how to generate the site2ptoken for the new staged environment.
I appreciate all the responses on these threads.
PS> To address another comment, as part of this password strength initiative I did learn about the OID plugin framework for passwords. I had to, since the OID options out-of-box aren't strong enough to meet our security requirements. With that in place we get functionality for testing for password similarities and special chars.
Edited by: athompson88 on Jun 19, 2009 6:49 AM