Question

We have multiple API modules.

Would I write a Policy for each API module, or is it one Policy with different rules?

Say I have an API

http://api.example.org/api/v1/users and

http://api.example.org/api/v1/products and

http://api.example.org/api/v1/purchases

would each of this api have one Policy with different rules for each resource? Or is it a Policy for each API module within a PolicySet?

I am new to XACML and we are writing our first policies. The introduction at OASIS just says:

A Policy represents a single access control policy, expressed through a set of Rules.

Not really clear for resolving my needs...

Was it helpful?

Solution

This is a great question. A short answer would be: it depends on your use case. There is not right or wrong here. You could protect all your APIs in a single policy or even a single rule.

That said, think about the entire policy lifecycle:

  • requirements gathering
  • policy design
  • policy authoring
  • policy evaluation
  • policy auditing
  • policy reconciliation

In each stage, who's responsible? The same set of people? Different teams? How do you want to scale up the use of XACML in your company? Do you want a central authoring team? Will that work when you need to support 10, 100, 1000 APIs? The answer is likely no.

This means that you want to let API owners write their own policies. They get to choose what they define in their policies, what is allowed, what isn't.

Then, you want to have a "policy packager" role. That person collects and assembles all the policies that have been written. There are different types of policies:

  • the application policies (the ones written by the API owners)
  • the operations policies (the ones about global checks e.g. no access before 9am or no access from a rogue country...)
  • the compliance & regulatory policies (the ones about HL7, PCI-DSS and other regulations)

In a global policy set you can combine the policies (or policy sets since policy sets can contain policy sets). You can choose your combining algorithm to match your need. A typical one is first-applicable. It means that whichever policy / rule applies first wins overall. A more conservative choice would be deny-unless-permit, which denies all requests unless a policy explicitly permits access.

Back to your specific example, based on past experience, I would be tempted to write 3 different policies, one per API. You can use policy references and policy set references to link and reuse policies.

Axiomatics (disclaimer: this is the company I work for) provides workshops on XACML and attribute-based access control.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top