So it flows as : subject --> (
r1)PS --> (
r1)-PPS
- Moreover the profile has an optional policy/set to respond queries to retrieve privileges of a subject (HasPrivilegesOfRole).
- A suggestion for the enablement of a role (Role Enablement Authority (REA)) that does the association of an attribute/s to a user and enables the role activation. Here I say activation rather than assignment as the scientific literature suggests so.
Now if we sum up:
1. From the policy evaluation point of view : alice (user) is assigned two roles r1 and r2 which is stored in a table (any structure that does the mapping) so that she gets the Subject attributes of "role-r1" and "role-r2" (REA is used till now). These attributes allow her to undertake the roles r1 and r2 (RPS is used at this point). The request alice made is evaluated against the permissions available for r1 and r2 (PPSs are used here). From this point of view, it is step by step. For example, it seems like the subject attributes (role) can be cached and used for future references, instead of doing the previous steps every time.
2. From user request point of view: alice sends XACML request including the subject/resource/action (ignore the environment and consider the request as a triple for simplicity) is sent to the PDP engine. subject element is used for enablement, resource and action elements are used for the final decision. So from this point of view it as all-in-once. Every time the request is sent and a response is returned.
Of course it depends on the application domain and the particular scenario used but there should be best practice out there? So I was wondering your experiences with XACML in an RBAC setting. In the first case, there can be caching of attributes while additional measures must be taken for attribute caching. In the second case, performance would be a problem.