仁科安全
我们希望为用户提供从外部网络访问 peoplesoft 门户的权限。但是..该访问权限必须是只读的并且非常有限。
peoplesoft 是否有人做过基于位置的角色启用。即禁用所有角色并仅基于 IP 地址或 Web 服务器启用特定角色？
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 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我已经做了类似的事情，使用 DNS 条目来确定内部/外部访问。用户希望在所有用户在家中登录 PeopleSoft 时强制对其进行自助服务访问，但如果用户通过 VPN 或在办公桌上登录，则为他们提供完全访问权限。这样，高级用户将无法获得完全的安全性，除非他们通过 VPN 或在工作中进行身份验证。
我们通过自定义 USERMAINT 组件、为“自助服务”安全性创建一个新的安全表、添加自定义 Signon PeopleCode 以及设置公开供外部访问的第二个 DNS 条目来完成。
首先，网络管理员设置了两组指向 PS Web 服务器的 DNS 条目。例如，psoft.company.com 是内部 DNS，仅设置用于本地网络访问，而 selfservice.company.com 是可用于全局访问的外部 DNS。
接下来，我们定制了USERMAINT组件（User Profile）。我们隐藏了提供的角色选项卡并将其替换为副本。新页面指向 PSUSERROLE 的副本。我们这样做是因为我们希望使用提供的 PSROLEUSER 表作为“当前”安全表。如果安全管理员想要更新用户内部（或日常工作）安全性，我们希望长期存储。 （这在下面会更有意义）。因此，新的自定义表（例如 XXROLEUSER）现在是安全性主表。
然后，我们为安全管理员添加记录/页面/组件来定义“自助服务”安全性 (XXSSROLES)。该记录/页面仅存储用户外部登录时的角色名称。这允许安全管理员针对季节性变化更新自助服务安全性，例如开放注册。管理员可以在开放注册期间添加角色以授予额外访问权限，然后在该期间结束时将其删除。
最后，我们创建了一个自定义 Signon PeopleCode 步骤来处理内部/外部安全开关。 Signon PeopleCode 获取用于登录的 URL。代码解析 URL 以查看用于访问系统的 DNS 条目。如果 DNS 条目是“selfservice.company.com”，代码将清除用户 PSROLEUSER 中的行，并插入 XXSSROLES 表中的角色。如果 DNS 条目是“psoft.company.com”，则代码将清除 PSROLEUSER 并插入 XXROLEUSER 表中的角色。
此代码更改将 PSROLEUSER 变成事务表。由于工具系统依赖此表来实现许多不同的安全功能，因此创建一个副本以用作用户配置文件组件中的“主表”非常重要。
如果您有兴趣尝试此操作，我很乐意发布 Signon PeopleCode 的一些示例代码。
我将 Signon PeopleCode 函数上传到 GitHub（请参阅下面的链接）。您可以创建自定义记录来存储 PeopleCode，然后将其添加到 Signon PeopleCode 页面中。如果您需要更多信息，请告诉我。我无法发布完整的技术规范，但如果您有疑问，我很乐意为您提供帮助。
http://github.com/iveersond/PeopleTools-Dynamic-Login
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
招聘解决方案使用类似的流程 - 在创建外部候选人网关以允许申请人申请职位时，会为具有严格限制权限的特定 Web 服务器创建“访客”ID - 基本上只是外部申请人申请对象。
在 PS 9 中，查看 PeopleTools >网页简介>安全选项卡下的 Web 配置文件配置。您绝对可以在 Web 服务器级别保护系统。
华泰
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
免责声明：我在公司工作。
聚会有点晚了，但一个有用的答案：IntraSee 已经开发出来针对这种情况的解决方案。
关键是您需要能够定义规则（位置），然后将它们与特定角色联系起来。在登录时进行评估，根据规则和用户位置撤销或授予角色。它可以使用IP或其他属性来确定角色。
手动执行此操作有点棘手，因为您需要考虑用户配置文件的版本控制和相关权限。 Signon PeopleCode 是评估这些规则的最佳场所，因为您可以在每个会话中执行一次，并且您可以访问业务数据来做出相关决策。 EG 如果一个人的批准限制很大，也许他们无法远程批准，但限制较小的人可以。相同的安全访问权限，但根据位置和数据添加或撤销。
对于您的具体情况：您将拥有对这些用户具有只读访问权限的基本角色，然后是一组提供读/写权限的“选择加入”角色。当他们从正确的位置进入时，他们就会获得读/写权限。因此，我们仅在适当的时候添加额外的访问权限。
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.
我将创建一个单独的网站（如候选网关建议），它将需要与您当前使用的网站类似的网络配置文件，无需进行其他更改。
接下来创建一个自定义菜单，然后附加您希望设为只读的所有组件。
注册这些 custom_menu.components 的内容引用。
创建角色和权限列表，添加 custom_menu.components，然后选择“仅显示”。然后将角色分配给用户。
通过防火墙公开该站点。
就是这样。
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.