November 18th, 2011

Forrester Wave for SOA Application Gateways 2011 – Layer 7 Positioned as a Leader

Written by
 

Forrester Wave for SOA Application GatewaysAt the end of last month, we announced that Layer 7 had been named a Deloitte Technology Fast 500 growth company and had been positioned as a leader in Gartner’s 2011 Magic Quadrant for SOA Governance Technologies. Today, we’re very proud to announce that Forrester Research, Inc. has named Layer 7 a Leader in a new report, The Forrester Wave™: SOA Application Gateways, Q4 2011.

The report groups its criteria into three high-level categories: Current Offering, Strategy and Market Presence. Layer 7’s “SecureSpan SOA Gateway scored well in all of the major functional categories.” In fact, we actually had the highest score in the Current Offering category and the Strategy category. As a Leader, we were recognized for our broad and deep support for messaging styles, attack protection, trust enablement and content transformation.

Top vendors were evaluated, so we feel it’s a great honor to be positioned as a Leader in this SOA Application Gateways Wave. For more information on the report, read our press release.

October 17th, 2011

New White Paper: A Simple & Secure Approach to Integration across SOA, API & Cloud

Written by
 

Lightweight ESB White PaperWe’re very pleased to announce the publication of a new Layer 7 white paper, called SOA Appliances: A Simple & Secure Approach to Integration across SOA, API & Cloud. Written by Jamie Ryan, Layer 7’s Partner Solutions Architect, this white paper explores how a SOA Gateway can be deployed as a lightweight alternative to the conventional Enterprise Service Bus (ESB).

The ESB has emerged in recent years in response to the increased need for IT integration, which enterprises have experienced as a result of rapidly proliferating Cloud and mobile technologies. ESBs tend to be extremely feature-rich. Consequently, they can also be very complex, to the point that they are often difficult and costly to install, administer and secure.

Our new white paper explains that a SOA Gateway represents a simpler, more cost-effective alternative to the ESB – crucially, an alternative that does not require the enterprise to compromise on security. Using a SOA Gateway as an ESB enables a modern integration architecture but with a much lighter footprint and user experience.

Click here to download SOA Appliances: A Simple & Secure Approach to Integration across SOA, Cloud & API

October 14th, 2011

FROM THE VAULT: Resources on How to Choose a SOA Gateway

Not All SOA Gateways are Created Equal white paperOur weekly From the Vault series highlights classic resources from the Layer 7 Library. This week, we’ve got not one but two items, both of which will prove highly valuable to anyone who is researching options for purchasing or replacing a SOA Gateway – a white paper called Not All SOA Gateways are Created Equal and a webinar called How to Choose a SOA Gateway.

Not All SOA Gateways are Created Equal notes that most Gateways on the market are able to address a good deal of the most common functional requirements. However, the white paper explains, the total cost of ownership (TCO) varies widely between Gateways – and TCO extends well beyond the initial licensing fees to encompass a range of significant factors.

The white paper goes on to examine those factors that will have the greatest impact on TCO, namely:

  • Ease of deployment and customization
  • Manageability, scalability and reliability
  • Cost of upgrade or repurchasing

Click here to find out more about the white paper and to download the PDF

How to Choose a SOA Gateway expands upon the content of this white paper to provide business managers with practical instructions on which key operational and functional needs, as well as potential pitfalls, to consider when selecting a SOA Gateway, including:

  • Portability considerations
  • Scalability risks
  • Extensibility and upgradeability needs
  • Global management implications
  • Hidden operational costs

You can either click here to find out more about the webinar and to download a copy or you can stream it in the player below, courtesy of the Layer 7 YouTube channel:

September 30th, 2011

FROM THE VAULT: White Paper – The Role of XML Gateways in SOA

Written by
Category From the Vault, SOA
 

Role of XML Gateways in SOA White PaperA week ago, we began a weekly series of blog posts on key content from the Layer 7 Resource Library. We started things off by bringing about our Expanding Role of XML Gateways in SOA, Mobile & Cloud webinar. This week we’re going to stick with the same general area of interest but focus in a bit on the specific uses of Gateways in SOA.

Our white paper The Role of XML Gateways in SOA is consistently one of the most popular items in the Resource Library, which goes to show that the topic of SOA is still on a lot of people’s minds. This white paper explains how XML Gateways deliver “application networking” functionality, making it possible to complete critical SOA tasks without programming.

In contrast to conventional networking devices, XML gateways specialize in the application-level protocols rendered within XML or Web services messages. An XML gateway can rapidly inspect and process XML messages to efficiently perform a range of processes vital to SOA, including content routing protocol switching, data transformation and identity authentication.

By doing so, XML gateways make it easy for SOA architects to:

  • Implement security
  • Optimize performance
  • Enable advanced policy operations

To get more detailed insight into the value of XML gateways to SOA deployments, download the white paper.

September 16th, 2011

OAuth Client Broker Tooling

In terms of OAuth enterprise tooling, a lot of focus is given to OAuth-enabling APIs exposed by the enterprise itself. Naturally, the demand for this reflects today’s reality where the enterprise is increasingly playing the role of an api provider. However, many enterprise integration use cases involving cloud-based services puts the enterprise in the role of API consumer, rather than provider. And as the number of enterprise applications consuming these external APIs grows, and the number of such external APIs themselves grows, point-to-point OAuth handshakes become problematic.

Another challenge relating to consuming these external APIs is that OAuth handshakes are geared towards a client application driven by a user. The protocol involves a redirection of that user to the API provider in order to authenticate and express authorization. Many enterprise integration (EI) applications do not function in this way. Instead their behavior follows a machine-to-machine transaction type; they operate at runtime without being driven by a user. Wouldn’t it be great if these EI apps could benefit from the OAuth capabilities of the APIs and still operate in headless mode? The so-called ‘two-legged’ OAuth pattern provides a work around for this challenge but requires the client app to hold resource owner credentials, which is problematic, especially when replicated across every client app.

To illustrate how an enterprise API management solution can help manage this challenge, I demonstrate an OAuth tooling geared towards brokering a client-side OAuth session with the Salesforce API using the Layer 7 Gateway. By proxying the Salesforce API at the perimeter using the Layer 7 Gateway, my EI apps do not have to worry about the API provider OAuth handshake. Instead, these EI apps can be authenticated and authorized locally using the Enterprise identity solution of choice and the Layer 7 Gateway manages the OAuth session on behalf of these applications. The benefits of this outbound API proxy are numerous. First, the OAuth handshake is completely abstracted out of the EI apps. In addition, the enterprise now has an easy way to manage control of which applications and enterprise identities can consume the external API, control of the rates of consumption and monitor usage over time. The API can itself be abstracted and the proxy can transform API calls at runtime to protect the consuming apps from version changes at the hosted API side.

To set this up on the Layer 7 Gateway, you first need to register a remote access to your Salesforce instance. Log into your Salesforce instance and navigate to Setup -> App Setup -> Develop -> Remote Access. From there, you define your remote access application. The callback URL must match the URL used by the Layer 7 Gateway administrator at setup time in the Layer 7 Gateway. Make sure you note the Consumer Key and Consumer Secret as they will be used during the OAuth handshake setup; these values will be used by your Layer 7 OAuth broker setup policy.

Using the Layer 7 Policy Manager, you publish your broker setup policies to manage the OAuth handshake between the Gateway and your Salesforce instance. Note that the OAuth callback handling must listen at a URL matching the URL defined in Salesforce. These policies use the consumer key and consumer secret associated with the registered remote access in your Salesforce instance. The secret should be stored in the Gateway’s secure password store for added security. Use templates from Layer 7 to simplify the process of setting up these policies.

Once these two policies are in place, you are ready to initiate the OAuth handshake between the Layer 7 Gateway and the Salesforce instance. Using your favorite browser, navigate to the entry point defined in the admin policy above. Click the ‘Reset Handshake’ button. This will redirect you to your Salesforce instance. If you do not have a session in place on this browser, you will be asked to authenticate to the instance, then you are asked to authorize the client app (in this case, your Layer 7 Gateway). Finally, you are redirected back to the Layer 7 Gateway admin policy which now shows the current OAuth handshake in place. The admin policy stores the OAuth access token so that it can be used by the api proxy at runtime.

Your Layer 7 Gateway is now ready to act as an OAuth broker for your EI apps consuming the Salesforce API. You can publish a simple policy to act as this proxy. This policy should authenticate and authorize the EI app and inject the stored OAuth access token on the way out. Note that this policy can be enhanced to perform additional tasks such as transformation, rate limiting, caching, etc.

Although this use case focuses on the Salesforce API, it is generally applicable to any external API you consume. You can maintain an OAuth session for each API you want to proxy in this Gateway as well as perform identity mapping for other external access control mechanism, for example AWS HMAC signatures.