Tag Archives: Web Services

Securing OData

Posted on November 27, 2010 | Leave a comment

One emerging technology that has recently caught our attention here at Layer 7 is the Open Data Protocol, or OData for short. You can think of OData as JDBC/ODBC for the web. Using OData, web developers can query data sources in much the same way they would use SQL. It builds on the basic CRUD constructs of REST, adding the Atom Publishing Protocol to help flesh out the vision under a very standards-oriented approach. OData’s major promoter is Microsoft, but the company is clearly intent on making this protocol an important community-driven initiative that provides value to all platforms.

I like OData; but as with any power tool, I approach it with care and some suspicion. I definitely agree that we need a formalized approach to interacting with Web data sources. OData is not SQL, but it brings enough familiar constructs with it to make the protocol easy to pick up and tremendously versatile. But OData also raises some significant security issues that need to be carefully considered before it is deployed.

Most applications are designed to constrain a user’s view of data. Any modern relational database has the ability to apply access control and limit a user’s view to the records to which they are entitled. More often than not, however, the enforcement of these entitlements is a task delegated not to the database, but to the application that interacts with it.

Consider, for example, a scenario, where a database makes a JDBC or ODBC connection directly available to clients outside of the corporate firewall:

It can be extremely risky to permit direct outside connections into a database.

People avoid doing this for a good reason. It is true that you can secure the connection with SSL and force the incoming user to authenticate. However, if an attacker was able to compromise this connection (perhaps by stealing a password), they could explore or alter the database at will. This is a gangster’s paradise.

A simple web application is really a security buffer zone between the outside world and the database. It restricts the capabilities of the user through the constraints imposed by elements that make up each input form. Ultimately, the application tier maps user interactions to explicit SQL statements, but a well-designed system must strictly validate any incoming parameters before populating any SQL templates. From this perspective, web applications are fundamentally a highly managed buffer between the outside world and the data—a buffer that has the capability of applying a much more customizable and rigorous model of access control than a RDMS could.

The Web application tier as security buffer between the database and the Internet.

However, this is also why SQL injection can be such an effective vector of attack. An application that fails to take the necessary precautions to validate incoming data can, in effect, extend the SQL connection right outside to the user. And unconstrained SQL can open up the entire database to examination or alteration. This attack vector was very popular back in the PowerBuilder days, but lately it has made a startling resurgence because its effectiveness when applied to badly designed web apps.

OData, of course, is the data source connection, so injection isn’t an issue—just getting a hold of it in the first place is enough. So what is critically important with OData is to strictly manage what this connection is capable of doing. OData servers need to provide not just authentication, authorization, and audit of the connection, but wholesale constraint of protocol function and data views as well. Web security demands that you assume the worst—and in this case, the worst is certainly compromise of the connection. The best way to manage this risk is to limit your exposure to what an attacker can do.

In SQL-terms, this is like limiting the functions that a user can access, and restricting them to the views to which they are entitled (and they shouldn’t be entitled to much). The danger with OData is that some of the tools make it much too easy to simply open a connection to the data (“click here to make the database available using OData”); this can have widespread negative consequences if an attacker is able to compromise a legitimate user’s account. If the data source cannot itself impose the necessary constraints on the connection, then an intermediate security layer is mandatory.

This is where Layer 7 can help. CloudSpan is fully compatible with OData, and can act as an independent security layer between the OData client (which may be a browser-resident application) and the OData server. It can offer not just AAA on the connection, but can narrow the OData API or mask query results based on an individual user’s entitlement.

CloudSpan Gateways managing access to OData data sources.

Here’s a real example that Julian Phillips, one of Layer 7’s architects, put together. Jules constructed a policy using the Netflix OData API, which is an experimental service the company has made available on the net. The Netflix API allows you to browse selections in their catalog. It has it’s own constraints built in—it’s already read-only, for example—but we are going to show how CloudSpan could be deployed to further constrain the API to implement stricter security protocols, and even enforce business rules governing access.

Jules’ policy is activated on all URI’s that match the /Catalog* patternthe entry point into the Netflix OData API. This shows up in CloudSpan under the service browser:

What we are going to do here is add some security constraints, and then a business rule that restricts the ability of minors to only view movie titles with a rating of G or PG-13. Minors can build perfectly valid Netflix OData queries and submit them to the API; however, these will be trapped by the CloudSpan gateway before they get to the actual OData server.

Jules’ basic policy is quite simple. We’ve collapsed some details into folders to make the basic flow easier to understand:

First off, the policy throws an explicit audit to capture both the URI and the query string for debugging purposes. We then ensure that the connection uses SSL (and subject to the cipher suite constraints currently in effect), and we mine HTTP basic credentials from the connection. Need Kerberos or SSL client-side certificate authentication instead? Just drag the assertions implementing either of these into the policy and you are good to go.

The gateway then authenticates the user against a directory, and from this interaction we determine whether this user is an adult or a minor based on their group membership. If the user is indeed an adult, the gateway passes their OData query to the server unchanged. However, if the user is a minor, the gateway adds constraints to the query to ensure that the server will only return G or PG-13 movies. For reference, the full policy is below (click to expand):

This example is somewhat contrived, but you should be able to see how the intermediate security gateway can add critical constraint to the scope of OData protocol. OData shows a lot of promise. But like many new technologies, it needs to be managed with care. If deployed securely, OData can become an essential tool in any web developer’s toolkit.

Advertisement

Leave a comment

Posted in Layer 7 Technologies

Tagged , , , ,

How to Fail with Web Services

Posted on November 19, 2010 | 1 comment

I’ve been asked to deliver a keynote presentation at the 8th European Conference on Web Services (ECOWS) 2010, to be held in Aiya Napa, Cyprus this Dec 1-3. My topic is an exploration of the the anti-patterns that often appear in Web services projects.

Here’s the abstract in full:

How to Fail with Web Services

Enterprise computing has finally woken up to the value of Web services. This technology has become a basic foundation of Service Oriented Architecture (SOA), which despite recent controversy is still very much the architectural approach favored by sectors as diverse as corporate IT, health care, and the military. But despite strong vision, excellent technology, and very good intentions, commercial success with SOA remains rare. Successful SOA starts with success in an actual implementation; for most organizations, this means a small proof-of-concept or a modest suite of Web services applications. This is an important first step, but it is here where most groups stumble. When SOA initiatives fail on their first real implementation, it disillusions participants, erodes the confidence of stakeholders, and even the best-designed architecture will be perceived as just another failed IT initiative. For over six years, Layer 7 has been building real Web services-based architectures for government clients and some of the world’s largest corporations. In this time, we have seen repeated patterns of bad practice, pitfalls, misinterpretations, and gaps in technology. This talk is about what happens when web Services moves out of the lab and into general use. By understanding this, we are better able to meet tomorrow’s challenges, when Web services move into the cloud.

1 Comment

Posted in Layer 7 Technologies

Tagged , ,

WS-I Publishes Basic Security Profile (BSP) 1.1

Posted on March 23, 2010 | Leave a comment

This morning the Web Services Interoperability Organization (WS-I) published the Basic Security Profile (BSP), version 1.1. This is a very significant milestone, because BSP is the definitive reference that we will all use to create secure and interoperable Web services for the foreseeable future.

I have a close personal connection to Basic Security Profile. I was one of the editors of both this specification and its predecessor, BSP 1.0. It took a lot of hard work to get this far, but the results of the our working group’s labours are important for the community. We all use Web services because of their potential for interoperability, but interoperability is only practical with the formalization that WS-I offers.

People have questioned the need for BSP in a world that already has OASIS WS-Security and the handful of WS-* standards that relate to it. The truth is, formal standards like WS-Security are so broad, complex, and new that it just isn’t realistic to expect vendor implementations to integrate perfectly. The WS-I approach differs from conventional standards efforts because the focus is strictly on promoting much needed interoperability. WS-I does not define new functionality, nor does it attempt to show people the “correct” way to use existing standards; it exists to profile existing standards by refining messages, amplifying important statements, and clarifying ambiguities so that systems from different vendors can communicate securely.

WS-I promotes interoperability by providing three important components: a profile of an existing standard (or set of standards), a suite of test tools to validate conformance, and finally sample applications. Microsoft’s Paul Cotton, the chair for the BSP working group, likens this to a three-legged stool—the effort can only stand when all three legs are present. This holistic approach taken by the WS-I distinguishes it from most standards efforts by including both specification and reference.

In the case of BSP 1.1, a very important component of the effort was the vendor interop. Six companies participated in this:

This is your short list of the vendors who are serious about Web services security. Obviously, we are the odd man out in terms of size and market reach, but we believe it’s important to drive the standards, not just implement them. And this is something we will continue to do. The days of big WS-* standards efforts are over. With the release of BSP, we have what we need to secure SOA. The next big challenge will be standardization of the cloud, and Layer 7 will be there.

Leave a comment

Posted in Layer 7 Technologies

Tagged , , , ,

REST Security Does Exist—You Just Need To Apply It

Posted on March 4, 2010 | 2 comments

On the eve of the RSA conference this year, Chris Comerford and Pete Soderling published a provocative article in Computerworld titled Why REST security doesn’t exist. It’s a prelude to a talk the author’s are delivering at the conference. Their premise is that while good REST security best practices do indeed exist, developers just don’t seem to follow them.

Comerford and Sodering attribute this state of affairs to a combination of two things. First, REST lacks a well-articulated security model. Few would argue with this—REST, by virtue of its grassroots origins, suffers from a security just-do-it-like-the-web nonchalance that’s certainly done it no favors.

The second issue concerns developers who tend to rush implementation without giving due consideration to security. Truthfully, this is the story of security across all of IT, but I might suggest that with REST, the problem is especially acute. The REST style owes much of its popularity to being simple and fast to implement, particularly when faced with the interest-crushing complexity and tooling demands of the WS-* stack. It’s reasonable to think that in the enthusiastic dash to cross the working application finish line, that security is conveniently de-emphasized or forgotten altogether.

REST, of course, can be secured, and the author’s offer sound advice to accomplish this deceptively simple task. They recommend that API developers:

  • “Do employ the same security mechanisms for your APIs as any web application your organization deploys. For example, if you are filtering for XSS on the web front-end, you must do it for your APIs, preferably with the same tools.
  • Don’t roll your own security. Use a framework or existing library that has been peer-reviewed and tested. Developers not familiar with designing secure systems often produce flawed security implementations when they try to do it themselves, and they leave their APIs vulnerable to attack.
  • Unless your API is a free, read-only public API, don’t use single key-based authentication. It’s not enough. Add a password requirement.
  • Don’t pass unencrypted static keys. If you’re using HTTP Basic and sending it across the wire, encrypt it.
  • Ideally, use hash-based message authentication code (HMAC) because it’s the most secure. (Use SHA-2 and up, avoid SHA & MD5 because of vulnerabilities.) “

I agree with this advice. And just to demonstrate how easy it is to implement, I’ve constructed a simple policy for the Layer 7 Technologies SecureSpan Gateway demonstrating their directives:

In this policy, I’m ensuring that the REST client is using SSL for three things: confidentiality, integrity, and server authentication. I could require client-side certificate authentication here, but instead I’m using HTTP digest, to emphasize the requirement to avoid using plain text HTTP basic or simple user keys. I’m authorizing access based on group membership here, restricting access to members of the sales group.

Finally, I’ve added a scan for cross site scripting attacks.

In the interest of deeper vigilance, I’m also searching for PHP and shell injection signatures. This is admittedly broad, but it covers me in case the developer of the service changes implementation without warning.

This last point—that there is an explicit separation made between developers and the security administrators writing and enforcing policy—is an important one. Developers will be developers: some will be rigorous about implementing security best practices; others won’t be. The only way to manage this is to assume a defensive posture in service policy, both from the perspective of incoming transactions, but also around the services themselves. The best practice here is to externalize policy enforcement and assign dedicated security professionals to administer policy.

This defensive approach to securing REST services fits well with the spirit of Comerford and Soderling’s directives. It addresses, in particular, their point about leveraging peer-reviewed frameworks. This is precisely what Layer 7’s SecureSpan Gateway is—a peer-reviewed security framework offering great depth of functionality. SecureSpan is undergoing Common Criteria Review of its implementation, as well as the entire development process for the product. We’re certifying to EAL4+, which is particularly rigorous. This provides assurance that the technology is sufficiently robust for deployment at the highest levels of military and the government. Common Criteria is an arduous process, and going through it demonstrates Layer 7’s deep commitment to security. You should not ever consider a security gateway—for REST, or for XML messaging—that isn’t undergoing the Common Criteria evaluation. Remember, Common Criteria is a necessary stamp of approval for governments around the world; it should also be a basic requirement for you.

Try SecureSpan yourself, and see how you can implement robust application security and monitoring without changing code. Download an evaluation of the SecureSpan virtual appliance right here.

2 Comments

Posted in Layer 7 Technologies

Tagged , , ,

How to Safely Publish Internal Services to the Outside World

Posted on February 9, 2010 | 2 comments

So you’ve bought into the idea of service-orientation. Congratulations. You’ve begun to create services throughout your internal corporate network. Some of these run on .NET servers; others are Java services; still others are Ruby-on-Rails—in fact, one day you woke up and discovered you even have a mainframe service to manage. But the question you face now is this: how can all of these services be made available to consumers on the Internet? And more important, how can you do it securely?

Most organizations buffer their contact with the outside world using a DMZ. Externally facing systems, such as web servers, live in the DMZ. They mediate access to internal resources, implementing—well, hopefully implementing—a restrictive security model. The DMZ exists to create a security air gap between protocols. The idea is that any system deployed into the DMZ is hardened, resilient, and publishes a highly constrained API (in most cases, a web form). To access internal resources, you have to go through this DMZ-based system, and this system provides a restricted view of the back-end applications and data that it fronts.

The DMZ represents a challenge for publishing services. If services reside on internal systems, how can external clients get through the DMZ and access the service?

Clearly, you can’t simply start poking holes in firewall #2 to allow external systems to access your internal providers directly; this would defeat the entire purpose of the DMZ security model. But this is exactly what some vendors advocate. They propose that you implement local security agents that integrate into the container of the internal service provider. These agents implement policy-based security—essentially taking on the processing burden of authentication, authorization, audit, confidentiality, integrity and key management. While this may seem attractive, as it does decouple security into a purpose-built policy layer, it has some very significant drawbacks. The agent model essentially argues that once the internal policy layer is in place, the internal service provider is ready for external publication. But this implies poking holes in the DMZ, which is a bad security practice.  We have firewalls precicely because we don’t want to harden every internal system to DMZ-class resiliancy. An application-layer policy agent does nothing to defeat OS-targetted attacks, which means every service provider would need to be sufficiently locked down and maintained. This becomes unmanagable as the server volume grows, and completely erodes the integrity of firewall #2.

Furthermore, in practice, agents  just don’t scale well. Distribution of policy among a large number of distributed agents is a difficult problem to solve. Policies rapidly become unsynchronized, and internal security practices are often compromised just to get this ponderous and dependent system to work.

At Layer 7 we advocate a different approach to publishing services that is both scalable and secure. Our flagship product, the SecureSpan Gateway, is a security proxy for Web services, REST, and arbitrary XML and binary transactions. It is a hardened hardware or virtual appliance that can be safely deployed in the DMZ to govern all access to internal services. It acts as the border guard, ensuring that each transaction going in or out of the internal network conforms to corporate policy.

SecureSpan Gateways act as a policy air-gap that constrains access to back end services through a rich policy-based security model. This integrates consistently with the design philosophy of the DMZ. Appliances are hardened so they can withstand Internet-launched attacks, and optimized so they can scale to enormous traffic loads. We built full clustering into SecureSpan in the first version we released, close to eight years ago. This ensures that there is no single point of failure, and that systems can be added to accommodate increasing loads.

The separate policy layer—and the policy language that defines this—is the key to the security model and is best illustrated using a real example. Suppose I have a warehouse service in my internal network that I would like to make available to my distributors. The warehouse service has a number of simple operations, such as inventory queries and the ability to place an order. I’ll publish this to the outside world through a SecureSpan Gateway residing in the DMZ, exactly as shown in the diagram above.

SecureSpan provides a management console used to build the policies that govern access to each service. Construction of the initial policy is made simple using a wizard that bootstraps the process using the WSDL, which is a formal service description for my warehouse service. The wizards allows me to create a basic policy in three simple steps. First, I load the WSDL:

Next, I declare a basic security model. I’ll keep this simple, and just use SSL for confidentiality, integrity, and server authentication. HTTP basic authentication will carry the credentials, and I’ll only authorize access to myself:

If this policy sounds familiar, it’s because it’s the security model for most web sites. It turns out that this is a reasonable model for many XML-based Web services as well.

Finally, I’ll define a proxy routing to get to my internal service, and an access control model once there. In this example, I will just use a general account. Under this model, the service trusts the SecureSpan Gateway to authenticate and authorize users on it’s behalf:

You may have noticed that this assumes that the warehouse services doesn’t need to know the identity of the original requester-—that is, Scott. If the service did need this, there are a number of ways to communicate my identity claim downstream to the service, using techniques like SAML, IBM’s Trust Association Interceptor (TAI), proxied credentials, or various other tricks that I won’t cover here.

The wizard generates a simple policy for me that articulates my simple, web-oriented security model. Here’s what this policy looks like in the SecureSpan management console:

Policy is made up of individual assertions. These encapsulate all of the parameters that make up that operation. When a message for the warehouse service is identified, SecureSpan loads and executes the assertions in this policy, from top to bottom. Essentially, policy is an algorithm, with all of the classic elements of flow control. SecureSpan represents this graphically to make the policy simple to compose and understand. However, policy can also be rendered as an XML-based WS-Policy document. In fact, if you copy a block of graphical assertions into a text editor, they resolve as XML. Similarily, you can paste XML snippets into the policy composer and they appear as graphical assertion elements.

This policy is pretty simplistic, but it’s a good foundation to build on. I’ll add some elements that further restrict transactions and thus constrain access to the back end system the SecureSpan Gateway is protecting.

The rate limit assertion allows me to cap the number of transactions getting through to the back end. I can put an absolute quota on the throughput: say, 30,000 transaction/sec because I know that the warehouse service begins to fail once traffic exceeds this volume. But suppose I was having a problem with individual suppliers overusing particular services. I could limit use by an individual identity (as defined by an authenticated user or originating IP address) to 5,000 transasctions/sec—still a lot, but leaving headroom for other trading partners. The rate limit assertion gives me this flexibility. Here is its detailed view:

Note that if I get 5,001 transactions from a user in one second, I will buffer the last transaction until the rate drops in a subsequent time window (subject, of course, to resource availability on the gateway). This provides me with application-layer traffic shaping that is essential in industries like telco, who use this assertion extensively.

I would also like to evaluate each new transaction for threats. SecureSpan has assertions that cover a range of familar threats, such as SQL-injection (which has been around for a long time, but has become newly relevant in the SOA world), as well as a long list of new XML attacks that attempt to exploit parser infrastructure and autogenerated code. For the warehouse service, I’m concerned about code-injection attacks. Fortunately, there’s an assertion for that:

Here’s what these two assertions look like dropped into the policy:

This policy was simple to compose (especially since we had the wizard to help us). But it is also very effective. It’s a visible and understandable, which is an important and often overlooked aspect of security tooling. SOA security suffers from an almost byzantine complexity. It is much too easy to build a security model that obscures weakness behind its detail. One of the design goals we had at Layer 7 for SecureSpan was to make it easy to do the simple things that challenge us 80% of the time. However, we also wanted to provide the richness to solve the difficult problems that make up the other 20%. These are problems such as adaptation. They are the obscure impedance-mismatches between client and server security models, or fast run-time adaptation of message content to accommodate version mismatches.

In this example, it took only seven simple assertions to build a basic security policy for publishing services to the outside world. Fortunately, there are over 100 other assertions—covering everything from message-based security to transports like FTP to orchestration—that are there when you need to solve the tougher problems.

2 Comments

Posted in Layer 7 Technologies

Tagged , , , , ,

Identity Buzz Podcast with Now Available: End-to-End Web Services Security

Posted on December 14, 2009 | Leave a comment

I recently had a great, freewheeling discussion with Daniel Raskin, Sun’s Chief Identity Strategist. Daniel runs the Identity Buzz podcasts. We talked about issues in identity and entitlement enforcement in SOA, compliance, and the problems you run into as you move into new environments like the cloud.

Daniel’s post about our podcast is on his blog.

You can download the podcast directly right here.

Leave a comment

Posted in Layer 7 Technologies

Tagged , ,

SecureSpan Product Line Certified Against Red Hat’s JBoss Enterprise SOA Platform

Posted on September 4, 2009 | Leave a comment

We were at this week’s RedHat Summit/JBoss World show in Chicago to announce that the SecureSpan line is now fully certified against the JBoss Enterprise SOA Platform. We’ve seen increasing use of JBoss in our engagements, so this endorsement is important for both Layer 7 and RedHat. We’re huge fans of open source technologies here at Layer 7, and it’s great to be more closely aligned with JBoss.

How Does it Work?

Here’s a very common deployment scenario, showing a SecureSpan Gateway in the DMZ, providing edge-of-the-network governance for JBoss Enterprise SOA platforms:

jboss

Of course, this isn’t restricted to hardware appliances. Every product in the SecureSpan line can be deployed as:

  • Hardware
  • Software on various OS platforms
  • Virtual Appliances for VMWare, Xen, or cloud providers like Amazon.

These options offer architects a lot of flexibility in how they deploy JBoss servers in combination with SecureSpan. It’s not uncommon for developers to run virtual images of both JBoss and SecureSpan on their laptops. The policies they develop in this environment can be transferred to production systems regardless of the target form factor.

Policy migration is made easy using regular import functions built into SecureSpan, or–if the application network is more complex–using our Enterprise Manager product. The later has advanced mapping features for automagically correcting policy attributes like IP address, or switching over to production LDAP systems instead of development. This is something that’s often overlooked (and I can tell you from experience that it’s a very difficult problem to solve well); but it’s an essential part of SOA policy management.

For more information:

Leave a comment

Posted in Layer 7 Technologies

Tagged , , ,

Integrating SecureSpan Gateways and Sun’s OpenSSO

Posted on September 4, 2009 | Leave a comment

François Lascelles, who is Technical Director for Europe here at Layer 7, has just published an excellent article on Sun’s Developer Network site titled Delegating XML Gateway Runtime Authorization to OpenSSO. It goes into detail about how entitlements in Sun’s OpenSSO can be enforced for Web services, XML, and REST transactions using a SecureSpan Gateway and OpenSSO server.

This combination of Policy Decision Point (PDP)–in this case, OpenSSO–and Policy Enforcement Point (PEP)– the Layer 7 SecureSpan Gateway–is a common deployment pattern for us. Most organizations have already made PEP PDPan investment in Identity and Access Management (IAM) infrastructure; however, this is not sufficient on its own for SOA access control. That’s where Layer 7 can help. Deployed in combination with an IAM system like OpenSSO, SecureSpan does the heavy lifting of XML processing and enforcement, but delegates the access control decision process (and often identity token validation) to the existing, familiar IAM infrastructure. It’s a powerful combination, and one that extends existing investment in IAM into the SOA world.

Over the past seven years, we’ve built connectors into virtually all of the IAM systems out there. When we built SecureSpan, we were careful to build an effective framework for authentication and authorization so that it’s easy to build connectors into different systems. This is important, because unfortunately the IAM marketplace evolved rapidly and without a lot of standardization.

Have a look at François’ article. He’s been with the company since it’s beginning, and has as broad a perspective on this area as you will find.

Leave a comment

Posted in Layer 7 Technologies

Tagged , , , ,

SOA Security Can Be Simple

Posted on August 28, 2009 | 3 comments

I wrote earlier in the week about Randy Hefner’s article that characterized the present state of SOA security as “good enough and getting better”. If you design your security architecture well, you can iterate on it and implement more sophisticated security models as you need them. This is something I agree with completely–in fact, this is the guiding principle behind how we build the SecureSpan Gateway product line here at Layer 7. But I’m a vendor; of course I’m going to say that. Instead, let me prove it using some real examples.

Suppose we have a simple warehouse application we want to make available to our field staff. The application resides deep inside our corporate network, and our field staff need to use the public Internet to access it. The good news is that this application publishes a service composed of four simple operations:

Warehouse Service

  • listProduct()
  • getProductDetails()
  • placeOrder()
  • currentOrders()

This will make it easy to build clients that can access it. The bad news is that it has no security protecting it in any way, as it’s been assumed to be in a secure environment.

We’ll use a SecureSpan Gateway in front of the application to be the secure “front door” to these services. The Gateway will provide policy-based security, that can be easily administered by a dedicated security professional–not the developers who wrote the original warehouse app. This is what Randy and Forrester recommend as a best practice. Here’s how it looks:

A simple, edge-of-network deployment of a SecureSpan Gateway as a border guard for internal services.

A simple, edge-of-network deployment of a SecureSpan Gateway as a border guard for internal services.

Scenario #1: Simple SSL

Randy suggested that given the right architecture, you can begin with a simple security model and evolve it. That’s what I’ll do here.  I’ll begin with a very simple, uniform security policy governing access to the service:

Policy #1

  1. Incoming connection must use SSL
  2. Send the request content to the internal warehouse service.

I’ll admit that this isn’t much of a security model–it has no authentication, authorization, or audit. But it does illustrate how you can layer on some simple policy to the internal service: here, by only accepting connections that are using SSL. Thus, we’ve put a constraint on the system that between the external client and the SecureSpan Gateway we must have confidentiality and integrity.

Policies are created in the SecureSpan Manager, which is the administration console for single gateways or clusters (a logical grouping of gateways that shares policies and critical state info and is administered as a whole). The SecureSpan Manager has a useful wizard that allows you to compose basic security policies using only the WSDL description of a service as input. I won’t demonstrate it here, but instead skip to the wizard output, which is an executable policy:

basic SSL reverse proxy

This policy will be executed automatically whenever the Gateway receives a message destined for the warehouse service. It’s composed of just two assertions that implement the policy requirements we listed above. In SecureSpan, assertions are strung together into algorithms that describe how the gateway should process a stream of XML content. SecureSpan ships about 100 standard assertions. These can be used to do everything from authentication, transformation, SLAs, routing to different transports, audit, logical flow control, orchestration, etc. There’s also a pluggable model for building your own custom assertions, which you can use to solve those unusual problems that can’t be overcome with basic components. It’s a lot like the shell scripting philosophy in Unix: give people a kit of basic sharp tools and there’s no limit to what they can build.

Scenario #2: Add Client-side Certificate Authentication and Authorization

Suppose we want to add client authentication to the policy. There are dozens of different authentication modes in the Web services standards, and a number of informal ones we see regularily in the field. We support virtually all of these. In this example, let’s use client-side certificates, and let’s add an authorization component to only permit people in the sales group to access  the warehouse service:

Policy #2:

  1. Incoming connection must use SSL
  2. Client must be challenged for a certificate, and this certificate must be valid, and be issued by an authority we trust
  3. Client must be in the sales group, as defined in the gateway internal identity provider
  4. Send the request content to the internal warehouse service (as before).

Think about what you would have to accomplish to implement this on the application server you host your services on. Now think about getting this consistent across a farm of servers. Finally, consider how you would maintain this consistently across different systems, like Microsoft .NET and WebSphere. It’s a big challenge. In contrast, here’s what it looks like in SecureSpan:

ssl authN

Notice the first assertion now declares that it will challenge the client to authenticate itself using the client-side certificate authentication protocol built into SSL. This is configured by adjusting the assertion details, which are accessible by double-clicking the assertion:

ssl detail

I’ve added a new assertion that adds authorization (or entitlements) by imposing group membership requirements. I simply dragged it in from our palette and dropped it into the policy. Here, I’m leveraging group definitions that were defined using our internal identity provider. This is a localized directory shared across SecureSpan Gateway clusters. Administrators create identities here, define groupings, and issue certificates using the Gateway’s integrated Certificate Authority (CA) capability. These features are convenient because they allows you to work with identity-centric policies without being forced to call out to an external LDAP, Identity and Access Management (IAM) system, or PKI authority. (Of course, if you want to go external, we have connectors into, well, pretty much all of them.) The internal identity provider is very useful for testing or development–and demonstrations like this where we are trying to keep things simple.

Scenario #3: OASIS Web Services Security WS-S Message-based Security

Now let’s make a really radical change to our security model. We’ll move from transport-level, SSL security to a more sophisticated message-based security model. This supports different transports–such as going over a JMS Message-Oriented Middleware (MOM) provider like MQSeries, or transfer of XML content as a file over FTP. It can handle asynchronous, and non point-to-point messaging, which are difficult or impossible to achieve using connection-based SSL.  Here’s the new policy:

Policy #3:

  1. Authenticate identity using the OASIS WS-Security Kerberos Token Profile
  2. Ensure that the message contains valid, digitally signed time stamps. These could be used to add uniqueness in the message as a means to defeat replay attacks (there are various other strategies to achieve this as well).
  3. If the operation requested is placeOrder(), decrypt the order contents elements in the message using the AES-192 cipher, a symmetric key encryption mechanism. Do this in compliance with the OASIS WS-Security standard.
  4. Regardless of the operation, ensure that there is a valid signature spanning the body of the message to ensure that nothing was altered in transit. This also establishes a binding between the content and the identity we validated in step #1.
  5. Client must be in the sales group, as defined in the internal identity provider (as before).
  6. Send the request content to the internal warehouse service (as before).

Our security model is becoming fairly complex, and it’s important to note that it is by no means complete. We haven’t even begun to address how the response from the service should be handled (right now it’s just relayed unaltered from the service); however to keep things simple in the example we’ll confine ourselves to this, knowing that it is incomplete.

Here’s what this policy looks like in the SecureSpan Manager. Note that it’s simple to read and understand, which is important when designing security implementations. Complexity increases the chances of errors going undetected:

wss 1

To write this I simply deleted the SSL assertion and dragged in four new ones. To configure the encryption on a particular element, I opened the detail pane of the encrypt request element assertion:

encrypt

This pane reflects on the schema bound to the original WSDL that describe the warehouse service. It allows me to just point at the elements I expect to find encrypted (or signed). The gateway takes care of the heavy lifting of XML decryption at run time using our acceleration technology. This panel provides a standard message stereotype to work with, or I can load a sample message to describe an even more realistic scenario.

The time spent converting from SSL-based security model to the much more sophisticated WS-Security policy was all of about 30 seconds. So what we’ve done here is shown how you can start simple, and grow your security model over time with very little effort or risk.

Simple SOA Security

When I was young my Dad was tough on tools. I quite clearly remember him stating “if your tools don’t work for you, get different tools”. This was usually followed by the offending tool being tossed into the garbage because it didn’t serve its intended purpose. A better one–one that solved the problem it was designed for–inevitably showed up soon after. Somehow, this has always stuck with me.

SOA tools need to work just as hard, and if they aren’t useful, they need to face a similar fate. SecureSpan Gateways need to offer flexibility, because the truth is, everyone has different integration challenges in the SOA world. But SecureSpan also needs to be simple enough to resist misconfiguration by virtue of the complexity of SOA security standards (more on this topic in a future post). These are actually two opposing forces, and it’s not trivial to find a useful balance between the two. SecureSpan has achieved that balance. When we do find case where it fails, our judgment is as unequivocal as my Dad’s around the chisels and wrenches in my his toolbox: replace it with something that works for you.

3 Comments

Posted in Layer 7 Technologies

Tagged , , ,

Randy Hefner on the State of SOA Security

Posted on August 25, 2009 | Leave a comment

Randy Hefner wrote an encouraging piece recently in ComputerWorld titled SOA Security: Good Enough and Getting Better. I say encouraging because from his perspective—which is broad and well-informed by virtue of his role as a Forrester analyst—most organizations now understand the importance of SOA security, and they are implementing the basics today. The more advanced pieces, particularly around complex identity-centric use cases such as single sign-on and federation, remain elusive; but at least there is a solid baseline to work from. Randy maintains:

“Thus it is important, even if you start with a simple SOA security solution, to anticipate the need for and leave paths open to build additional, deeper security functionality as business requirements demand and SOA security maturity allows.”

This is something I definitely agree with. Security can begin with the basics, as long as you put the time and energy into your basic policy and security architecture upfront. If you design it for growth, you can easily add in support for scenarios like non-repudiation later on. Security should always be an iterative process. It’s something you never finish, and you need to keep this in mind as you are designing your security architecture. You don’t want your tools and infrastructure to let you down at some point in the future.

But Randy’s real gem is here:

“Forrester strongly recommends that you design a solution that does not require application developers to do security-related coding. Even with strong guidelines and code reviews, embedding security into application code is risky both in terms of achieving consistent security and of allowing future flexibility and enhancement of application security.”

Bravo Randy—and Forrester by extension. This is the critical insight that so many people miss. Here at Layer 7, we’ve been evangelizing for years that developers need to be taken out of the equation when it comes to securing the communications that make up a secure SOA application. SOA security is a complex discipline, and it’s risky to assume that each of your development teams will implement it consistently and correctly. You need to dedicate an expert to the problem and make this person (or persons) responsible for implementing a security model across all of your SOA apps.

The fundamental associated risk with standards like WS-Security (WS-S) is their complexity. This is a very broad specification, one that relies on a host of other specifications as its core. By design, it is not prescriptive about how you should use it; rather, it is a framework for securing SOAP transactions to your business needs.

I was (am still am) an editor of the WS-I Basic Security Profile (BSP), along with colleagues from IBM, from Nortel, and from Microsoft (a number of other companies also contributed to the specification as participants in the working group). I’ve worked alongside the best SOA security minds on the planet, and I learned first hand how easy it is to inadvertently create WS-S (or, for that matter, BSP)-compliant security models that are riddled with holes. OASIS and WS-I, through the standards and profiles they produce, do not have a mandate to offer formulas for securing SOA apps. They are in the business of providing frameworks for experts to implement secure solutions, or to promote interoperability.

This is why it’s so important that security for SOA be placed in the hands of dedicated experts, and that the tools to support an overall governance strategy—such as Layer 7 SecureSpan Gateway line—allow security policies to be enacted simply and comprehensively. I’ve always said that the soul of good security is consistency. Your tools need to support this.

In a forthcoming blog entry, I’ll demonstrate how simple it is to implement SOA security using Layer 7’s SecureSpan Gateways, and thus deliver on Randy’s assertion that we must take application developers out of the SOA security process.

SecureSpan Gateway Cluster deployed in a common, edge-of-the-network scenario. This is just one example of many different deployment possibilities. Here, the gateway cluster provides consistent security policy enforcement for all services published by the organization.

SecureSpan Gateway Cluster deployed in a common, edge-of-the-network scenario. This is just one example of many different deployment possibilities. Here, the gateway cluster provides consistent security policy enforcement for all services published by the organization.

Leave a comment

Posted in Layer 7 Technologies

Tagged , , , , ,