| Auto Create User Profiles |
|
| Thursday, 02 November 2006 | |||||
|
One of my clients is implementing Enterprise Learning Management, and all employees are potential users. We were trying to figure out the best way to set all users up and keep them up to date. What it came down to was to either 1) load all users from HRMS with the userexport/userimport data mover scripts and keep them synchronized using the the USER_PROFILE EIP, or 2) interface with Active Directory and create a default user profile the first time they logged on. After some consideration, we decided that the USER_PROFILE EIP wasn't the best option because roles in HRMS didn't necessarily apply in ELM, and it brought up questions about where user maintenance would be performed. So we decided to create a default user profile the first time a user logs on by interfacing with Active Directory and using Sign On PeopleCode. We needed to create user profiles the first time a user logs on, regardless of how they enter the ELM application. There are two ways: 1) Click the link from Enterprise Portal (using PeopleSoft SSO); and 2) Enter their network ID and Password from the ELM sign-on page (using LDAP authentication). Here's basically how it will work: When a user signs in using either method, PeopleSoft will attempt to log the user in. If it fails because there is no user profile for the user, the SSO_AUTHENTICATION or LDAP_PROFILESYNCH functions (depending on the logon method) will call updateUserProfile() to create a new profile based on information in Active Directory using defaults and mappings we set up in the user profile map. Here were the steps to get it set up:
Set up Single Sign On between Enterprise Portal and ELM First we want to be sure that users can log on to Enterprise Portal and get into ELM without entering a password (as long as the user exists in both places). Basically you simply set up PeopleSoft Single Sign on between the applications, and there are three simple steps that you've probably already done when you installed ELM: In Enterprise Portal, go to Integration Broker > Node Definitions (actual navigation depends on tools release) and pull up the Enterprise Portal Default Local Node. Make sure Authentication Type is set to Password, and it has a password assigned to it. In ELM, go to Integration Broker > Node Definitions (actual navigation depends on tools release) and pull up the Enterprise Portal Default Local Node. Set the Authentication Type to Password, and enter the same password that the node is using in the Enterprise Portal application. Also in ELM, go to Peopletools > Security > Security Objects > Single Sign On and enter the Enterprise Portal Default Local Node that you used in the previous step. Set up your directory configuration I'm not going to spend a lot of time on this topic right now, but Tom Lenz has a great red paper on Customer Connection called LDAP Authentication with PeopleTools that provides as much detail as you'll ever need. Suffice to say you'll need to Configure the Directory, run the Cache Directory Schema, and set up an Authentication Map. After you activate the LDAP_AUTHENTICATION Signon PeopleCode, you should able to log on with your network ID and password. The User Profile Map allows you to map attributes in your directory to fields on the User Profile. We mapped Active Directory to our user profile like this:
One thing I might point out: If the EMP ID type isn't activated, navigate to PeopleTools > Security > Security Objects > User Profile Types. Open the EMP User Profile Type. Check the Enabled box and click Save. Activate the Signon PeopleCode functions LDAP_AUTHENTICATION, SSO_AUTHENTICATION and LDAP_PROFILESYNCH Once your directory is set up and the user profile to active directory mapping is done, activate the Signon Peoplecode functions. LDAP_AUTHENTICATION takes the username and password from the sign in screen and authenticates it against your directory server. If authentication is successful, it signs you in as the xxxxx on the user profile map. SSO_AUTHENTICATION will create a new user profile for first time users who use PeopleSoft Single Sign On functionality to log in -- for example users who click a link from PeopleSoft Enterprise Portal. LDAP_PROFILESYNCH will create a new user profile for first time users who log in by entering their network credentials and are authenticated by the LDAP_AUTHENTICATION function. To activate, go to PeopleTools > Security > Security Objects > SignOn PeopleCode. Click the check box next to them. Be sure to click the Exec Auth Fail checkbox next to the LDAP_AUTHENTICATION to be sure it gets called even if the sign on fails. Also, users who have never logged on have no rights in the system, so you'll need to change the Run As a the top of the screen to run as a predefined user. I pick a generic service account with a strong password to run as. Make a mental note that if you ever change this service account password, you'll have to change it here too. Modify the updateUserProfile function to populate ELM-specific fields All of the functions you're activating can be viewed and edited in Application Designer. You can see the record name, field name, PeopleCode name and function name right there. So just pull it up in App Designer and you'll be ready to customize! Well, as long as you have the correct definition security to edit a PeopleTools object anyway. Also, be aware that any changes you make here can be wiped out during your next PeopleTools upgrade, so document your changes carefully. The updateUserProfile function is good but probably won't meet all of your needs. We made two customizations to this code. 1) In ELM, we needed to create a relationship between the Leaner ID and the Operator ID in the PS_LM_LEARNER_OPRID table. To do this, I had to add a SQLExec to get the learner ID based off of the Employee ID stored in PSOPRALIAS and do the insert. 2) We hard-coded some logic to assign an additional Manager role to anyone who had any direct reports. Yes, I could have used a dynamic query role or ldap role, but query roles require a job to be run to update them and ldap roles require manager information to be stored in the directory (which wasn't the case). An SQLExec seemed to be the most efficient way to accomplish this. That's the process in a nutshell. This approach certainly would work for just about any PeopleSoft self-service application. If you have any questions or if there's something I missed, please leave a comment.
|
|||||
| Last Updated ( Thursday, 02 November 2006 ) | |||||
| < Prev | Next > |
|---|