Role-Based Access Control (RBAC)
GW IT is transitioning to Role-Based Access Control (RBAC) to tailor account access over the next 24 months. RBAC assigns permissions to roles, not individuals, enhancing security and compliance. It offers better monitoring and auditing, improving university operations. RBAC is a leading practice used to ensure access to sensitive information and resources is properly controlled.
In Spring 2024, GW IT completed a RBAC pilot with Human Resource Management and Development (HR). Based on its success, we’re launching a campus-wide RBAC initiative, expanding the rollout to roles that require Banner admin access. The rollout will be phased by department. The next phase will focus on student roles, as well as continue to expand the HR roles from the pilot.
Partnering with campus departments is key. We’ll engage stakeholders for the departments to communicate the initiative, establish timelines and ensure testing, adoption and compliance. We will share updates about the progress and provide additional details as information becomes available.
Implementation Phases:
- Planning: Document and define roles and access requirements.
- Configuration & Testing: Review and approve new roles and access simulations.
- Implementation & Deployment: Finalize documentation and monitor access changes.
This collaborative effort ensures a smooth and efficient implementation of RBAC.
RBAC in Action
RBAC Key Components
Roles
These are defined based on job functions within an organization. For example, roles could be “Admin,” “Editor,” “Viewer,” etc.
Permissions
These are the actions that can be performed within the system, such as “read,” “write,” “delete,” etc.
Users
These are the individuals who need access to the system. Each user is assigned one or more roles.
How it Works
Define Roles
Determine the different roles needed in the organization and what permissions each role should have.
Assign Permissions to Roles
Link the necessary permissions to each role.
Assign Roles to Users
Assign users to the appropriate roles based on the level of data access needed.
Example
Enabling role based access control for a document management system may include the following roles and permissions:
Admin: Can create, read, update, and delete any document.
Editor: Can create and update documents but cannot delete them.
Viewer: Can only read documents.
In this system, if a new employee joins as a content writer, they might be assigned the “Editor” role, giving them the permissions needed to do their job without granting unnecessary access.
Benefits
- Simplifies Management: Easier to manage permissions by roles rather than individual users.
- Enhances Security: Reduces the risk of unauthorized access by ensuring users only have the permissions they need.
- Scalability: As the organization grows, new roles and permissions can be added without overhauling the entire system.
Questions & Feedback
- If you have questions or feedback about this change, please share them with us by submitting the technology feedback form, and a member of the project team will be in contact with you.