Axiomatics is proud to release version 6 of its flagship product, the Axiomatics Policy Server (APS). APS 6 features the industry’s first web-based graphical user interface for XACML policy creation and editing, in addition to support for the REST and JSON profiles of XACML that were recently ratified by the XACML Technical Committee. These along with a whole slew of optimizations and feature updates make this release something that existing customers have been looking forward to and something that organizations planning an initial roll-out of Attribute Based Access Control (ABAC) find to be very useful.
Data Filtering is a powerful new technique to ensure that sensitive data stays safely in the database. Many companies have already deployed Data Masking as part of their data protection strategy. In this post, we’ll review the key differences between data masking and dat filtering, highlighting strengths and weaknesses of each approach; and finally show how they can be deployed together.
At the heart of your enterprise - and most likely the final layer of protection in your security architecture - is your data. Your business relies on it to function; creates, updates and deletions need to be carefully protected; and the data must only be read by those with the rights so to do.
For most organisations, there is a subset of this data that is particularly sensitive - for business reasons; for regulatory compliance; or both. Many companies take an approach of protecting this data at the application layer - but increasingly there is a requirement to better protect at the data layer itself.
Earlier this year, we released a new product, the Axiomatics Data Access Filter (ADAF). ADAF provides powerful, standards-based data filtering, meaning you can protect your data from ever leaving the database; and you can protect applications with modern, externalised access control even if you can’t make changes to the applications.
Today, ADAF supports Oracle databases, and uses a component of the Oracle Database - Virtual Private Database (VPD) - to intercept and parse the SQL query.
So what happens if your data resides in some other database - say, SQL Server?
Externalised authorization is a powerful way to ensure resources are protected and restricted only to those individuals who have the appropriate permissions. Attribute-based access control (ABAC) gives you the flexibility you need to comply with complex security policies as well as regulatory requirements.
As companies discover the power of ABAC, CIOs, CISOs and security architects are pushing for this technology to be included even for smaller development projects. Project managers and developers are caught in the middle, trying to deliver the project on time and to budget, whilst meeting these increasingly challenging security requirements.
This is the third and final post of a series examining how authentication -- in particular, federated identity and standards-based single sign-on (SSO) -- and attribute-based access control (ABAC) interrelate, and can interoperate in support of some interesting use-cases. In case you didn’t read the earlier posts yet, or if you just want a quick refresh, Part I is here, and Part II is here.
This is the second post of a three-part series examining how authentication -- in particular, federated identity and standards-based single sign-on (SSO) -- and attribute-based access control (ABAC) interrelate, and can interoperate in support of some interesting use-cases. In case you didn’t read it already, or if you just want a quick refresh, Part 1 is here.
This post builds on Part 1 to explore in more detail the key standards for authentication, both existing and emerging, and lays the groundwork for a closer examination in Part 3 (coming in a few weeks’ time) of how these can be used together with standards-based ABAC.
Let’s first make sure we’re clear about exactly what we mean by ‘authentication’. I’m not going to cover multi-factor authentication and related work being done by groups such as the Initiative for Open Authentication (OATH) or the FIDO Alliance. This is an interesting topic all to itself, but too much to cover in detail here. Nor am I going to cover internal-only authentication standards and solutions like Kerberos or Novell NetWare. Integration methods with solutions like these are fairly well understood; and more importantly, these solutions are being superseded or extended by cross-domain authentication -- otherwise known as ‘federated identity’. This is the area we’ll cover here.
This will be the first blog of a three-part series examining how authentication (auth’n) -- in particular, federated identity and standards-based single sign-on (SSO) -- and attribute-based access control (ABAC) interrelate, and can interoperate in support of some interesting use-cases.
We’ll start, in this post, with a quick review of federated authentication: what it is, what standards apply, and how it differs from authorization (auth’z). The second and third posts, coming in a few weeks’ time, will look in more detail at some key new standards emerging for authentication (part II) and then (in part III) at how these can be used in the context of standards-based ABAC.
First, then, a quick review of auth’n and auth’z.