I've worked with Tivoli Access Manager (TAM) for a long time (through three product name changes and two company name changes at least) and have been getting into Tivoli Security Policy Manager (TSPM) over the last year or so. One of the things that I have become more aware of is the different thought process I go through to design authorization policies with these two products. I wouldn't say that I have developed a migration procedure or anything like that just yet. However, I did want to write down a few notes on the approach I take and how I neutralize the TAM bias currently in my brain.
Firstly, here is a recap on writing TAM authorization policies:
- The TAM protected object space is hierarchical.
- TAM has three policy constructs - ACL, POP and Authorization Rule.
- Exactly one ACL and no more than one POP and Authorization RUle may apply to a TAM protected object.
- TAM policies implicitly describe permitted operations/access. There is no flexible way to explicitly construct a complex denial of permission.
- An ACL is a list of associations between directory users/groups, or a principal such as all-authenticated, and permission sets.
- A POP provides identity independent constraints, such as authentication and network based policy.
- An Authorization Rule is a boolean rule constructed from identity, transactional and third-party data/attributes.
- Customized external authorization rules can be coded in C and augment (not replace) TAM's native policy.
- Many of TAM's advanced authorization features (including some not discussed here) are not accessible from the browser based administration pool, and though powerful, are infrequently used.
TSPM authorization policies, making some indirect comparisons to TAM authorization policies, have these highlights:
- Uses XACML as the policy description language. This allows for a more formal description and structure for how an authorization decision response can be formulated from a request and the policy configuration
- Are also based on a hierarchy of protected resources (how they are discovered is more flexible)
- Policies can be associated with one or more protected resources (TSPM 7.0 calls them services, which can be counter-intuitive for some resource types)
- A policy can specify multiple roles, including special subjects 'everyone' and 'all authenticated'.
- A policy can specify one or more actions, or no actions
- Policies can contain one or more rules. Those rules could be simple, e.g. "permit" or can be formed from clauses that compare request context, subject attributes and other information obtained from policy information points, such as directories and databases. Rules are evaluated in order until one (if any) matches.
- Rules within a policy can return permit or deny.
- Customized external authorization rules can be coded in Java (OSGi) and become part of a TSPM rule.
- Authorization decision requests can return one of four states: permit, deny, not applicable (no policies apply) or indeterminate (didn't have all of the information needed to make a decision).
When it comes time to construct policies in TSPM, I try to keep these things at front of mind:
- Approach the problem in a subject-centric way. Don't start by thinking about the resources as I typically do with TAM, but think about the different subjects and role and the set of accesses they need and must be denied.
- Remember that rules can return permit or deny. Use of explicit denial can simplify policy definitions.
Then, I (think I) go through a process like this. For each role (including the special 'all authenticated' and 'everyone' roles)
- Formulate the list of simple statements that describe what those roles can and can't do.
- Normalize and consolidate those statements to reduce the number of statements without changing the intent
- Order the statements in each role:
- Where possible, put simpler rules not involving external attribute data or external rules higher up, to accelerate evaluation performance. Permit rules can be re-ordered without changing the result. Elevating deny rules may have unintended consequences.
- Add explicit deny rules at the end of each policy, so that the integrity of the solution is independent of how the enforcement point interprets 'Not Applicable' decision responses.
I hope you found that useful. Now then, if you've played with TSPM or other XACML based products, how do you approach policy authoring?