Properties of Role and Why They are Profitable to Application Database
Lively (dynamic) Privilege Management: If the privileges of a group may be altered in future, then only bother about altering the privileges of the role only. And reflect to all alteration may affect automatically to all the users.
Reduced Privilege Management: Rather than assigning the same group of privileges directs to the users one by one, instead; one can grant the privileges to a role and that Role is assigned for a group of related users directly.
Selective availability of Privileges: In any given situation DBA can enable or disable the Roles granted to a user as per database application requirement.
Application-specific security: Protect or Secure Role with the help of password. When User given the correct password, Applications can be created specifically to the Role and cannot enable the role if they do not know the password.
Secure application Role: DBA may be able to create a Role with password to disallow unofficial use of the privileges granted to the role. When application is started, it will then enable the proper Roles but does not need to know the password of the application Role.
Scope of the Role:
a) Role can be assigned to any of the Database User.
b) Role can be granted to Other Role but not granted to itself and also cannot be granted circularly. For ex. Role A can be granted to Role B, implies that Role B cannot be further granted to Role A.
c) Role can be granted System or Object both Privileges both. Also provide by oracle some default system privileges list so we can assign those privileges to user. Object privileges that allows assign to some specific table while system privileges allows global access rights.
d) Any Roles assign to user afterward no need for that privileges to User so we can easily remove those privileges from user with help of REVOKE Command.
e) If DEFAULT Roles are assigned to User than optionally, user can make a directly granted role a default role. So optionally assign Role may become default Role indirectly.
f) If Role is secure application Role or may not be password authenticated then User can assign a Role accidentally to the User. Finally, Role granted to a User through another Role that has already been granted to User previously. Let’s see Example for the Same, Role A is granted to user John. Then grant the Role B & Role C to the Role A. So now Role B & Role C is under the Role A. That means User John is in access Role A directly but access of Role B & Role C indirectly due to both Roles are under Role A.
Find more technical information about Privileges in Oracle database services.