UML class diagram for RBAC. I don't know if the permissions and roles are properly set

I think the most obvious error in this diagram is that "Member" and "Manager" should be roles of a user, not users themselves. Hence you got the inheritance wrong.

Moreover, a user can have different roles (like being a Member and a Manager at the same time), and the same role can be assigned to different users - hence there should be an n:m relationship between users and roles. The same should probably apply for roles and permissions.

You need also make a decision whether you want to use UML just as a sketch, as a blueprint or as a programming language - in other words, which "UML mode" you want to use. Using it only as a sketch, your diagram will be probably fine after you corrected the errors I mentioned. Still, I would consider to use explicit comments to express there are certain IDs for certain objects - or you create a separate Object diagram for it. Attributes in a class diagram are intended for names of the members and their type, not for their value.

For using it as a blueprint, you may consider to build the system without explicit classes Member or Manager, since this will only be Role objects in the real system.

The core of a Role Based Access Control is to associate a User to one or several Role, each granting one ore several basic Permission, with some popular variants:

• some RBAC associate a single role to a user for the sake of simplicity. You seem to go that way
• plain RBAC often associate each permission in a role with permission parameters (e.g. categories of books on which the action can be performed). You don't seem to use this.

Taking this into account, and removing the password with a salted password hash as good security principle require, you'd have something like this (perhaps adding a layer on top of the enumeration in case your implementation language doesn't easily allow conversion of enumerations to strings, and if you need strings:

The difference between a Manager and a Member is then only defined by the roles they have at run-time. It's no longer structural. It makes no sense to model it in your class diagram, since you could add many more roles, or you could have the same roles with other names. Also, it makes no sense to hard-code what these specialisations could do on a book.

If you want to add an audit trail, you could add a class action associated to Book and User and Permission, with a timestamp.

What you have to think about is how to enforce the access control: should book check that user has the permission when the operation is performed ? should the user check the permission before operating on other objects ? Should you add a Transaction object (or use the audit trail object) to independently verify compatibility of permissions with the action performed)? This is indeed the hard nut to crack in RBAC.