Access control doesn’t make it to the bestseller lists

12 June 2013

Jason Turner

Reviewing access control with a customer recently, looking to roll out a range of reconciliations over the internet to their large counterparty customer base, I was struck by the revelation that access control doesn’t make it to the bestseller lists, and that as a result the significance of a solid capability in enterprise applications, or indeed the extent to which a flexible approach can ensure you don’t end up reading the manuals while on holiday is not entirely self-evident.

CTC is designed to be integrated fully into an enterprise in a service oriented architecture, and is designed to enable rapid deployment and configuration by enabling a completely flexible system which imposes no pre-defined data structure but learns and adapts the data structures of the data to be matched and managed.

In a modern enterprise whether delivering a value-adding service to corporate customers and counterparties or delivering an internal matching capability the need to provide a solid and business oriented security capability is crucial. A key part of this security infrastructure is the ability to control access to resources and capabilities and to control the audit of that access.

To provide an access control capability which can cover all uses of the system, adapt to business data and also adapt to the security policies of customers or organizations CTC has adopted an attribute based access control model (ABAC – for standards and references see footnotes). ABAC is based on the concept of granting security attributes to resources, actions and users within a system and applying policies which compare the security attributes of the user to those of the resources and action to determine whether the action should be allowed or prevented, and how that action should be audited.

In CTC the resources are those resources which are accessible via the system services – namely all of the core concepts of the system, including for example tenants, reconciliations, matching patterns rules and functions, record and group data, reports, and tasks. In CTC the actions are the actions which can be enacted on the resources via the system services – namely all of the key activities of the system, including for example viewing record and group data, matching records into groups, accepting or rejecting suggested matches, raising and resolving exceptions, providing documentation, and editing configuration. In CTC the policy is a normal ABAC type policy which assesses the attributes of resource, action and actor to make access decisions.

CTC adopts this approach for several major reasons:

  • Firstly the model is absolutely service oriented in the sense that the model imposes no pre-defined structure, but enables the security model for any particular reconciliation and surrounding business logic and workflow to be defined consistently with the desired business goals and (possibly pre-existing) policies. This means that a new reconciliation can be on-boarded to the matching service and the security for that reconciliation can be tailored to that use.
  • Secondly the model is consistent with CTC’s focus on enabling rapid on-boarding and efficient maintenance of reconciliations, and of imposing no unnecessary overhead or configuration. If no security attributes are applied then the system is entirely open, as is appropriate for rapid deployment and configuration. Security can then be imposed as required, and at no point does adding further restrictions impact outside of the resources being secured.
  • Thirdly the model enables our customers to offer the same level of rapid on-boarding and efficient maintenance of reconciliation to their own corporate and counterparty customers, critical where those customer bases are of a significant size. This is enabled because while flexibility of policy is ideal to provide flexibility in behaviour, where a more pre-defined approach is required the same policy can be applied across an entire multi-tenant set of reconciliations; this enables the service consuming corporate customer to manage access control within an established framework by merely configuring a small set of security attribute values.
  • Fourthly the model is consistent with service orientation in that the source of the security attribute information for users can be obtained from any suitable service. CTC provides its own security attribute management capability for customers without some existing service that can provide such information, but the system can integrate cleanly into an existing on-boarding flow and set of services.
  • Fifthly the model establishes a service oriented base for access control. CTC does not currently support the use of external entitlement servers or policy application services, however the architecture is already in place to enable the application of access control to be entirely externalized from CTC, in line with CTC’s guiding strategy of SOA integration and use of existing enterprise services where available.

CTC uses ABAC in the following manner:
Resources of two types are available in the system – configuration and operational. Configuration resources are things like tenants, reconciliations, reports and record and group definitions. Operational resources are things like records and groups. Security attributes can be associated to both kinds of resource, but are applied according to the resource model. Configuration resources are affected by security attributes with static values, which are provided at the point of association. Operational resources are affected by security attributes using attribute values which are dynamically drawn from the data.

As a simple example, if a security attribute of RegionSA is applied to a report then it must be applied with one or more values, e.g. RegionSA=’AP’, and the report will be visible only to users who have been granted the attribute value RegionSA=’AP’. However applying RegionSA to a record feature Region does not require a value, but will dynamically use the feature value on a record instance at runtime, thereby restricting visibility of a record instance with Region equal to ‘US’ to users with attribute value RegionSA=’US’.



T: +44 (0)20 7653 0222 (sales)

Email Us

New York

T: +1 646 943 5955

Email Us


T: +65 6809 5027

Email Us


T: +61 (0)2 8514 7007

Email Us

Keep Up To Date

Sign up to our newsletter

Please leave this field empty.