| dc.description.abstract | People in an enterprise should not be allowed to simply sit down and start working with a computer; only authorized personnel should be allowed to use the computer and its applications. Furthermore, authorised users should only be allowed to access resources they need to perform their duties. Traditionally, an administrator assigns each user access rights to applications. In assigning the rights, the administrator would then grant all the necessary permissions needed for the person to complete his/her work, while preventing that person from performing any unauthorized work. Using access models such as Discretionary Access Control (DAC) and Access Control Lists (ACLs), the permissions are granted to each individual user. When granting permissions to several users over many applications, DAC and ACL quickly is cumbersome, difficult, and costly to administer. An alternative access model that resolves these issues is Role Based Access Control (RBAC). The basic premise underlying RBAC is that in order to simplify security administration, permissions are assigned to roles rather than users; a user gains permissions by being assigned to a role. Roles can be a way of defining positions in organizations, a collection of responsibilities, or perhaps representing a qualification. RBAC is a proven technique to assign permissions to users via roles. In RBAC, users can be easily reassigned from one role to another, roles can be granted new permissions for new applications as systems come online, and permissions can be revoked with regard to roles as needed. This improves scalability and offer more flexible means for administration of access control. As a means of simplifying security management and enhancing information and network security, a windows-based tool called RBACS was developed in this project, which grants access to computing resources based on a user’s role within an organization. The tool was designed using Visual Studio 2005 on the Microsoft .NET framework. The source code (Visual C) is attached in Appendix for those who might want to expand on this work. | en_US |
