Axiomatics provides an authorization policy lifecycle that will help you formulate your ABAC policy.
- Define the use case
- Define the use case’s authorization requirements in natural language statements
- Identify the attributes that are used in the natural language statements
- Identify where the attributes comes from
- Rework the natural language statements as attribute-based rules
- Define the test cases
- Connect the dots: draw an architecture diagram of the overall system
Let's work through your example.
One online book-store wants to grand access to clients regarding their subscription. There are 3 types of subscriptions A , B and C.
- Customers get access in the subscription type they choose.
- If a book is not listed in the subscription list it's free for all.
- Every 15th of every month all books are free.
- User role e.g. customer
- User subscription plan e.g. A, B, C
- Optionally customer status (active, inactive)
- Book subscription plan
- Action id e.g. view, delete, approve...
- Date / Day of the month
Identify the source of the attributes
In this stage you define whether the attributes come from a database, an LDAP, a web service... This is more of an implementation / deployment concern. In this theoretical exercise, you can skip this step.
Rework the natural language statements as attribute-based
- A user with the role == customer can do the action == download on an object of type == book if customer.subscription == book.subscription
- A user with the role == customer can do the action == download on an object of type == book if book.subscription == ''
- A user with the role == customer can do the action == download on an object of type == book if date.day == '15'
In conclusion it means your RBAC model needs a single role, customer.
You can use the ALFA language to model your policies and convert them into XACML, the eXtensible Access Control Markup Language.