Hi,
We are looking into System Privileges and wondering what the IMPERSONATE USER privilege does and how to use it.
Using Apps 9 UPD 14.
Many thanks,
Matthew
Solved
IMPERSONATE USER
Best answer by CallumW
Matthew wrote:
Hi
So there are two elements to this - permission sets and profiles.
In order to test out permissions, I simply suggest just having a test user which you can use and change the permissions of as and when you need to. (To copy an existing user’s permission sets)
This way you can copy the users permissions to it and log into the system and have a look to check their permission sets give the correct level of access
The other side is the profile side - You can either copy the users profile to the test user profile or change the profile to the current logged in user (Tools → Options → User Profile Tab → Edit Personal Profiles → Select User and Read Only) to check if they have changed a setting in their profile
Alternatively just maintain another database and then change the user password in that environment and log into that one and test using their account
Impersonate User won’t be useful for what you are trying to do - this is mainly used to post background jobs as a different user or to perform actions as a different user (such as approval routings etc) - impersonate user will not let you log in as that user to “see what the user can see”
But if you still wanted to understand how to use the IMPERSONATE USER privilege, here is some code provided by
begin
Dbms_Output.put_line('Session user: ' || Fnd_Session_API.Get_Fnd_User);
IFSAPP.Fnd_Session_API.Impersonate_Fnd_User('NEW_USER_ID');
Dbms_Output.put_line('Session user changed to: ' || Fnd_Session_API.Get_Fnd_User);
-- run the job
IFSAPP.Fnd_Session_API.Reset_Fnd_User;
Dbms_Output.put_line('Session user reset to: ' || Fnd_Session_API.Get_Fnd_User);
end;
+18Hi
The privilege allows the authenticated user the possibility to impersonate (run as) some other user. This is a very high privilege and should be used with care.
Hope this helps!
https://www.linkedin.com/in/himashaabeywickrama
1 person likes this
Hi
+20HI Matthew,
As per the F1 documentation
IMPERSONATE USER : Allow the authenticated user the possibility to impersonate (run as) some other user. This is a very high privilege and should be used with care.
There are inbuilt permission sets which has been granted with this privilege.
Eg: BA_BARS_ADMIN
Here is a use case which might help you understand the usage: (This explains why the permission FND_ADMIN has been granted with the IMPERSONATE USE system privilege)
The reason why the FND_ADMIN permission set contains the IMPERSONATE USER privilage is so that the IFS System Administrator who is granted this permission set is allowed to perform some framework functionality that they would normally not be allowed to do if they were not granted this system privilage.
For example, one place the IMPERSONATE USER privilage is used is with backgound jobs. In a situation where an IFS System Administrator wants to run background jobs which have gone to an error or warning state, they must have the IMPERSONATE USER privilege to run the background job as the posted user.
We have seen that application groups also have used this functionality.
Hope this helps.
Thanks,
Kasun
Kasun B - https://www.linkedin.com/in/kasunbalasooriya/
+15
Matthew wrote:
Hi
So there are two elements to this - permission sets and profiles.
In order to test out permissions, I simply suggest just having a test user which you can use and change the permissions of as and when you need to. (To copy an existing user’s permission sets)
This way you can copy the users permissions to it and log into the system and have a look to check their permission sets give the correct level of access
The other side is the profile side - You can either copy the users profile to the test user profile or change the profile to the current logged in user (Tools → Options → User Profile Tab → Edit Personal Profiles → Select User and Read Only) to check if they have changed a setting in their profile
Alternatively just maintain another database and then change the user password in that environment and log into that one and test using their account
Impersonate User won’t be useful for what you are trying to do - this is mainly used to post background jobs as a different user or to perform actions as a different user (such as approval routings etc) - impersonate user will not let you log in as that user to “see what the user can see”
But if you still wanted to understand how to use the IMPERSONATE USER privilege, here is some code provided by
begin
Dbms_Output.put_line('Session user: ' || Fnd_Session_API.Get_Fnd_User);
IFSAPP.Fnd_Session_API.Impersonate_Fnd_User('NEW_USER_ID');
Dbms_Output.put_line('Session user changed to: ' || Fnd_Session_API.Get_Fnd_User);
-- run the job
IFSAPP.Fnd_Session_API.Reset_Fnd_User;
Dbms_Output.put_line('Session user reset to: ' || Fnd_Session_API.Get_Fnd_User);
end;
Callum Wells - https://uk.linkedin.com/in/callum-wells
+18Nick
1 person likes this
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.