In an enterprise SOA resources have become more centralized in order to be shared causing growing pains through a realization of necessary governance. One of the first concerns from management and business owners is that what they are offering within the scope of the SOA can be controlled with policies they establish as well as audited against adherence to those policies. Historically when application silos were built, tight control was available as most authorization for performing tasks within the application was either a function of the application container or the application logic itself. While network security, encryption, digital signatures, and strong authentication can be enabled consistently for SOA assets, what is challenging many SOA implementations today is how to adequately enable application authorization in an SOA context with coherent management capabilities. This white paper will attempt to outline the case for leveraging the move to an enterprise SOA as the perfect opportunity to enhance information assurance for the enterprise as opposed to allowing it to manifest itself as actual or even perceived gaps in controlling access to both SOA and legacy applications.
As the IT infrastructure has evolved over the last decades, many security, authentication, and authorization models have been introduced from ACF-2 to Top Secret and RACF for the mainframe to LDAP and Active Directory for UNIX and Windows. Given what these services provide to the overall effectiveness and risk management of applications they are certainly an intrinsic part to the fabric that provides the necessary components for making applications available to diverse user populations. Most of these offerings sprang from vendors and generally support an open standard (LDAP) for storing user accounts and passwords in a variety of contexts within an LDAP ‘tree’ that is queried at logon to yield what’s known as an ACL (Access Control List). An ACL is essentially a ‘key’ in the form of the total resources that the user will have access to that are also protected within the LDAP directory.
The challenge with this path of evolution is that while given a standard repository with which to store information many vendors have chosen either to extend the repository to suit their own needs or to remain in a proprietary security mechanism that likely originated prior to the advent of LDAP. While it would be ideal to believe that all applications conceived after LDAP actually leveraged it to store security information, this is not the reality. Many applications are able to leverage LDAP for user authentication so you do not need to manage a separate user database for the application’s authentication, however the applications that facilitate authorization of users in this same fashion is an extreme minority. Microsoft Windows leverages Active Directory as a method of Single Sign On to enterprise resources but even they do not provide automated access to much else other than shared network file systems and printers. In fact, one of the only applications entirely integrated with Active Directory is their flagship enterprise email server, Exchange.
While IT began rolling its own authorization and in many cases authentication mechanisms, the software vendors were busy performing an acquisition spree around an application suite pattern known as ‘Identity Management’. The vendors that have an LDAP offering themselves provided customizations to LDAP in order to support a single sign-on within their own group of applications. They soon discovered that as they began to acquire more vendors and their applications, that an external, homogenized mechanism used to provide ‘security as a service’ within their own suites was becoming of paramount importance. These Identity Management suites consist mainly of identity provisioning, or the act of creating user accounts on systems as well as access control through groups or roles, or protecting access from a single authority to resources such as URLs, APIs or lower level access like SQL databases or Message Queues.
The industry eventually came up with a more robust XML based standard that could be embedded in SOA requests called SAML (Security Assertion Markup Language), which facilitates the trust relationship between these security directories. This standard allows you to federate identity, authenticate, and authorize across applications that trust the provider of SAML tokens. The authorization mechanism of SAML however, is limited, and provides an answer to whether or not someone is associated with a particular thing as well as providing information on whether or not someone has access to a particular resource after authentication. These items are of great use in constructing an audit trail of who did what and when but in the end falls short of enterprise policy compliance audit needs.
The next step in creating standards for making service oriented authorization a reality for SOA (Service Oriented Architecture) was the formation of XACML (eXtensible Access Control Markup Language) which provides a way to hold rules about making authorization decisions. These authorization decisions, essentially a yes or no answer based on who is asking to perform what action to which object, are invoked by a PEP (Policy Enforcement Point or something that protects a resource) when a request is made of that resource. The rules for evaluating the requested access is executed by a PDP (Policy Decision Point) that has access to the rules stored in a PAP (Policy Access Point). This mechanism is essentially providing much the same answer that an Active Directory request would in the form of an ACL, but it is externalizing the decision itself by analyzing what may be a resolution of intersecting hierarchies or authorities. This is critical for centralizing this behavior and getting it out of the hands of a diverse developer population of SOA services.
As was mentioned earlier one of the barriers to sharing in SOA has been the ability to effectively define, govern, and audit these types of policy. This holds even truer when we are dealing with Federal Agencies tasked with providing national security. You need look no further than a recent attempt to share and federate information across these agencies called Railhead to find the challenges in dealing with sensitive data and chain of authority operations on shared services even as simple as search applications. When XACML is the default method for securing your SOA as well as Portal and Web 2.0 applications, the benefits of a single central manager for policy overcome many of these challenges. In fact coupling this layer with secure database mechanisms such as Oracle’s Database Vault, Virtual Private Database, and Label Security you can increase DCID Protection Level compliance and defend against becoming a privacy concern for the public even where sensitive documents subject to redaction are the SOA payload.
Enterprise logging mechanisms such as ArcSight provide collecting and reporting on a wide range of enterprise application logs. Logging with this homogenized approach facilitates those things compliance auditing is most concerned with, such as easier preparation for insight into who knew or did what, when and how that are key tenants of information assurance building on top of cryptographic non-repudiation. There are many active risk management solutions coming from industry that essentially put network intrusion detection into the application layer by leveraging this type of usage, policy, and log data. Another beneficial application of the data coming from this type of solution is the ability to actively mine and manage roles, discovering which tasks may be better suited in different portal regions or which human resources may augmented by offloading or automating certain tasks.
At the end of the day for SOA to be a success in the federal government but given the demand placed on exposing and sharing such sensitive data with policies that may change over time requires a homogenous way to define and audit those policies as well as offer a consistent model for consumers. SAML and XACML provide those in a vendor neutral fashion that satisfies other requirements inherently that have otherwise seemed unapproachable threat analysis and role management. If SOA is the façade for your legacy applications, then creating a service-oriented authorization layer ensures access to these systems is performed in a secure, manageable and perhaps most importantly, readily auditable fashion.
No comments:
Post a Comment