What follows is a conversation I had with Gerry Gebel on authorization and XACML. Gerry Gebel was formerly with Burton Group and is now President of Axiomatics (America). Axiomatics focuses on authorization and the XACML standard. These topics are important and do not lend themselves to sound byte chunks, I asked Gerry a number of questions on the space and found his answers quite interesting on authorization technology and trends.
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.
GP: Bob 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.
Part of the Conversation is here
Comments