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.

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

What better way to kick off my external IBM blog than to share with you some details of the presentation I intend to give at IBM Pulse in Las Vegas in early February. The presentation is titled Heterogeneous Identity and Access Management for Microsoft Office SharePoint Server. Integration with Microsoft SharePoint has been a topic of growing interest among our customers, and I'm excited about the chance to update people on the solutions we have available now, and the even newer things that are being explored, planned, discussed, implemented.

This presentation will take a holistic approach to providing business-driven security to Microsoft SharePoint environments using Tivoli Security products including TAMeb, TIM, TFIM and TSPM. The presenter will draw on his experiences to share solution patterns and best practices for integrating Tivoli's identity and access management products with the Microsoft SharePoint family of products. Architectural decisions will be described for how to choose between the various options for providing authentication, single sign-on, authorization, and user provisioning for SharePoint environments. Deployment examples from customers will be shared.

What I hope to get from delivering the presentation is copious feedback from customers and business partners on how they perceive the suitability of some of the solutions I will present (and demo!) as well as where they still see gaps that we must close. What we can't cover during my scheduled session can be discussed at one of the hospitality functions throughout the week.

I hope to see you there, but if you can't make it and have an interest in the topic, let me know and we can setup another time to discuss.