The XACML Enabled Gateway The Entrance to a New SOA Ecosystem

Transcription

1 The XACML Enabled Gateway The Entrance to a New SOA Ecosystem White Paper Intel SOA Expressway and Axiomatics Policy Server Solution Intel SOA Expressway and Axiomatics Policy Server combined provide a reference perimeter security, governance, and XACML policy enforcement model for new applications with an ability to retrofit existing infrastructure without intrusion Introduction to the Problem From top of the hype to utter despair SOA has in a few years evolved from representing what was a solution to seemingly every business problem to instead being itself a main business concern. The notion of service orientation most certainly is here to stay but many great expectations have turned into disappointments and sometimes lead to a frustrated prediction that SOA is dead. The primary strength of SOA becomes a weakness if not handled with care: fast, flexible and agile alignment of IT with changing business requirements a promise on which SOA has delivered enables swift realization of new information flows and empowers business process owners and users to leverage new investments for faster ROI. However, poorly managed SOA initiatives create uncoordinated or even incompatible information models for data in transfer and at rest.

2 Table of Contents Introduction Background on the Gateway Externalizing Authorization The ABAC Approach XACML - a Policy Language and a Generic Architecture Intel SOA Expressway with APS Federation and Cross-domain Data Exchange Benefits of Combined Solution Summary

3 Introduction to the Problem (con t) Part of the reason SOA promises could not be realized earlier had to do with overuse of complex multi-layered SOA infrastructure based on Enterprise Service Busses, or ESBs. For example, most of these SOA architectures, required separate components for Identity related functions such as Authentication & Federation, separate one for Workflow processing, another for runtime security enforcement such as encryption, and yet another for handling common Service invocation patterns. It is not that this multi-layered SOA architecture is not required, it is in fact, absolutely essential for business unit level or micro-domain level Service orientation, but overkill and hindrance to agility for Enterprise-wide SOA. So while ESBs are great at core integration and service sharing efforts within sub-domains, there is a need for a more specialized and highly scalable infrastructure to drive SOA at the enterprise levels. The concept of Enterprise Service Router and its realization as Intel SOA Expressway is the essence of the approach: it provides a a layer of technology underneath these micro-domains that provides for scalable and secure access to both services and information by any number of consumers. In other words, a technology that functions like a network router, making sure that the services are available to those who need them, just like packets routed by a switch within a network. In this new SOA re-born era, services can be REST or SOAP based, and they could be in-house, mashed-up, or on a public cloud making Enterprise perimeter somewhat moot. Services typically land on public or private clouds that can be managed as set of infrastructure services themselves. In order to govern, secure, accelerate and route services, an Enterprise Service Router can enforce Service AAA (Authentication, Authorization, Auditing), enable message exchange patterns and related dataflow, and enforce XML Firewall and Quality of Service policies. Policies remain dynamic, based on standards such as WS-Security Policy & WS-Policy, and are executed with minimal latency overhead. The common notion in policies is of Externalization, that is, externalizing attributes that are required to be made available at the Enterprise or Cloud level in order for Service to be truly useful by any consumer. The focus of this paper, of course, is externalization of one of those key attributes for Services, namely, Authorization. White Paper: Intel SOA Expressway and Axiomatics Policy Server Combined SOA has made apparent that the established approach to Identity and Access Management (IAM) fails as infrastructures become increasingly capable of dynamic adaption to changing needs. Who is actually able to gain access to which data, where, when and why? From a Governance, Risk and Compliance Management (GRC) perspective these questions are becoming increasingly important as SOA helps tear down the barriers of old security domains. Whether in egovernment, online banking, B2B services, cloud computing or elaborate sourcing, SOA plays an important part in our move towards global cross-domain connectivity in which fine-grained and contextaware access control has become more important than ever. Established IAM concepts based on centralized identity management with user privileges being provisioned to a presumably fairly static set of applications is simply inadequate in environments where data is streaming to users in mash-ups blending output from multiple services. It is no longer possible from the perspective of a single application or service to foresee in which context data will be presented. As a result, authorization of users cannot be dealt with from within this narrow scope. Instead, authorization decisions need to be based on policies that are derived from and adequately express business rules themselves being subject to constant change rather than the relations of intricate but static business objects within a single application. Rather than provisioning user account data to applications we need to provide applications with real-time services intelligently ruling whether a user s access to specific information in a given context complies with current overall business rules or not. It follows that IT organizations with a portfolio of business-critical service oriented architectures need to enforce policies for SOA governance in general and for authorization in particular.. Combined, Intel SOA Expressway, the best-of-breed XML Security Gateway on the market, and Axiomatics Policy Server, the world s leading XACML implementation, address these new challenges. 3

4 Background on the Gateway Intel SOA Expressway is an efficient service router that combines the capabilities of a service bus with those of a security gateway and an XML acceleration engine. It provides universal SOAP or REST message level security, service virtualization, delegated AAA functions and threat prevention to ensure runtime governance and web services security. For more information about these general capabilities of the Intel SOA Expressway, refer to documentation available on the Intel SOA Soft- Appliance website - The focus of this paper is on the potential offered by the AAA functions of Intel SOA Expressway and specifically the ability to translate an incoming call to an XACML based authorization request. The Intel SOA Expressway can be configured to enforce any necessary authentication and authorization requirements as defined by applicable policies via calls to relevant authentication and authorization services respectively within the domain. SOA Expressway can verify the identity of a user from an incoming request by means of routing the call to the appropriate authentication service as mandated by applicable policies. It can then automate the creation of a SAML ticket and the generation of an XACML authorization request. This request can be configured to include not only relevant user attributes retrieved from authentication or user session parameters but also the necessary attributes of the resource to which access is requested. In other words, the Intel SOA Expressway can be used to implement a versatile XACML Policy Enforcement Point (PEP) placed in front of a domain, thus enforcing fine-grained and context-aware access controls to protect information sources even for already deployed services which natively did not have these capabilities. 4

5 Externalizing Authorization the ABAC Approach With XACML a new generation of authorization architectures is introduced. Attribute-Based Access Control (ABAC) goes beyond Role-Based Access Control (RBAC), the model which in recent years has been the most common approach. RBAC is used to define a relation between a set of users on the one hand and a set of permissions on the other hand. The overall objective has been to simplify user administration by means of categorizing and grouping individuals with similar profiles. Adding permissions to a role implicitly means granting these permissions to all users assigned to that role. Adding users to a role means granting all role permissions to these users. This concept is well aligned with needs emerging out of conventional IAM solutions. Once user administration has been centralized, the administrative burden of mapping many privileges to many users becomes quite overwhelming and the role concept then appears as an attractive simplification. ABAC, in contrast, does not focus on the grouping of users but goes beyond. It is based on the conclusion that any semantically meaningful and syntactically correct statement about an access request includes four essential building blocks: a subject or user, an action, a resource and the environment in which access is requested as illustrated by the table below: White Paper: Intel SOA Expressway and Axiomatics Policy Server Combined Each of these four parts can be described using attributes derived from business processes which in turn establish the context of business rules governing access. Let us for instance think of how access control may have to be enforced in an R&D environment in a project oriented organization. Essential documentation relates to a specific Project ID and Product ID respectively and the group of authorized users must be limited to those with a relation to the project/product. In heavily regulated industries, access control may have to take more or less elaborate data classification schemes into consideration as well as mandated by applicable external compliance regimes. Change management processes set gates with clearly defined conditions for read and/or read-write access to specifications and development plans once frozen a specification or plan can no longer be altered. Business rules may thus establish that only the project lead or program manager can update specifications whereas all project members should be granted read access. If information about the product due to external regulations is classified, further restrictions may need to be imposed as well; the nationality, certification, competence or clearance level of the user may have to be considered. Furthermore, access should perhaps be restricted to normal working hours and the physical premises of the plant. Access rule can thus be expressed using a number of attributes derived from a related business process: 5

6 if the user s project membership is the same as the project ID of the information object requested then permit else deny if the product classification is less than 3 and the user s clearance level is 2 or higher then permit else deny if the action is check-in and the data type is specification or project plan and the user role is project lead or program manager then permit else deny if the action is check-in and the data type is specification or project plan and the project state is not frozen then permit else deny If the user s location can be verified as within premises based on IP-address or perhaps based on a time stamp from a physical card entrance system then permit else deny Etc. An attempt to handle access rules of this type using an RBAC model typically leads to role explosion, especially when dynamically changing conditions need to be considered such as project state, time of day or location. XACML - a Policy Language and a Generic Architecture The extendable Access Control Markup Language, XACML, defines a formal syntax for the definition of access policies and a format for a request/response protocol for access requests. It is a well-defined standard with broad recognition in the industry, authored and maintained by the OASIS XACML Technical Committee. It is therefore the obvious choice for an implementation of Attribute-Based Access Control (ABAC). But XACML is not only a standard for access control based on policies. It also implicitly suggests a generic architecture as illustrated below: 6

7 The Policy Decision Point (PDP) is a centralized instance that takes on the crucial task of comparing an XACML access request with existing XACML policy definitions to resolve the request with a permit or deny answer. The PDP and the related Policy Administration Point (PAP) are components used to implement centralized authorization management. The PEP, in contrast, enforces authorization decisions made by the PDP locally within or in front of the application or service which it protects. The Axiomatic Policy Server is a pure XACML 2.0 and 3.0 implementation for complete policy life-cycle management. It comes with a patent pending technique for policy synchronization in multi-pdp deployments and a PAP with advanced policy modeling and debugging features. These are the components combined with the PEP of the Intel SOA Expressway in the conceptual solution presented here. Intel SOA Expressway with APS The strength of XACML is fairly obvious and the need for externalization is becoming broadly recognized. However, while it may be an obvious choice for new service deployments, incorporating existing infrastructures into the domain of an XACML PDP may be more of a challenge. This is where the combination of the Axiomatics Policy Server with the Intel SOA Expressway offers a strong value proposition. With the SOA Expressway, already deployed SOA domains can be incorporated into a domain of XACML controlled policy based access control. SOA governance policies of the SOA Expressway can even mandate attribute gathering beyond what is given by the initial request. If attributes of the user in addition to what is known from authentication or session parameters need to be considered the SOA Expressway can gather such information from a related LDAP source. If resource classification or other meta-data about the request must be gathered, the SOA Expressway can be configured to do separate queries to application servers within the domain. The combination of Intel SOA Expressway and Axiomatics Policy Server thereby introduces an extremely flexible protective shield with which already deployed as well as new services can be made subject to an organization s established policy governance. In the conceptual solution illustrated below, the SOA Gateway gathers user and resource attributes in accordance with the OASIS XACML.3.0 Export Compliance profile, Version 1.0, before sending an XACML request to the Axiomatics Policy Server. A use case of this type could for instance be relevant in environments similar to the R&D example discussed above. 7

8 Federation and Cross-domain Data Exchange A scenario like the one above becomes even more compelling in environments where multiple security domains may need to exchange information. Since the Axiomatics Policy Server fully implements and supports the new XACML 3.0 notion of Delegation, federation of administrative policy management privileges can be supported across security domains. A provider of services could for instance delegate administrative privileges for a defined subset of users or resources to the policy administrator of a client.. Benefits of Combined Solution The value proposition of these two products combined can thus be summarized: XML Gateway and XACML Authorization combined: SOA governance and XACML Policy enforcement for web service security provided through SOA Governance and XML firewall features of the Intel SOA Expressway are combined with the Axiomatics Policy Server s attribute-based authorization. Different types of vital security and operational / performance related policies can thus be enforced from a central point. Performance and security gains: The XML acceleration capabilities of the SOA Expressway help combine performance gains with essential information security improvement governance. Non-intrusive GRC enforcement retrofitted: Attribute-based Access Control capabilities can be retrofitted to include already deployed services in a non-intrusive way. Cost-reduction for deployments: The time and efforts needed to deploy new services can be dramatically reduced for new services deployment. 8

9 Where to find out more Intel Contact us by . About SOA Expressway SOA Expressway is a soft-appliance deployed to address common XML and SOA problem areas such as acceleration, security, service mediation and service governance. SOA Expressway is available for any organization deploying services (SOA), hosted services (SaaS) or Web 2.0 (RIA). SOA Expressway is available for standard operating systems such as Windows* and Linux* and requires no special custom hardware other than standard OEM servers. For more product information: For more comparison information and to register for Webinars: Contact us by phone Americas UK and Ireland: 44 (0) All other Geographies: White Paper: Intel SOA Expressway and Axiomatics Policy Server Combined Axiomatics Contact us by . info@axiomatics.com sales_emea@axiomatics.com sales_us@axiomatics.com About Axiomatics Policy Server Axiomatics Policy Server implements the complete XACML 2.0 and 3.0 specifications consistently which means it not only handles XACML request/response but also maintains its policy store according to the XACML specification. This way the Axiomatics Policy Server supports policy exchange through export/import for optimized interoperability. Axiomatics Policy Server comes with a versatile Policy Administration GUI with built in modeling and debugging tools in addition to a complete set of policy life-cycle management features. A patent pending technique can be used for policy distribution in multi-pdp environments allowing subsets of a policy store to be replicated in real-time to related PDPs. For more product information: For more comparison information and to register for an Evaluation Download: Contact us by phone All Geographies: +46 (0) Performance tests and ratings are measured using specifi c computer systems and/or components and refl ect the approximate performance of Intel products as measured by those tests. Any difference in system hardware or software design or confi guration may affect actual performance. Buyers should consult other sources of information to evaluate the performance of systems or components they are considering purchasing. For more information on performance tests and on the performance of Intel products, visit Dates and plans are preliminary and subject to change without notice Intel may make changes to specifi cations, release dates and product descriptions at any time, without notice. For processors with HT Technology, performance and functionality will vary depending on (i) the specifi c hardware and software you use and (ii) the feature enabling/system confi guration by your system vendor. See for information on HT Technology or consult your system vendor for more information. For more information go to: Intel Corporation. Intel, Intel logo, Intel Inside logo, and Core are trademarks or registered trademarks of Intel Corporation, or its subsidiaries in the United States and other countries. * Other names and brands may be claimed as the property of others. Printed in USA Please Recycle SOAE-XACML White Paper 9