XACML Made Easy: Modeling High Level Policies in XACML
- LANGUAGE: English DATE: Thursday, October 06, 2011 TIME: 16:00 CEST / 7:00am PT / 10:00am ET
Access control is one of the touchiest topics in IT security and has a direct impact on compliance management. Many applications implement their own proprietary access management logic, based exclusively on roles. This prevents business from taking fine-grained control and turns governance into an up-hill struggle. The OASIS XACML standard (eXtensible Access Control Markup Language) was created to address these issues in a flexible and consistent manner. To fully benefit from XACML's potential, we need to embrace this new concept that is simple, yet powerful.
In this webinar, Principal Analyst Martin Kuppinger will give an overview on how the XACML standard can be used to achieve a top-down approach to governance. Following Martin's presentation, Axiomatics' Director of Technology Partnerships and former Kuppinger Cole Analyst Felix Gaehtgens will show examples that show how easy it actually is to translate high-level access control requirements from written English into XACML policies that implement tight control. Felix will then describe how to model XACML policies to integrate risk-awareness in access controls.
Questions & Answers
Q: "Environment" attributes seem to be hiding a lot of complexity. In practice, how is the connection made between the nice clean XACML policy and the messy database queries?
XACML allows us to resolve attributes that a policy needs to make a decision. If these attributes are not supplied in the request, the XACML architecture can call policy information points (PIPs) to resolve those attributes. At Axiomatics, we defined an interface that can be called to ask for a specific attribute. This interface is implemented by the PIPs, and they then attempt to resolve the attribute. Very commonly used PIPs use SQL databases or LDAP directory servers. They will take attributes from the request context (such as the user ID) in order to make a look-up in a database table or make an LDAP request. We have also seen people define special stored procedures in SQL databases that take input parameters and then do some lookups in the database and come back with a result.
It can be a bit surprising to see how clean and easy-to-understand XACML policies can be. But this is fully intended, and in my opinion just shows how powerful XACML actually is. The idea instead is that a policy will require some information from the request, and some information will have to be looked up. It’s not necessarily attributes in the category “Environment”. In fact, any attribute of any category could be looked up by PIPs.
Q: Can you give an example of what “Environment” attributes are used for? They seem to be able to contain a lot of the context that you talked about.
“Environment” attributes are used to describe the situation in which access is being made. As such they often achieve basic context-awareness. They are usually far from complex, for instance time-related (date/time of day) or location related (IP address, access point from where access is requested etc.). However, they can indeed be used for more elaborate - or complex if you want - authorization rules. In financial systems, we may for instance introduce “risk” as an environmental attribute which in turn may be calculated based on numerous other types of data - normal user behavior patterns, size of transaction in relation to current balance etc. etc. In military use cases a “red alert” may be an environmental attribute impacting all other authorization rules etc. Yet, this is exactly what makes XACML simple, I’d say! It’s a simple way of handling anything from simple rules (“access only allowed during normal office hours”) to quite complex situation in which we demand “risk awareness”.
Q: Access Control gets extremely messy when you have to do it for the databases as well. Can XACML help?
A common reason for database access control getting messy is that we traditionally were forced to also cater for access control needs in our database models rather than just having a strict focus on the application’s functional requirements.
This is because databases often only allow us to specify privileges for “database users” on a per-table or perhaps even on a per-column basis, but not really on a per-row basis. Therefore, when a database contains many records, and there are many users accessing it, access control is often done outside of the database itself, by the application. Those applications connect to the database using a technical user id, and then filter data in order to make sure that users only see the data that they are entitled to.
In an ideal world however, applications should ask for the data that they need from the database layer (SELECT * FROM MY_TABLE ...) without any additional strange joins to check that the records returned are actually allowed to be returned to the user. Often, this means that data elsewhere is referenced in order to authorise the current user; the query could become something like (SELECT MYTABLE.*, T1.Country, T2.MY_ACCOUNTS [...] FROM MY_TABLE WHERE …. [with elaborate expressions to make sure that we are only returning rows that our user is allowed to see]).
This means the authorization actually becomes hard coded not only into the application code itself, but also into its database layer. And still - in spite of messy database queries we rarely are able to handle even quite simple multi-dimensional aspects of authorization; situations where we need to filter out either entire rows or just one or the other column to reflect the current user’s authorization.
XACML offers elegant solutions. With Axiomatics XACML based Reverse Query (ARQ) technology we can for instance do the following:
1. The application asks for the data it wants without bothering about authorization.
2. The Policy Enforcement Point (PEP) queries its policy engine about the current user’s permissions both on the level of rows and columns.
3. The application then gets the record set returned with all values for which the current user is unauthorized filtered out. The filter could either blank out individual cells or delete entire rows in the result set.
All of this can be done in a snap and the beauty of it is that these multi-dimensional filters are controlled with attribute values that don’t even need to exist in the database - they can be maintained centrally in your LDAP where all the other user permissions are configured.
Q: But the auditors can't stop with the XACML policies, they still have to dig at least one more level.
Not exactly. With XACML we can achieve governance by implementing a top-down access control model that tightly follows business rules. Hence, by auditing the XACML policies we can ensure that the access control system conforms to the rules imposed by the business. These rules should, whenever possible, use existing business data. So when looking at access control - it should be enough to audit the rules.
Of course – if legislation or business requirements dictate this – business data may also need to be audited, but that’s the case anyway, even without access control.
To give a practical example of this: say we have XACML policies that give specific privileges to employees. These XACML policies would need to query the HR system. So in this particular case you would only have to audit the XACML policies in order to check whether your access control policy has been implemented correctly.
Of course you could argue that the XACML policies give access according to data in the HR system, hence the HR system may or may not need to be audited as well - this depends on legislation and business practises. So regardless of access control you may have to audit business data and processes anyway. And in this case, XACML makes life easier for you, because XACML policies can use business data directly – you don’t need to create yet another data silo that needs to be audited as well.
Q: What is the state of the art with regard to the Policy Administration Point? I.e., editing the rules? How do you manage a large set of rules?
Each vendor offers a different set of tools for policy administration, hence this is really product specific. I can therefore only really speak for us (Axiomatics). We focus on 100% XACML support, and therefore don’t believe that it is a good approach to offer “short-cuts” that ultimately restrict you by offering you only a limited part of XACML in the name of being “easy to use”. Instead, we offer a policy editor that has been extended with a tool set to assist in authoring, managing the lifecycle of, documenting and testing policies.
To simplify policy authoring in a pre-defined context, a Domain Specific Language (DSL) may be considered. Axiomatics can for instance provide such solutions to allow developers to express policies in a language aligned with their programming code, using the attribute names that have been agreed upon within their security domain.
Last but not least, it is also very important to simulate access policies – not just for auditing but also during the definition of policies. For this we provide a comprehensive set of tools to fully trace the whole policy decision process from receiving a request up until the final result. At every step it is possible to see which rule was invoked, which attributes were being compared to which given values, what the outcome was and how the different individual decisions were combined to deliver the final decision.
We believe that these tools are invaluable when dealing with a growing amount of policies. However there is a misconception of XACML and “large amounts of policies”. XACML is very powerful and typically allows you to tightly map your plain English access control policy towards a computer representation (in XACML). Therefore you shouldn’t expect to have a large set of rules. Rather you should expect few, but very powerful XACML policies that harness your business data to make access control decisions.
Q: Is this from complexity point of view different from having your web/java developer code the rules? XACML looks complex... are there enough tools (which ones) to document and audit the rules once they are coded in XACML?
We have seen different approaches there. In some cases, where a web/java developer is expected to deliver a “turnkey solution”, it is the developer who does the actual coding of the rules. However, the rules are independent of the application and can even be changed or optimized at a later point. Tools exist to create, manage, test and debug XACML policies – they are of course different from each vendor, and I can only speak for Axiomatics here where we have focused on a comprehensive set of tools to offer full access to all of XACML’s features without restricting them in any way. This is very important, because the XACML policy language itself offers a rich set of features designed to write compact and powerful policies. We therefore find it of paramount importance not to offer “short-cuts” that might look nice and simple but restrict things, because this ultimately leads to a large set of (primitive) policies that are difficult to manage. Instead we use features such as attribute management, domain specific languages, policy tracing to assist the definition and management of policies.
There is the common misconception that XACML is “complicated” because it is so expressive and rich in features. This however makes it actually quite easy to use when compared to other access control models. XACML rules should closely follow plain language rules. This is possible because of the attribute-based access control: Who (SUBJECT) may carry out an ACTION on something (RESOURCE) in a specific Context (ENVIRONMENT). Multiple attributes can be used in each categories to describe the policies. Attributes can be looked up from external policy information points.
This actually reduces policies to a high level where it uses existing business data in order to make decisions. This also makes it much simpler to audit: With XACML we can achieve governance by implementing a top-down access control model that tightly follows business rules. Hence, by auditing the XACML policies we can ensure that the access control system conforms to the rules imposed by the business. These rules should, whenever possible, use existing business data. So when looking at access control - it is in many cases enough to audit the rules. Last but not least - we have a product called the Axiomatics Policy Auditor (APA) that is a feature-rich tool for auditing XACML policies.
Looking at policy management and audit is just one aspect though. What is by far the more important part for the developer is to use a software development kit (SDK) to enable fine-grained XACML support in the application. This can be done by adding “check points” into the code at which points a call-out to a decision point is made. Also, methods and even data objects can be protected by tagging or “wrapping” them. Once this is done, the application will send access requests to a policy decision point (PDP), and that decision point will obviously require policies.
Q: Have you seen a successful example of a domain/enterprise governance of fine-grained XACML attributes?
Absolutely. Some of our financial customers are using this for their trading applications. XACML implements fine-grained authorization by harnessing business data from external systems. The XACML policies used for this are implemented straight from regulation and business requirements. For the financial industries an access control model that allows implementation of fine-grained rules based on conclusions drawn from a corporate risk matrix offers amazing opportunities. If you for instance consider the multi-dimensional approach of the COSO framework, XACML offers some very obvious and powerful governance benefits: the outcome of corporate risk assessments and risk appetite decisions can directly be fed into the policies that control how applications feed information to users. Think about the many instances in recent years where fortunes have been lost when individual employees on behalf of their financial institutions have taken on risks which their managers later claim to have had no knowledge about. These are incidents could often have been prevented with the kind of context- and risk-aware authorization systems we see our customers implementing right now.
Q: Can you provide example of "One approach to manage access" vs. the opposite ("multiple approaches"?) (slide 13)
If we want to know what really happens with the corporate information, current solutions focus on auditing many systems which might have access to that information. With other words: We need several approaches on auditing which aren’t integrated or harmonized. The result is that we might know what happens with specific information from the perspective of a single system, but we don’t have a holistic perspective neither with respect to knowing about all systems accessing particular information nor with respect to consistency of business rules enforced in the different systems. If we work with one set of policies which are externalized out of different systems, we can focus on auditing these rules and their impact on the information instead of trying to get a valid overview about a multitude of heterogeneous systems.
Q: High level requirements can be transferred into XACML policies in many ways in XACML (e.g a target can be set in rule or in a policy). Are there any best practices for modelling XACML policies?
Yes, we provide customers with best practices. We also provide workshops and training material that cover the best practices. Many are common sense and have to do with the actual structure of the policies being authored. For instance, we tend to promote a “divide ‘n conquer” approach whereby policy authors can divide an access control into smaller chunks by authoring resource-specific policy sets that focus on separate applications (or sub-parts of applications).
Other best practices have to do with the use of attributes, their location, their retrieval costs, etc...
Q: can you name some of out-of-box PDP's?
There are 3 categories of PDPs today:
- open-source PDPs
- JBoss PicketBox
- commercial closed-source PDPs
- Axiomatics PDP
- academic PDPs
- U. of Kent (Permis)
- Heras AF (University of Applied Science Rapperswil in Switzerland)
Q: Does XACML''s policy language support calls to external applications returning a certain value necessary for a policy?
Yes it does. This is essential what the policy information points (PIPs) are used for. They are called either by the policy enforcement point (PEP) or by the policy decision point (PDP) in order to resolve and look up attributes. These PIPs can be written to do whatever they need to do – including calling external applications or services - and at the end return the required values.
Q: when the number of rules, thus cases, grows, how is the question of contradicting rules addressed?
This is addressed by a feature in XACML called “combining algorithms”. These define how the final decision should be derived. For example: “the first rule should apply”, or “deny overrides”, “permit unless deny”, and many others. Combining algorithms can be applied to policies (where they combine the results of several rules) and to policy sets (where they combine the results of several policies, or policy sets).
Q: Why does it take so long to get XACML 3.0 finalized when, apparently, there are no major enhancements? Who, except axiomatics, really pushes it?
There are in fact major enhancements. XACML 3.0 introduces new combining algorithms, data types and functions. There is a new XPath data type which integrates XPath more correctly into the language. Obligations can now have dynamic content, and there is the new “Advice” construct. There are also new and improved profiles, such as the administration profile and a much improved multiple decision profile. So there really is a difference. It is correct that Axiomatics is the leader in XACML implementation, and Axiomatics was the first company to attest a 3.0 implementation, but Axiomatics is not the only company implementing or promoting XACML 3.0. In fact, the scrutiny the spec is receiving now because several vendors have implemented it or are implementing it, has lead that some minor errors were discovered in the text. The TC decided to make corrections, and we therefore brought the spec back to working draft status. Getting them up to CS from there is a somewhat time consuming process, designed to ensure that the specs get a public review. OASIS staff is currently very busy so there is a several months long queue for publication, which has caused delays. After public review has completed, one more attestation is required, before the vote for official standard can be held.
Q: In this example, you sent the permit response to the resource (I assume), but what are you permitting - does XACML also send the additional information such as dept attribute which limits access to secure content.
The response contains the decision (either of Permit, NotApplicable, Indeterminate, or Deny). The response is sent from the PDP to the PEP. The PEP is what protects the targeted resource. Depending on the form factor of that resource, the PEP can be deployed as different components e.g. a web service handler, a servlet filter, or a database filter.
Take the servlet PEP for instance: if the PDP returns Permit, then the servlet PEP passes on the HTTP servlet request to the next filter in the application’s servlet chain. If the PDP returns Deny, the PEP is responsible for blocking the message flow and potentially returning an error e.g. an HTTP 401 or maybe a custom error.
Along with the decision, it is possible to return additional information through the use of XACML obligations and / or advice. Obligations are statements the PEP must comply with. The PEP may handle advice statements. Obligations can help enrich a business flow such as limit access to secure content based on department attributes. It can be used to force end users to augment their authentication (for instance in a retail banking website).
Q: Do we need an entitlements server to implement XACML architecture?
The XACML architecture defines several actors: the policy enforcement point (PEP), policy decision point (PDP), policy information point (PIP), policy retrieval point (PRP) and policy administration point (PAP). Several vendors sell what is called an “entitlement server” which often offers fine-grained access control in a proprietary way, and at the same time offers some XACML support. Depending on the specific vendors, this could be something as simplistic as being able to export a policy set in XACML (but often limited to export, i.e. not being able to import a policy that was generated by a different software). In some cases, an “entitlement server” can also act as a PDP – often supporting the XACML 2.0 protocol.
If you want to implement a XACML architecture you should therefore look at the required architectural components (PEP, PDP, PAP, PIP and PRP). Perhaps you could use something sold as an “entitlement server” to provide some of these components. Alternatively, you could go for a native XACML implementation such as the one that Axiomatics provides – in this case you have the guarantee that all of XACML’s features are there for you to use so that you can build fewer but more powerful policies as opposed to a larger number of primitive policies.
Q: Hello Felix, to make all this to work the target application must support XACML. Can you say a few words on that?
Not necessarily. In some cases, access can be controlled through gateways or filters. This is usually the case for message buses or queueing systems, or SOA services. Also, application servers/servlet engines can implement filters that don’t require changing the target application. There are many other examples where it is possible to control access with an agent as well, without the application knowing anything about XACML.
In order to use externalized fine-grained authorization though, the application should externalize its access control. This does not necessarily have to mean that the application needs to use and understand XACML. Instead, if the application externalizes authorization through an interface, it is then possible to connect this interface to a XACML-enabled policy engine. Of course there are also externalized authorization frameworks that are XACML enabled, and they are quite simple to use. At the end of the day though it is important to understand that an application does not have to know about XACML necessarily, but instead it should know about externalizing authorization and using attributes.
Axiomatics is the leading provider of fine-grained access control. Axiomatics’ solutions are utilized by government agencies and Global Fortune 1000 companies around the world to enable digital transformation: share and safeguard sensitive information, meet compliance requirements, and minimize data fraud. Axiomatics provides Attribute Based Access Control (ABAC) for applications, databases, Big Data, APIs and microservices. To learn more please visit: www.axiomatics.com or @axiomatics.
The march of the cloud is unstoppable. Eager to outsource the tedious and expensive maintenance of their IT infrastructures to a reliable 3rd party, most companies would dream of becoming cloud-native, at least in the long term. Needless to say, letting someone else run your identity management out there sounds like a great idea as well, hence the rising popularity of Identity-as-a-Service solutions that combine the latest technology achievements with the flexibility of the cloud.
Come to the place where the Digital Transformation is happening. The European Identity & Cloud Conference, held from May 14-17, 2019, offers a mixture of best practice discussions, visionary presentations, and networking opportunities with a future-oriented community. More than 800 thought leaders, leading vendors, analysts, executives, and end-users get together in Munich to be inspired by a list of world-class speakers.