Peoplesoft OPRID include in PERSON_BASIC_FULLSYNC Message - peoplesoft

Some query regarding OPRID. i want to include the oprid in the Person Basic Fullsync message. I added the record PSOPRDEFN to the Message. But i am not able to get OPRID values for all the employees. I am getting only for some employees whose user profile is present.
Is OPRID related to only for user profiles?
how can i generate OPRID for all employees??

In PeopleSoft you have persons (identified by EMPLID) as transactional data, and users (identified by OPRID) who can access the application.
Not every user is necessarily related to a person or employee (e.g., system accounts such as PTWEBSERVER, developers' accounts, etc.), and not every person or employee will have a user profile (e.g., employees without access to Self Service transactions, ex-employees who no longer work at the company, etc.).
So, to answer your questions:
Yes, OPRID is only related to user profiles (you can obviously find OPRID values used elsewehere, like in "Last Updated By" fields, security tables, etc., but it only relates to users). Often an OPRID will be linked to an EMPLID (in the PSOPRALIAS and/or PSOPRDEFN tables), but this is neither guaranteed not required.
Generating a user profile for every employee is not always warranted, as there are important security implications to it. Furthermore, if your company uses single sign-on with LDAP authentication, the users are automatically created upon first sign-on if so authorized, so proactively creating them is unnecessary and often ill-advised. Finally, it will often be a security breach to have ex-employees with active user profiles, so you may never truly reach a scenario where all your EMPLIDs have associated OPRIDs. If you've weighed all of these concerns and do indeed want to pre-populate the entire user population, you can use something like Excel-to-CI. However, note that this will solve the issue as of right now, and the moment you create a new employee you'd need to also create its user profile.

Related

Oracle APEX User Rights and Previleges

I do not have much experience and I would like to know if there is an easy way to create user rights and privileges, so that each user can access only specific records from the database tables, based on the level he belongs to.
More specifically, suppose we have a group of companies where this group has some companies and these companies have some branches and the branches have some users.
I want the user belonging to the "group of companies" level to have access to and view all the entries in the database related to that group and what is below it (its companies and the branches of these companies).
The user who belongs to the "company" level should have access and see only the files of this company and the branches that this company may have in the database.
The user belonging to the "Branch" level should only be able to access and view this barnch records in the database.
And finally the user belonging to the "End User" level to have access and see only the records created by the user in the database.
Of course level "administrator" will have access to all records in the database.
I thought of creating a user table with a field "User_Level" and in each table to enter USER_ID where based on this I can find the level of a user but how can I restrict access based on the Group of Companies or the Company or the Branch where it belongs?
In APEX you can create authorization schemes to determine what components a user has access to within an application - but that is just a part of the answer to this question. Your question is about filtering the data that is showed to a user based on certain criteria.
There are a couple of possible solutions to this. Since this is a very broad question I'm just going to give you pointers/concepts to start your research. Up to you to determine what solution/combination is most suitable for your implementation.
Concept: Multi-Tenancy
If the data is used by multiple tenants then add a tenant_id to each table that has tenant specific data. In your case a tenant should be a branch. A simple design could be a groups table (to hold branch - companies - company groups), a group_members table (to define relationship between branch - companies - company groups OR between any group and a user) and a users table.
Concept: VPD This is a feature in the oracle database that allows a transparent implementation of security rules. In the application you'll define a simple select like
SELECT * FROM emp
But the VPD implementation will automatically add a where clause to the query to only show the records defined in the VPD policy. This makes developing the application a lot easier since there is less room for errors. Note that this database option could not be included for your licence. There is also something called "Poor Man's VPD" that does not use the VPD option. Google on how to implement this in your apex application.
Just do it all by hand: This is the least preferred option but it can be done. For every component where a select is done, manually add a where clause to restrict the returned rows. However this is very maintenance intensive and there is a ton of room for errors - obiously the data model will still have to support the striping of the data.
This blog post by Jeffrey Kemp might give you some pointers as well: https://jeffkemponoracle.com/2017/11/convert-an-apex-application-to-multi-tenant/ - go through the "further reading" section at the bottom.
you can create a procedure or function and in your app's shared components -> authorization scheme use that such as pl/sql function/procedure returning boolean and return true for the users you want to see the things and false for hiding.
In Apex components, select this authorization scheme like in items, pages etc.

Is there an inherent risk in publishing other users' ids?

I have a collection called Vouchers. A user can, if they know the unique number ID of a Voucher, "claim" that voucher, which will give it a user_id attribute, tying it to them.
I'm at a point where I need to check a user's ID query against the existing database, but I'm wondering if I can do so on the client instead of the server (the client would be much more convenient because I'm using utility functions to tie the query form to the database operation.... it's a long story). If I do so on the client, I'll have to publish the entire Vouchers collection with correct user_id fields, and although I won't be showing those ids through any templates, they would be available through the console.
Is there an inherent risk in publishing all of the IDs like this? Can they be used maliciously even if I don't leave any specific holes for them to be used in?
First, in general it sounds like a bad idea to publish all user_ids to the client. What would happen if you have 1 million users? That would be a lot of data.
Second, in specific, we cannot know if there is inherent risk in publishing your user_ids, because we do not know what could be done with it in your system. If you use a typical design of user_ids chosen by the user themselves (for instance email), then you MUST design your system to be safe even if an attacker has guessed the user_id.
Short Version: not so good idea.
I have a similar setup up: user can sign-up, if she knows the voucher code. You can only publish those vouchers where the user_id is identical to the logged in user. All other checks like "does the user input correspond to a valid voucher?" must be handled on the server.
Remember: client code is not trusted.

Why not to allow changing usernames?

There are several services which allow change of usernames frequently like Twitter, LinkedIn etc. Some other have very limited options (example: Facebook for two times). And rest does not allow changing usernames.
The major reasons I can understand is, records are kept against usernames and the URL are cached by search engines against the username. But to solve the first problem, which is much vital, applications can use userid instead of username.
Is there any other important issues/reasons for which I should consider disallow changing usernames?
the main issue is social engineering. people associate a reputation with a name (both the user with the name, and the people who interact with them). if you allow names to change then there is less social pressure to preserve a good reputation and more "bad behaviour".
it's all about coercing users to invest social status in a persistent identity. technically they could implement a system that supports name changes (for example, you could use an arbitrary, unique, auto-generated ID to represent the user in the database/cache/file system and display some (user modifiable) string from the database when showing the name in a web page).
There are technical reasons behind some sites disallowing namechanges, such as if the users have the ability to store files, changing the username may break it if the file paths are based on the usernames. However, a good implementation uses user IDs instead, and avoids such things. For the most part, its a social matter of keeping a permanent link between a user's name and an account. Giving the user the ability to switch names gives other users the ability to impersonate them, or steal their name, and makes it difficult to find people sometimes.
I'd also like to note that there is a difference between login usernames, and nicknames. What you are calling 'username' is moreso a nickname if it can be changed, and usually sites that let you 'change your username' are only letting you change your display name - your login remains the same. Steam is a good example of this, it allows you to change a nickname, but your login name can never change.
I have recently came across this dilemma whether to allow user to change username.
I have entered it on my blog: http://www.dizkover.com/post/423/programming-why-not-to-allow-users-to-change-username-in-social-web-application-design

Need advice on best practice(s) for using databases in my ASP.NET website

I'm building a website that will be used by employees to log work that they've completed. The site contains a page to submit the information, a page to view the information and a page with the employees personal info like name, email, phone, etc. I'm using ASP.NET Membership for authentication. All code will be VB. My questions:
1) ASP.NET Membership only stores the username and email of members. I want to store additional information like first and last name, phone number, etc. Can I just update the tables in the membership database to include this information? Or should I store this information in a separate database? My goal is to populate text boxes on one of the pages with data specific to the user that is currently logged in.
2) The work completed will be stored in another database since it seems logical to keep it separate from membership data. What is the most efficient way to pull and display records from this separate "work" database that are specific to the user who has logged in and been authenticated against the member database?
3) I'm having trouble with the design of tables for the "work" database. Each record stored in the database will represent a days worth of work. However, a number of activities will occur during that day. Each activity will have a type of activity, location and amount of time worked. An employee can complete 1 activity or 100 activities. I assume I'm going to need a table just for the activities and then relate it to the work table. Does this sound correct?
For your first Point i will suggest you to create your own table of User and relate this table with membership user table with guid viz. keep on userid file in your table and relate it with membership table.
Second point will automatically get solved once you will create your own user table, all you need is to relate work and user table(created by you) to fetch the records from work
And at last if you are creating new table for activities how come you will relate it to your work table, again you will have multiple occurrence for record, instead i would suggest do not create another table for activities keep it in work table itself as if you are creating a new table, you will have to provide relationship with work which will result in redundancy.
Hope this helps.

Best Practices in User Privileges/Session Variables in MVC3

Hi Stack Community Members,
I am developing an application under MVC3 where users have department-specific CRUD privileges. In other words, all users can view data for all departments, but only certain users can make changes to the data for any one given department. User-department privilege data is held in a join table in a database.
What I typically do in this kind of situation (in PHP) is to create a Session variable (an array) on login which is populated with the id's of the departments which the user is allowed to edit. When a user then goes to access the editing feature a drop-down list is populated with only these specific departments. I also populate a few other session variables which are used frequently like the user's name and the id of the current time period (business quarter).
Is this type of approach a good way to go in MVC3, or is some alternative approach better? While I figure that I'm going to use Forms Authentication and some specific roles (employee, admin, etc.) these types of roles are just too broad to be able to target department-by-department access, and I'm not sure that MVC3 has an out-of-the-box method which is better than what I'm planning to do.
Your guidance is appreciated!
I'm using Forms Authentication, add specific roles, and combine them if needed. I don't mind being specific for the roles, as they can be combined anyway I want. I can still have broad roles for more general actions.
I store similar data (UserId, DepartmentId, etc) in session since it does not change for the user and it is a small amount of data. It is my opinion that session state would be a good approach for you also.

Resources