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.
