Roles and Permissions
After a role is created, you can then associate permissions with it and create grants to it for individual users. For example, for the associated application to execute properly, grant update permission to all payroll tables for the update_payroll role. For details, see Object Permissions.
When you grant an object permission or a subject privilege to a role, you are, in effect, granting that same permission or privilege to any session that is started using that role.
Specifying Role ID at Session Startup
When starting a session, you must specify a role identifier, which puts into effect the associated permissions and subject privileges. For example:
• On the –R flag for many system commands. For details, see the Command Reference Guide.
• With the CONNECT statement as part of an application.
• For an application image as part of the connection profile for an OpenROAD session. For more information, see online help for the Create Connection Profile dialog in OpenROAD.
For the DBA or a user (such as the system administrator) who has the security privilege, neither role identifier nor password is validated. For any other user, the specified role must exist, the user must be granted permission to use the role, and any required password must be specified correctly; otherwise, the connection is refused.