High-Tech Humanities

Stephen W. Cote's Blog


Authorized For Duty

Separation of Duty As A Function Of Risk-Based Access and Authorization

While working with CrossIdeas, which is a fine product in and of itself, I spied a gap between the governance separation-of-duty (SoD) declarations and policy enforcement points, such as in Business Rules Management Systems (e.g.: ESBs or rules engines). If governance software, be it CrossIdeas or SailPoint or Aveksa, do a somewhat decent job abstracting technical constructs into something the business can understand for purposes of auditing and reporting, could those same constructs also be given back to an authorization end point?

I realized I had a solution for this with the Account Manager 5 Authorization Service.

Here is an example: Bob has fourteen accounts, and access to numerous shares each with thousands of unmanaged or undiscovered files. Is it permissible for Bob to invoke a particular service while having a toxic combination of entitlements? Maybe, maybe not. It depends on the situation.

The typical SoD configuration may compare entitlements as expressions of business activity and report violations forthwith. While there may be some argument as for why someone should be allowed to be in violation, those toxic entitlement combinations may need to be banned from actual use. It may be ok for an account's LDAP account to have write permission to one database and read access to a business database on another system. Even if those two are considered risks, they may be permissible given a particular business need. However, there may also be a particular application or service that must block access regardless of the rationale. If the SoD policies and activities can interoperate with the BRMS system, then it's possible to address this situation. I acknowledge certain systems do this already, though usually within their own ecosystem and not necessarily with full awareness of all entitlements across the enterprise.

Here is another example: Bob is compliant per SoD policy and is actively using Application Charlie. Likewise, Carly is compliant and is actively using Application Delta. Meanwhile, Ernie plans to engage in some shenanigans by compromising Bob's and Carly's accounts. Ernie submit's one activity via Bob's account that requires approval, and then a corresponding activity via Carly's account to approve the just-submitted activity. Both users are authorized to perform the activities, and both the SoD configuration and BMRS systems recognize the successful authorized activities. But Ernie introduces an added dimension: Either these activities are both conducted on the same session, or from the same location, or at unexpected business hours - all of which fall into the realm of risk-based-access.

If SoD and RBA policies, and a BRMS can interoperate, and one of those stores an audit trail of authorization evaluations alongside contextual attributes, then that history can be used to mitigate some or most of the risk.

Intrigued by how this might be solved, I added a Separation of Duty rule type to the Account Manager 5 rules system. Then, I created a database view that translated the group entitlements cache with the URN values, primarily to break the reliance on the unique database identifiers and make the dataset more portable. I created a simplified business activity concept by reusing the DirectoryGroupType objects, to which entitlements and roles may be attached. This provides a straightforward way to read and cache permissions by business activity, and then find people or accounts that currently have those activities assigned. By pairing two or more of these patterns together as SEPARATION OF DUTY patterns, and setting the rule to DENY, that rule can be used for pure SoD reporting purposes, or be partnered with Risk- and Role-based authorization assertions. From an application point of view, it can still make a simple policy invocation, such as: Does Policy #1 Permit Person A? The only needed input parameter is the name of the Policy and the Person, while the policy evaluation includes SoD, RBA, and RBAC statements.

The end result is that an SoD policy, written to be consumable by the business, can be used for immediately enforcement, even when a violation exists or is determined to be allowed.


A Tool for Project Management Governance


Rocket is a collaborative project management tool designed to work with organizations' unique perspectives on project methodologies. As mentioned in the Authorization as a Service article, the Rocket library is quite versatile. This article discusses the principles and philosophy of the Rocket design.


I've experienced a variety of program management methodologies and tools in my two decades of high tech employment. Over that time I've become fascinated with the ways in which organizations implement various solutions, and both the fervor and resentment of trying something different. I've had the pleasure of working for companies of all sizes, both as a full time employee and also as a consultant. As a technical leader, no matter which methodology, I often found myself preparing multiple versions of project materials for different situations. As a consultant, I was able to see customers struggling with the same difficulties and without any one tool able to adequately bridge multiple methodologies and styles. As a proof of concept, I conducted a few decomposition exercises to create an object model able to represent the different approaches and requirements I had encountered. Two notable examples were, one, mandates that project plans conform to and include elements of inarticulate models, and two, enterprise-grade plans that cross methodologies.

One common scenario is an organization wants to deliver something, stakeholders expect certain artifacts at certain stages, management expects schedules and projections in particular formats, and the implementation teams become constrained by organization-defined methodologies and are impeded from providing what stakeholders and leadership expect. The organization's methodology, to be kind, can be a bastardization of some standard, de facto or otherwise. Challenges that lead organizations to customize procedures include disparate goals, budgets, and schedules, with interdependent requirements, resources, and artifacts. One of the first questions I encounter as a consultant is: How do you plan on tracking the proposed one or more projects while accommodating a customized methodology with proprietary requirements and milestones?

The trap I found myself stepping into is I use one tool (e.g.: Excel) to create or adapt a set of estimates, including information and formulas I don't plan on sharing outside my immediate team. Then, a separate project plan is created out of the tasks defined with the estimates using a planning tool (e.g.: Project) from which a project schedule is more readily consumable without hacking up custom reports. That plan only lasts until the project starts, when it is severely gutted and reworked into whatever a customer's organization or department uses, with additional steps which are pertinent to the organization but otherwise would not be apparent to me at the beginning. For large multi-month or multi-year projects, it's pretty common to have significant priority changes that lead to subsequent rework on the plan. What I think is amazing is the complete disregard for the gross waste of shelving work and reworking plans during these re-planning sessions. Priorities change, that's understood, and nobody wants to throw good money after bad, but I think there should a clear indication that anything made left on the shelf, call it your buzzword-debt, is waste.

Weary of re-entering the same estimate information in myriad formats, and growing more frustrated over wasted time and effort, I reviewed a number of existing tools from process frameworks to mind map tools to collaborative project management tools. Each had their own distinct features, but still I felt drawn to something that could combine the collaborative features with a process framework, while addressing those process areas that I thought were too often overlooked. So, I did what any red-blooded developer-at-heart would do: I made a model from which I could transform the information into whatever esoteric or, wishfully thinking, somewhat standardized methodology that was desired.

I recognize there are a number of cloudy Web-based project management tools with added business intelligence capabilities, particularly some that popped up over the last few years. At the time I started down this path, not so many existed, and even now, I don't know that they would do what I wanted to do: Be able to accommodate multiple and unique project planning methodologies. In the process, I created a general approach and a set of tools that, inadvertently, match a lot of what the commercial cloudy tools offer, plus my own secret sauce.

Why Rocket?

I chose to create a model for a Big Hairy Audacious Goal (BHAG): Planning to build and launch a rocket. And, thereby came the project's namesake. Although I had a number of complex project plans to use for reference, I wanted to use the most complicated mess I could think of. Consider the sheer number of sub-projects that exist in building, launching, and landing (or delivering) a rocket. No one methodology governs the components built by sub-contractors, although certain types of planning and status information must be centralized. Somebody wants to know whether or not that candle is getting off the ground on time. The Rocket design represents this hybrid and dynamic structure.

The Rocket Philosophy

Accompanying the technical design is a philosophy for harmonizing methodologies (Waterfall, Iterative, et al) . I wrote an elaborate treatise on the subject, but that became counter to the objective which wasn't to introduce yet another process, but to try to make better sense of what is being used. The most important points, which I think are still applicable, are the first two:

  1. Have a warrior spirit mentality (Bruce Lee). Be like water, fluid and dynamic when wet, and hard and carved when ice. This is primarily for the managers and leaders. There are times when flexibility is key, just as there are times when rigidity is needed.
  2. Identify, acknowledge, and address waste. This is not so much a rewording of the theory of constraints as it is the observation that managers and leaders won't or can't acknowledge waste, and thereby allow it to accrue. Wasting time, resources, and money ruins morale and suppresses innovation.

Data Model

Rocket is built atop the Account Manager 5 library, which includes support for organization hierarchies, encrypted data, roles-based access, object-oriented bulk load operations, and more. The two primary objects for aggregating everything together are Lifecycles, which represent the aggregate of all projects against specified budgets and schedules, and Projects, which represent one or more stages of work and their work products. Beyond Lifecycles and Projects is a rich model for describing many atomic aspects of a project plan.


In addition to the project modeling capabilities, the following features are also provided by Rocket:

Authorization as a Service

Account Manager 5 Capabilities

This article continues the discussion started in the Authorization as a Service article.

Within Account Manager 5 is a versatile foundation for working with and authorizing against enterprise identity and entitlement information. This foundation begins with a flexible entity model partitioned by organization, and a generic authorization model that accommodates Roles-Based Access Control(RBAC), Attribute-Based Access Control (ABAC), and Risk-Based Authentication (RBA). The internal authorization implementation is called Participation Access Control, on which the Effective Authorization Service and Authorization as a Service service are based.

Authorization as a Service is exposed as the Policy Service REST interface. An authorization client requests a Policy Definition for a given Policy, which includes context information, expiry instructions, and a list of expected parameters. A Policy Request can be created from the Policy Definition, and parameterized values may be specified for the defined parameters. The Policy Evaluator translates the parameters into Facts, which are then used during the evaluation of the rules and patterns attached to the policy. At the end of evaluation, the Policy Response includes the response state, any risk score, and the pattern chain used to evaluate the policy. A key feature of the Policy Service is that authorization operations, such as asserting role participation or entitlement affect are pre-calculated through the Effective Authorization Service at the time the data is loaded. Therefore, the Policy Service has access to an emulated view of a given set of enterprise identities, accounts, applications, permissions, roles, data, and data rights.

Each cluster of enterprise identity data is logically separated by organization, and then by group and/or parent. Account Manager requires that all entity objects be owned, limiting default access to the owner and administrator, and safeguarding it from accidental exposure. Further more, values and certain objects may be encrypted using one of several integrated encryption layers (Cryptography currently supplied by BouncyCastle). Persons, Accounts, and Groups are all scoped by Group and then Organization, while Roles and Permissions are scoped by parent and then Organization. A snapshot of enterprise data is represented by a group of Persons, a group of applications, and forks in the Role and Permission trees. Applications are represented as named groups, into which Accounts are stored. If the Person to Account relationship is provided, as well as Application entitlements and entitlement memberships, then the Effective Authorization Service will calculate the effective permissions for a person via a linked account and that account's permissions. If a role hierarchy is loaded, and application entitlements and person memberships specified, then the Effective Authorization Service can also show the base and effective role entitlements. Each type of entity supports multi-valued ad-hoc attributes, which then allow the Policy Service to evaluate attribute-based access.

The Policy Service's internal authorization procedures understand a set of predefined Factory types, including persons, accounts, users (not represented here), attributes, roles, groups, and permissions. When executing Authorization rules, the referenced Factory types are retrieved and then evaluated through the Effective Authorization Service. This allows for rules that assert for indirect permission and indirect role participations, without supplying any of those references. Authorization assertions are limited to discrete values because the Policy Definition and supplied parameter templates include the necessary context, and all non-parameter facts remain on the server. For example, consider a person with twenty accounts, some role memberships in a role hierarchy, and any number of application entitlements. Does a Person have an Account with a Permission (entitlement) inherited from a Role? Or, Does a Person have an Account with a Permission and a custom attribute value on either the account or the permission? This type of policy can be written by bulking loading data and defining the policy rules, and executed with only a reference to the Person. No PIPs, no lengthy attribute lists, no custom data schemas, no complicated or abstract authorization languages (looking at you, XACML). For another example, this model has been used to rapidly bulk-synchronize with IBM Security Identity Manager, including extracting role hierarchy and entitlements. Once that data was loaded it was immediately available (to an authorized user, of course) for use by the Policy Service.