Archive for the ‘XACML’ category

Talking authorization with Gunnar Peterson

December 15, 2010

Gunnar Peterson and I had a discussion about why authorization should start to receive more attention in the infosec industry. He feels that most infosec pros are over emphasizing authentication and it’s time to look more toward authorization. Since I now work for Axiomatics, I couldn’t agree more :-). Here is a transcript of the conversation:

GP: Authentication gets so much attention in security, for example there are dozens of authentication types supported by SAML. This is due to the many, many attempts that people have made in improving authentication over the years, but authentication is really a guess. There are ways to make better or worse guesses, but once that guess is bound to a principal, the game changes. Authorization is mainly about solving puzzles (not guessing), it seems to me that infosec as a whole should spend more time getting their “puzzle logic” implemented right, ensuring that authorization rules have the coverage, depth and portability. Why is it that people have been so easily seduced by authentication and what can we do to get people to focus less on this quixotic pursuit and onto more solveable problems like authorization?

GG: The focus on authentication, in many ways, is justifiable because much authorization was embedded within the authentication process. If you can authenticate to the application, then you have access to all the information – in a general sense. This approach is manifested in many legacy applications, early security perimeter strategies, and first generation portals. In today’s environment, authorization approaches must be much more discriminating due to regulatory, privacy, or business requirements. Further, the number of applications or resources that are not shared with an outside party has essentially been reduced to zero – the most valuable assets are the one of most interest to your partners and customers. This transition from “need to know” to “need to share” is shifting the focus to authorization and I believe we are seeing the early signs of enterprises placing more focus on authorization. Ultimately authentication remains important because we still need to know who is accessing the information although not necessarily their identity, but enough privilege granting attributes about them.

 

GP: What is driving this shifting focus towards authorization? How much is driven by the management of sharing problem present in today’s applications like Web applications, Web service, Mobile and Cloud, where architectures are so distributed and occasionally connected that they are forced to authenticate in space and authorize in another? And how much is driven by the applications themselves becoming more sophisticated with more functionality, data and layers that require more fine grained authorization? Can general purpose frameworks like XACML help in both the technology architecture and the language expressiveness or are there different patterns required?

GG: There are many forces at work that are changing the perspectives on how identity management functionality and services should be implemented. First, it is quite logical to have authentication taking place completely disconnected from the application or data resource – think of the federated model. Second, applications are much more sophisticated than what was being developed even a few years ago. The level of complexity and granularity must be met by an equally sophisticated and comprehensive authorization scheme. Finally, XACML is well suited to meet the complex requirements we are referring to. XACML is a mature standard (work on it began in Feb 2000) that is comprised of a reference architecture model, policy language and request/response protocol. The XACML architecture is well suited to protect application resources whether they are centralized in your data center or distributed across the data center, private clouds, public clouds, partners, etc. And the core XACML policy language, plus profile extensions such as the hierarchical resource profile, is capable of modeling very complex business rules that will address the vast majority of use cases.

 

GPBob Blakley’s paper on “The Emerging Architecture of Identity Management” from earlier this year described three architecture models – first a traditional Push model, then a more dynamic future state based on a Pull Model, and a third hybrid model to move from Push to Pull to help enterprise to make incremental progress. The pure Pull model looks to solve what I regard as the single biggest security issue we face today – poor integration. Can you discuss how XACML based architectures play a role in these Push and Pull models, is XACML applicable in all models or are some more in its sweet spot than others?

GG: In fact, Bob includes XACML in his emerging architecture – referring products of this class as ‘XACMLoids.” The primary value XACML brings is in externalizing authorization from business applications – “Externalized Authorization Managers” is another excellent report that Bob has recently written on this topic.

In the Push model, XACML systems have a smaller role since identity data is synchronized with or pushed to the application specific identity repositories. In the Pull model, applications call out to the XACML service for authorization decisions using the XACML request/response protocol. If additional attributes are needed to make an authorization decision, the PDP engine can retrieve attributes through a virtualization service. XACML works equally well in the hybrid model – the difference here is that the application does need to persist some identity information in a local repository. That said, the sweet spot for XACML-based systems is likely the pure Pull model or the hybrid scenario.

 

GP: So beyond, the XACML language framework can you briefly describe the components that an authorization system needs to implement XACML architecture in the pure Pull and Hybrid scenarios?

GG: The components identified in the XACML reference architecture are:

Policy Decision Point (PDP): this component receives access requests, evaluates them against known policies, and returns a decision to the caller

Policy Enforcement Point (PEP): this component is located at or near the resource and can be integrated as a gateway, co-located with the application, or embedded within the same process as the application. PEPs basically construct the request in XACML format, forward it to the PDP over a particular protocol, and enforce the decision returned from the PDP

Policy Information Point (PIP): XACML is an attribute based access control (ABAC) model and therefore thrives on attributes. If the PEP does not send all the necessary attributes in the request, the PDP retrieves the additional attributes via the PIP interface.

Policy Administration Point (PAP): Here the policies are written, tested, and deployed – all the expected policy lifecycle management functions.

Policy Retrieval Point (PRP): This is where the policies are stored by the PAP and retrieved by the PDP.

 

GP: Given that logical architecture, what do you typically see or recommend in terms of physical deployment? Seems like a minimum would include separate PEP, PDP, and PAP instances. The PIP and PRP would be combined with PEP/PDP and PAP respectively. Is this is a way to get started on building the foundation?

GG: Some of these deployment configurations will be product dependent, but in general here are tome typical topologies for an XACML system:

1. Shared PDP service: You should have at least 2 PDP instances for availability and business continuity. Additional PDP instances can be deployed for scalability as each server instance is stateless.

2. Embedded PDP: For low latency scenarios, the PDP can be embedded directly in the application container

3. Attribute sources: The PDP, via the PIP interface, can connect to several attribute sources directly as one option. A second option is to use a virtual directory as the attribute source manager. Finally, when a persistent, consolidated attribute store is required then privilege granting attributes can be synchronized into a directory.

4. PAP service: Typically this function will be run in an offline mode. Most of the work happens when a new application is onboarded to the environment and we find that XACML policies are quite stable and don’t require daily or even weekly adjustments.

5. PRP repository: Obviously the PAP will store XACML policies in the repository but the enterprise may have a preferred option for putting policies into production. Operational procedures must also take into account how many PDPs are installed locally or distributed throughout the network. For example, you could utilize database or directly replication to promote new policies into production.

6. PEP integration with applications: Here you can get started by integrating the XACML system with an XML gateway as a great way to get started, which has a low impact to the existing environment. For more advanced scenarios, you can integrate application environment specific PEPs into your business applications.

 

GP: I look at the domain of information security like a triangle – there AAA services for Identity and Access Management, Defensive Services like monitoring and logging, and finally Enablement services that help to integration AAA and Defensive services in to the organization. XACML was designed to handle parts of the AAA and Enablement challenges, but how can we use XACML and authorization services to improve our Defensive posture? What ways have you seen to implement more robust logging and monitoring through the Authorization layers?

GG: The XACML PDP engine should be instrumented so it can provide important information to the logging and monitoring apparatus of the enterprise. At the basic level, the monitoring system can track the number of permit and deny decisions to watch for anomalies. Further, alerts can be triggered if certain thresholds are exceeded – maybe the same user getting repeatedly denied access or a particular IP address making excessive requests.

 

Discussing XACML with Travis

October 6, 2010

Travis Spencer (@travisspencer) raised a few issues with XACML and proposed some solutions in a recent blog post. I’d like to take this opportunity to respond in the interest of continuing the conversation. Thanks to my colleagues, Erik, David (@davidjbrossard), and Ludwig for their input.

Point 1 – Lack of wire protocol definitions: The industry is limited to a single wire protocol spec at the moment, the SAML profile for XACML. It is by no means universally applicable but is useful when integrating with other vendors’ policy enforcement points (PEP). Such is the case for integration with XML security gateways. We agree that other wire protocols are needed and expect that they will emerge over time, as the market demands them. This will require a combined effort between XACML vendors and experts in the particular protocol domains of interest. Once the industry reaches a point where multiple protocol profiles are created, then formal certification and interoperability testing may also be required – similar to the SAML profile testing that occurs today. Finally, I invite you to join the TC and provide your use cases as input!

Point 2 – Cryptographically binding attributes to a trusted IDP: There are cases where a cryptographic chain can be established between the IDP and PDP – as Craig Forster described in a comment to the original post. That is, a SAML token can be passed from the PEP to the PDP and the PDP can perform signature validation. However, this doesn’t address all possible scenarios as there are many ways that attributes can reach the PDP. In federated scenarios, a token of some sort may contain attributes, but this represents only a portion of use cases. The PEP may derive attributes from a local repository and it, of course, may send environmental attributes in the access request to the PDP. The PDP may also query additional sources for necessary attributes before making an access decision. These sources could include a local LDAP directory, web service, or customer database. The PDP could also query a remote source, as defined in the Backend Attribute Exchange (BAE) profile. Therefore it may not be practical, or possible, to implement cryptographic bindings all the way to the attribute source.

It is true that the PEP and PDP operate in a trusted ecosystem – that includes the application itself as well as other infrastructure components. XACML was intentionally designed in a modular fashion to cleanly separate authorization from other IdM functions, such as authentication. Security mechanisms are implemented to secure the communication between PEP and PDP components, but there also is a certain amount of trust between the components. For example, the PDP must “trust” that the PEP will actually enforce decisions properly and carry out all obligations. The PDP must “trust” the contents of access requests from the PEP, including the attributes about the subject. In such cases where additional context is needed, the PEP can send subject attributes plus the source (issuer) of the subject attributes – it’s just another XML string.

Point 3 – Policy authoring and administration: The XACML policy language was developed to address a broad range of application scenarios and to satisfy the complex requirements of sophisticated applications. As such, XACML is a rich language and it must be, otherwise we would be debating whether it is comprehensive enough. Based on our experience at Axiomatics (@axiomatics), if you simplify the policy authoring tool – you lose some of the XACML functionality. Some clients choose to create domain-specific and simpler admin tools but these are only used after the initial set of policies has been created. A couple other observations may be helpful. First, XACML policy development takes some effort up front, but the policies are typically quite stable and do not need a lot of manipulation. Second, the more frequent activity is management of user attributes during onboarding or when the user’s status changes. Finally, we expect more domain specific policy administration tools to emerge in the future as the standard is adopted more broadly.

In summary, I thank Travis for raising points that are issues from his perspective. XACML is not perfect but then no technology is. However, the standard and products that implement it will continue to improve over time based on experiences from production deployments across many industries. We think that XACML is a very comprehensive and capable specification – and we are seeing many leading organizations choosing to deploy it already today. They recognize the value of standards-based, externalized authorization as a competitive advantage and a vast improvement from previous models.

Lastly, I invite everyone to attend our webinar on XACML and the ‘200M’ user deployment this month (October). More information on the event can be found here.

Instigating Again – XACML 3.0 Interop

August 4, 2010

One of the points I made during my vendor lightning round session at Burton Catalyst last week was that the industry should be looking ahead to an XACML 3.0 interop in 2011, perhaps at the next Catalyst conference. Catalyst was the site of the first ever XACML interop demonstration back in 2007 and would be a great venue again next year. It is expected that more vendors will adopt version 3.0 once OASIS completes formal standardization (currently a committee draft and will shortly be voted on as committee standard).

There are some basic usage scenarios that can be tested, such as implementing policies authored in one vendors PAP in another vendor’s PDP. Another scenario that is frequently mentioned is integrating a PDP with other vendor’s PEPs. What scenarios are most important to you?

Another item to consider is whether the industry needs certified conformance testing of XACML products. This capability has been very valuable to the federation market, but there is a lot of ambiguity today for externalized authorization manager products. If vendor products were certified as conformant by independent party, would that be valuable to you?

Finally, interoperability and standards conformance are more important than ever for the externalized authorization manager market. Demand is increasing from enterprises, SaaS vendors, cloud service providers, and others. These prospective implementers of XACML-based solutions must be confident of the functionality supported in commercial products and they should have a clear understanding of interoperability capabilities. That is why we are calling on other XACML vendors to join us in planning for the next interop event and also to seriously consider sponsoring a certification process.

image credit: http://instigate.co.uk/InstigateCop.jpg

Diagramming XACML Performance

July 14, 2010

In a previous post discussing XACML performance myth-busting, I described several areas in an XACML authorization system where performance issues can be addressed. Since then, my colleague David Brossard created the diagram below to illustrate potential performance bottlenecks.

To refresh your memory, here is the issue for each numbered item in the diagram (see the previous post for explanations):

  1. Policy Retrieval
  2. Policy Matching
  3. Attribute Retrieval
  4. Decision Caching
  5. Multiple Requests
  6. PDP – PEP Interaction

Authorization Performance Myth Busting

April 30, 2010

It’s a common misconception that XACML authorization systems perform poorly by default because they are XML-based. While it is true that XML systems can be slow, XACML product vendors have many techniques at their disposal to address performance concerns. Keep in mind, however, that every application and every deployment has its own performance considerations and will require individual analysis. Therefore, this post lists the main bottleneck points for performance and discusses some alternatives for each.

Policy Retrieval: When resources are accessed, the authorization system must find the right policy to evaluate. If the PDP is going to the database or file system to retrieve policies during runtime, you can degrade response time considerably. An alternate approach is to load all policies into memory at PDP startup. XACML policies are not excessively large, so memory usage is not an issue.

Policy Matching: Policy modeling and structure directly impact how quickly a PDP can find the right policy to evaluate. Application access patterns must be studied to determine the most efficient policy structure for rapid matching and evaluation.

Attribute Retrieval: Attributes are the lifeblood of an XACML system and their inefficient retrieval can contribute to poor application performance. Attributes can be incorporated into the authorization process from many entry points: 1) the PEP can gather attributes from the user session or service request, 2) the PEP can retrieve additional attributes from enterprise systems and repositories before making the access request, 3) the PDP can retrieve yet more attributes from similar sources before evaluating a rule, 4) you can have all of the above in a given scenario.

If multiple attributes are sourced from the same repository, they can be retrieved with one call, instead of making a call for each attribute. Caching can also be useful to retain in storage attributes that are frequently used by the PDP. Attribute retrieval can also be triggered during policy matching, allowing the PIP interface to “look ahead” for attributes once the PDP knows which policy will be matched. Finally, if an attribute repository is known to be costly to fetch, it should only be utilized in policies that are infrequently called.

Decision Caching: In certain cases, the PEP can cache access decisions so that the PDP does not have to be invoked for each access request. This technique is useful where similar requests would result in the same outcome due to the structure of policies or due to the nature of the request.

Multiple Requests: It is quite common that multiple decisions must be processed for a particular request, such as when a user is requesting access to a list of resources. Such requests will be more efficient if they are processed as a “multiple request” instead of a series of individual requests because there is less transport overhead and the PDP can optimize the request knowing it is for the same subject (user).

This reminds me that I recently heard a comment at an industry event where a vendor stated, “If you are rendering a web page with 50 authorizations in it, it is not possible if you do a SOAP call for each authorization.” Well, of course that is a correct statement but not exactly helpful to prospective customers that are considering deploying XACML authorization. This is precisely a case where multiple requests should be utilized and where more suitable enforcement points should be considered to avoid the SOAP overhead.

PDP – PEP Interaction: It is possible to implement a closely coupled PDP-PEP in order to reduce transport overhead. In addition, authorization systems should be able to support several types of transport mechanisms, such as web service, RMI, in process, or others. In extremely performance-sensitive cases, the PDP and PEP should be able to communicate via in-process calls for ultimate response times.

PDP Features: In general, the PDP is stateless, making it very easy to create several concurrent instances. These instances may run on separate threads (and thus leverage multi-core architectures) and/or on separate hosts to increase the capacity of the authorization system.

What have you done to address performance concerns??

Photo credit: http://bit.ly/aXnTlb

Myth Busting, XACML Style

April 6, 2010

MythBusters is a popular TV series that attempts to prove or disprove popular beliefs, rumors, or “myths.” Their topics have ranged from whether cell phones interfere with a plane’s instruments (they don’t) to whether a fingerprint reader could be spoofed (it was). In the realm of XACML, there are also what we would consider myths or at least mis-conceptions.

Over the next several weeks, I will address the following candidate myths and share some of Axiomatics’ perspectives. If you have others that should be added to the list, please let me know.

  • XACML will cause performance problems for my application
  • The XACML policy language does not cover my complex application scenarios
  • XACML authorization systems are not “stateful”
  • Administrators do not understand XACML
  • Another standard? Can’t we do this with SAML (addressed this one previously)
  • XACML is an immature standard
  • XACML does not define the communication protocol between PDP and PEP
  • XACML is only good for SOA deployments

Thanks to David, Erik, and Ludwig for their input

XACML workshops in San Francisco and Wash DC

February 19, 2010

Please join us in San Francisco or Washington DC for an XACML workshop.

“This is a two day XACML introduction course, including hands-on training. It will be provided by leading XACML experts with in-depth experience from some of the world’s largest XACML deployment projects. Based on their attendee experience, there will be a mix between high-level aspects and technical details. We cover best practices and discuss how you avoid common pitfalls in the deployment of an Attribute Based Access Control (ABAC) solution. However, we also ensure you get a thorough understanding of the XACML request/response and policy languages. You will create and debug your own XACML policies and run access requests against them to verify that you get the response you expect.”

San Francisco, March 9-10

Washington DC, March 16-17

*** ALERT: These workshops have been rescheduled – dates TBD! ***


Follow

Get every new post delivered to your Inbox.