Peoplesoft security - peoplesoft

Question

We want to give users peoplesoft portal access from outside network. But ..that access needs to be read only and very limited.
Has anyone done location based role enabling is peoplesoft.. i.e. disable all roles and enable only particular role based on ip address or web server ?

Answer 1

I have done something similar to that using DNS entries to determine internal/external access. The users wanted to force Self-Service access to all users when they logged into PeopleSoft if they were at home, but give the users full access if they logged in via VPN or at their desk. That way, power users would not have full security unless they were authenticated via VPN or at work.
We accomplished by customizing the USERMAINT component, created a new security table for "self service" security, adding custom Signon PeopleCode, and setting up a 2nd DNS entry that was exposed for external access.
To start, the network admin set up two sets of DNS entries that pointed to the PS web servers. For example, psoft.company.com was the internal DNS and only set for local network access, and selfservice.company.com was the external DNS available for global access.
Next, we customized the USERMAINT component (User Profile). We hid the delivered Roles tab and replaced it with a copy. The new page was pointing to a copy of PSUSERROLE. We did this because we want to use the delivered PSROLEUSER table as the "current" security table. If the Security Admin wants to update a users internal (or day-job) security, we want to store if for long term. (This will make more sense below). So the new custom table, say XXROLEUSER, is now the master table for security.
Then, we added record/page/component for the Security Admin to define "self service" security (XXSSROLES). This record/page just stores Role Names for when users log in externally. This allows the Security Admin to update self service security for seasonal changes, like Open Enrollment. The admin can add a role during Open Enrollment to grant additional access, and then remove it when the period has ended.
Last, we created a custom Signon PeopleCode step that handles the internal/external security switch. The Signon PeopleCode grabs the URL used to log in. The code parses the URL to see with DNS entry was used to access the system. If the DNS entry is "selfservice.company.com", the code will clear our the rows in PSROLEUSER for the user and insert the roles from the XXSSROLES table. If the DNS entry is "psoft.company.com", the code will clear out PSROLEUSER and insert the roles form the XXROLEUSER table.
This code change turns PSROLEUSER into a transaction table. Because the Tools system relies on this table for many different security functions, it is important to create a copy to use as the "master table" for use in the User Profile component.
If this is something you are interested in trying, I'd be happy to post some sample code for the Signon PeopleCode.
I uploaded the Signon PeopleCode function to GitHub (see link below). You can create a custom record to store the PeopleCode and then add it into the Signon PeopleCode page. If you need more information, let me know. I am not able to post the entire tech spec, but I'd be happy to help if you have questions.
http://github.com/iversond/PeopleTools-Dynamic-Login

Answer 2

Recruiting Solutions uses a similar process - when creating the external Candidate Gateway to allow applicants to apply for positions, a 'guest' ID is created for a particular web server that has severely restricted permissions - basically just the external applicant apply objects.
In PS 9 , have a look at PeopleTools > Web Profile > Web Profile Configuration under the security tab. You can definitely secure the system at a web server level.
HTH

Answer 3

Disclaimer: I work for the company.
A bit late to the party, but a useful answer: IntraSee has developed a solution for this exact situation.
The key is that you need to be able to define rules (locations) and then tie those to specific roles. Evaluated at login, the roles are revoked or granted depending on the rules and user location. It can use IP or other attributes to determine roles.
To do this manually is slightly tricky as you need to account for the versioning of the user profile and associated permissions. Signon PeopleCode is the best place to evaluate these rules as you can do it once per session, and you ahve access to the business data to make correlative decisions. E.G. if a person has a huge approval limit, maybe they can't approve remotely, but someone with a small limit can. Same security access, but add or revoked based on location and data.
To your specific case: you would have base roles with read only access to those users, then a set of 'opt-in' roles that gave read/write. When they come in from the correct location, they get the read/write. So, we are only adding the extra access when appropriate.

Answer 4

I would create a separate site ( like the candidate gateway suggestion ), it will need a similar web profile as the one you are currently using, no other changes would be necessary.
Next create a custom menu, then attach all of the components you wish to make read-only.
Register the content references for those custom_menu.components.
Create Roles and Permission Lists adding the custom_menu.components then select "Display Only". Then assign the roles to the users.
Expose that site via the firewall.
That's it.