|
Cross Site Scripting Vulnerability |
|
|
Written by Brent Martin
|
|
Tuesday, 06 May 2008 |
|
Just wanted to make you aware that there is a Cross-Site-Scripting vulnerability on the PeopleSoft Sign-In page. From my testing, this vulnerability exists in PeopleTools 8.43, 8.44 and 8.48 and 8.49. It probably exists in others going back to version 8.0, but I don't have environments to test it in. To exploit the issue, an attacker would insert Javascript code into the SignOnDefault cookie, and somehow place the altered cookie onto a victim's workstation. To me that seems pretty unlikely but I guess it'd be possible. My client considers it a high risk because the firm that audited their security considers it a high risk. I opened a case with Oracle and they were able to recreate it. A fix is due for PeopleTools releases 8.48 and 8.49 sometime in July. If you're not running PeopleTools 8.48 or 8.49, or if you don't want to wait for a fix, here's the workaround:
|
|
Last Updated ( Thursday, 12 June 2008 )
|
|
|
Understanding Portal Security Sync |
|
|
Written by Brent Martin
|
|
Friday, 27 April 2007 |
|
Everybody knows the basic security structure. It goes like this: User -> Role -> Permission List, and permission lists include Menu-Component-Pages. Before PeopleTools 8.40 that was all you needed to know to give someone access. But these days the Portal Registry provides the front-end navigation, and it maintains its own security table that has to be kept in sync. The portal registry (basically the left-hand menu navigation) is made up of folders that can contain subfolders and/or content references. Content references point to different types of content, but most of the time in your HCM, FSCM or CRM application they point to components. The portal registry security table is called PSPRSMPERM. This table defines which permission lists and roles are assigned to each folder and content reference. When you do edit permission lists on-line, PeopleCode keeps PSPRSMPERM in sync. But not so when you migrate permission lists, or when you build or update them via SQL (a technique I’ve grown to depend on). So if you migrate a new permission list into an environment, how do you get the portal registry synchronized? Well, that’s the job of Portal Security Sync. Portal security sync can be a confusing process. In this article I’ll try to make some sense of what it is, why it’s necessary, what kinds of issues you can expect, and some alternatives.
|
|
Last Updated ( Friday, 27 April 2007 )
|
|
|
Secrets of PSAUTHITEM |
|
|
Written by Brent Martin
|
|
Saturday, 07 April 2007 |
|
PSAUTHITEM is one of PeopleSoft’s core security tables. It’s primary purpose is to track which pages and authorized actions that each permission list is assigned, but it tracks web library (iScript) permissions as well. In this article I’ll talk a little about the fields in PSAUTHITEM, how you can join to other PeopleTools tables to get more information (like Component), and how to decode the elusive AUTHORIZEDACTIONS field.
|
|
Last Updated ( Monday, 13 August 2007 )
|
|
|
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
- Configure integration with Active Directory.
- Activate the Signon PeopleCode functions LDAP_AUTHENTICATION, SSO_AUTHENTICATION and LDAP_PROFILESYNCH
- Modify the updateUserProfile function to populate ELM-specific fields
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:
- User ID Attribute: sAMAccountName
- ID Type: EMP
- ID Type Attribute: employeeID
- Use Default Role: Internal_Learner
- Use Default Language Code: English
- EmailAddress: mail
- NavigatorHomePermissionList: LMLELM9030
- PrimaryPermissionList: LMLELM9070
- ProcessProfilePermissionList: LMELM9050
- RowSecurityPermissionList: LMELM0000
- UserDescription: name
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 )
|
|
|
