Responsibilities can now be considered a special type of role that represents the set of navigation menus contained within an application. Therefore, responsibilities loosely represent an application itself, whereas roles can be used to determine what parts of that application (and data therein) a user has access. This represents a shift in the definition of a responsibility in Oracle Applications. Previously, a responsibility has been used not only to define the application navigation menus, but also to confer privileges and permissions within that application. Using this definition of responsibility, it was often necessary to create several similar responsibilities in order to effectively carve out data and functional security access for a group of users. This has increased the overall cost of ownership as the number of responsibilities has grown.
Oracle Applications follows the Role Based Access Control (RBAC) Reference Model (ANSI INCITS 359-2004) definition of a role as "a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role." Roles can now be defined to determine what applications (responsibilities) as well as what data and functions within those applications a user has access to.
By leveraging the RBAC model, users will no longer need to be directly assigned the lower level permissions and responsibilities, as these can be implicitly inherited based upon the roles assigned to the user. Roles can now be defined to consolidate responsibilities and other roles through role inheritance, as well as lower level permissions (functions) and data security policies. This is accomplished through a one-time setup, where all the permissions are assigned to the role. In order to make a mass update in a production system a client only needs to change the permissions or role inheritance hierarchies defined for a role, then all of the users assigned to that role will instantly inherit the new permissions.
Oracle Applications follows the Role Based Access Control (RBAC) Reference Model (ANSI INCITS 359-2004) definition of a role as "a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role." Roles can now be defined to determine what applications (responsibilities) as well as what data and functions within those applications a user has access to.
By leveraging the RBAC model, users will no longer need to be directly assigned the lower level permissions and responsibilities, as these can be implicitly inherited based upon the roles assigned to the user. Roles can now be defined to consolidate responsibilities and other roles through role inheritance, as well as lower level permissions (functions) and data security policies. This is accomplished through a one-time setup, where all the permissions are assigned to the role. In order to make a mass update in a production system a client only needs to change the permissions or role inheritance hierarchies defined for a role, then all of the users assigned to that role will instantly inherit the new permissions.
No comments:
Post a Comment