My company is looking to implement a centralized security service, and it seems like a popular standard for that is XACML. I have a complex authorization scenario and I've been having trouble figuring out how it could be defined using attributes for XACML policies.
The system I'm working on has several pieces relevant to this authentication scenario:
- Users create projects to organize their work. Each project has a list of team members and viewers (users or groups who can view the project but not modify it).
- Within these projects, users create recipes to describe how something should be manufactured.
- Users make requests for these recipes to be manufactured by another group.
In the case where a user wants to view the recipe for a particular item, any of the following must be true:
- The user must be the owner of the recipe (the person who wrote it).
- The user must be a team member on the project where the recipe was created. (either directly or via group membership)
- The user must be a member of a group manufacturing the recipe. (They need to see the recipe to manufacture it.)
- The user must be a member of a group that has manufactured the recipe within the past two weeks. (i.e., after completing a request to manufacture the recipe, they can continue to view the recipe for two weeks to correct any problems.)
- The user must be an administrator.
With those rules, it seems like the attributes needed to determine if a user can view a recipe include:
- The user
- The user's group membership (for project access, manufacturing group, or administrator access)
- The project team members and viewers
- Manufacturing requests for the recipe
Questions:
- How would a PIP gather this information? Directly from a database? Via service calls to the system that stores this information?
- How would this information be represented for XACML (in general)? Most of the examples I've seen use simple models that don't use collections of data (like a list of manufacturing requests); simply attributes directly on the object being accessed. Would the data be flattened somehow, like "isBeingManufacturedByUserGroup"? (and if so, how would the value for that attribute be determined?)
- How would the policies be structured to evaluate these rules?
- Are there any alternatives for handling this sort of authorization (besides XACML)? Would OAuth 2.0 be able to handle this sort of problem any easier?
(disclaimer - I work for Axiomatics, the leading implementation of XACML and ABAC)
Great question. I've actually put together an authorization policy lifecycle which walks users through the process of gathering requirements, identifying attributes, and implementing policies.
In your case, let's walk through your requirements
Requirements Gathering
Your original requirements
Restructured requirements
I like to rework requirements as subject - verb - object e.g. A user can view a recipe... Based on this model your original requirements can be reworded as the following:
Identify attributes
You can break down attributes into different categories (or grammatical functions). XACML uses categories itself so this is a natural step towards implementing using XACML (or ALFA).
Subject Attributes
Resource Attributes
Action Attributes
In this category, by the looks of it, you only have:
Requirements rewritten using the attributes
Implementing the policies using ALFA or XACML
The next step is to implement your policies. You can use ALFA (Abbreviated Language for Authorization). Axiomatics has an Eclipse plugin that translates ALFA into XACML 3.0.
Let's create a policy set that handles recipes. That policy set will contain a policy that handles the action view. That policy in turn will contain rules that address each requirement.
Using Policy Information Points
A PIP is just an abstract notion of an external attribute source. It can be anything. Different implementations will have different PIP connectors. For instance Axiomatics Policy Server provides connectors to SQL, LDAP, and REST services. This covers most of a client's needs.
XACML and OAuth 2.0
You compare both technologies but they are somehow a little different. OAuth 2.0 focuses first and foremost on authentication. It came about to defeat the password anti-pattern. Then there was a need to define permissions or, as they call them in OAuth, scopes. However those scopes are only punctual permissions. You still rely on the target application to publish a set of valid scopes and you still cannot do fine-grained access control. My colleague wrote a three-part blog on the topic, the first part of which you can read here.
I hope this helps. Feel free to ask follow-up questions or tweet to me.
XACML Output (Bonus)