Wednesday, August 24, 2011

Live from 36000 Feet - How to deploy the Vordel Gateway in Multiple Environments


First of all, a quick acknowledgement of my lack of blogging. Life at Vordel has been really fast paced, and I've been traveling the country working on a lot of interesting use cases with some really great customers. I'm flying from San Diego to San Francisco, and this flight has WiFi, so I guess I'm out of excuses.

A quick note on feature that was added in 6.0.3 - envSettings.properties. This is the ability to externalize attribute values in the gateway's per environment. The file can be found in the $VINSTDIR\conf directory. The text below, from the file explains how to use it.
# This file is read when the server starts up. If a server configuratio
n contains a value in the format
# ${env.X}, where X is any string (for example, MyCustomSetting), this file MUST contain an equivalent
# name-value pair of env.MyCustomSetting=MyCustomValue.
# When the server starts up, every occurrence of env.MyCustomSetting is expanded to the value of MyCustomValue.
# For example, if a port in the server configuration is set to ${env.LISTENER_PORT}, specifying a name-value
# pair of env.LISTENER_PORT=8080 results in the server opening up port 8080 at start up.
env.LISTENER_PORT=8080

Here we see the corresponding configuration in the Policy Studio


This is a very simple. but powerful approach for configuring the gateway to work across environments. It also aligns nicely with most enterprises existing approach for moving configurations among environments.

Looks like I forgot to charge my battery, and no AC power on the flight, so this is going to have to be a short post :)

Friday, April 22, 2011

Finalized Agenda for First Meeting of the Boston Chapter of CSA - NOTE: NEW LOCATION

I've got the agenda for the first meeting of the Boston Chapter of the Cloud Security Alliance.

When: Wednesday April 27, 2011 - 6:00 PM - 7:30 PM
Where: CA Offices in Framingham, MA
Agenda: Two presentations, each with their own unique and insightful perspectives on the topic of cloud security.

Presentation #1: Cloud Computing Risks

Speaker Bio:

Bhargav Shah is a Director within KPMG Advisory practice. He has over 12 years of experience as a trusted advisor to C-level and Senior IT leadership having led multiple engagements in Outsourcing, Cloud Computing, IT Solution Delivery/Application Development, Process Engineering, and IT Services Management. Mr. Shah regularly speaks at conferences and IT leadership forums on various topics related to Outsourcing and Cloud Computing. He also leads KPMG’s solution development initiatives related to IT implications of cloud computing.

Abstract:

As the paradigms of technology consumption change, cloud computing is at the forefront of an IT transformation providing infrastructure, platforms, and software as services to the business. While some call it a technology fad, the pervasive buzz around cloud computing is here to stay. Cloud computing provides many benefits but introduces just as many risks. Successful organizations must understand and mitigate these risks to get more out of their cloud computing initiatives.

In this session, Bhargav Shah will share his insights on the types of risk you need to be aware of while utilizing cloud computing, how they vary by cloud model you use (Public vs. Private) and what controls you can consider to mitigate some of these risks associated with cloud computing.


Presentation #2: Cloud Computing and it’s impact of Identity & Access Management (IAM) Infrastructure

Speaker Bio:

Robert Levine brings more than 25 years of technology management experience to SENA Systems that includes significant customer and vendor side enterprise software and knowledge. Robert has served as SENA’s President & CEO since 2001 and with the SENA management team has overseen its growth in the US, Europe, Asia and the India operations center as well as its merger in March of 2008 with aurionPro Solutions LTD. Robert presently holds the position of President of aurionPro Solutions Inc as well as the head of the SENA Systems business unit. Prior to joining SENA Systems, Robert worked for Venture Consulting Group, Inc. a provider of management services to early stage and restructuring companies, as a strategic business advisor to both public and private companies.

Robert previously served as the VP of Business Development for Transindigo, a startup e-infrastructure company providing mission critical solutions for securely managing transactional entitlements and authorizations that was sold to RSA. Robert also served as the co-concept originator, interim CEO and technical advisor to Transindigo prior to its launch in January 2000. Prior to Transindigo, Robert served as Managing Director, Deutsche Bank Strategic Ventures and as Managing Director in Bankers Trust's Technology and Operations Group where he was a member of the management team responsible for Global Technology Infrastructure. Robert served on the board of IQ Financial, a global software supplier of front, middle and back-office financial services technology selling to global financial firms that was later sold to Misys. He also served as the technical advisory board of mFormation a wireless network management products and services company. Robert was a founding member and Vice President of SIMC, a nonprofit organization, that focused on advancing the capabilities of middleware in the financial services industry. Robert is a strong believer of community service and currently serves in a Line Officer capacity as Sergeant of his local community EMS Rescue Squad

Abstract:

No conference, seminar or a CXO level technology roadmap meeting today is complete withouta discussion on Cloud Computing. Every organization is asking the question – how could, would and should cloud computing impact or influence their plans related to IAM.


In SENA’ talk on Cloud Computing we will discuss the following considerations:

· Two Fold impact of Cloud Computing on IAM Services

o Protecting cloud based applications with should IAM Services.

o Providing IAM Services over a Cloud infrastructure.

· IAM Infrastructure

o Considerations related to Software as a Service, Platform as a Service and Infrastructure as a Service including SENA’s plans regarding such offerings.

o Differentiating the advantages and challenges related to

§ Identity Management

§ Access Management

· A frank assessment of where the security industry is with regards to Cloud offerings.

Monday, March 21, 2011

Call for Speakers - First Meeting of the Boston CSA Chapter - April 27 6:00 @ Oracle Offices in Burlignton

I'm happy to announce that we're going to have our first meeting of the Boston Chapter of the Cloud Security Alliance on Wednesday, April 27th at 6:00 at the Oracle office in Burlington, MA.

The topic for this meeting is Cloud Security Architecture. We wanted to cover both the conceptual (NIST, CSA Reference Architecture, etc) and the practical - real world examples of what people are using/deploying in their environments. The agenda will be something like this:

6:00 - 6:15 Introductions
6:15 - 6:45 Presentation 1 - Cloud Security Architecture - Conceptual
6:45 - 7:15 Break/Networking Session
7:15 - 7:45 Presentation 2 - Cloud Security Architecture - Practical/Use Case
7:45 - 8:00 Closing

We're looking for speakers on both the abstract notion of "What is Cloud Security Architecture?" and a more practical hands on use-case driven view of the topic. If you are interested in speaking or participating in a round-table type discussion, please send me which topic you're interested in presenting, and speaker's BIO (linkedin profile). Please send this to me (josh.bregman@vordel.com) by Thursday, March 31st.

Looking forward to a great first session.

Friday, March 4, 2011

Minutes from the Boston Chapter of the CSA's first Board Meeting

After many scheduling challenges, we had our first CSA Boston Chapter Board Meeting. The "Board" consists of me (Vordel), Prateek Mishra (Oracle),Matthew Gardiner (CA), and Kevin Fox (Cisco). A really good session for planning out the year. Here's the basic thinking:

- Divide the CSA guidance into 4 units and have 1 meeting focused around each unit
- The events will be about 2 hours - 1 hour on high-level information contained in the CSA guidance and 1 hour on a lower level details of someone who is actually living/implementing the scenario
- We'll rotate the location among CA, Oracle and Cisco locations - basically 128/495

The next steps are to have Matt, since it was his idea, to group the domains into the four meeting "buckets", and for us to meet again in two weeks to start the planning of the 1st meeting - targeted for some time in April.

Once we get the meeting "themes" worked out, we'll be publishing them with some tentative dates, and we'll be issuing a pseudo "call for speakers". Ultimately we're looking to have some really interesting speakers and presentations that are worth the trip - but for that to happen we'll need everyone's help. Ping any of the board members if you have a topic to suggest (aligned with the CSA Guidance) or a speaker that you think would be good.

We're also open to any other suggestions/guidance that people may have, so don't hesitate to speak up.

Wednesday, March 2, 2011

How to turn an XML Gateway into a Maven Repository

I've made some real progress on the Maven integration with the Vordel XML Gateway. I've updated the incubator with the latest set of policies. These policies provide two main features:


  • The ability to download the Gateway libraries as dependencies directly from the gateway
  • The ability to deploy Maven artifacts to the gateway


Exposing the libraries of the Gateway as POMs


One of the main challenges in getting a technology like the gateway that isn't built using Maven into the Maven world is the mapping of jars to POMs. As I showed previously, you can do this, but its a manual process. You could automate it with ANT tasks, but its still tricky. I encountered this problem before when I was trying a similar exercise with Oracle Entitlements Server. For that I wrote a bunch of custom code and deployed it as a WAR to the OES Admin Server. Not bad, but with the gateway it was even simpler.

Basically I used the static content service to point to the directories on gateway, and then used a policy to handle a view of the subtleties - we only have MD5 checksums, POMs need to get generated since we don't have them, some of the mappings for the org.eclipse libraries are irregular. For the main case, retrieving the jar, I'm just manipulating the http.request.uri property and passing it to the static content service. Magically, it returns the POM, the JAR, and the MD5 checksum of the JAR. I also used a cool feature new to 6.0.3 - the ${env.xxx} capabilities. You can use this namespace from inside of a policy, and the gateway will resolve the value based on the envSettings.props file. I used this to specify the values of the location of the gateway in my environment


env.maven.gateway.path=c:\\Users\\jbregman\\Documents\\products\\xml gateway\\vordelgateway\\system\\lib
env.maven.policystudio.path=c:\\Users\\jbregman\\Documents\\products\\xml gateway\\policystudio\\plugins
env.maven.repo2.path=c:\\Users\\jbregman\\repo2


In order to take advantage of my gateway as a repository, I modified the parent POM of the sample-filter, to include:

<repositories>
<repository>
<id>vordelgateway</id>
<url>http://localhost:9090/repo</url>
</repository>
</repositories>


This means that when its looking for the dependencies, it will check the gateway, and they will be downloaded to your local repository so you can compile. Maven supports SSL and Basic Authentication, so these things could easily be added to both the Maven configuration as well as applied to the Maven policies running on the gateway.

Deploying Maven Artifacts to the Gateway


The first question is "Why would you want to do that?". One use case that I'm working on is for custom filters. Once the jar is built, it needs to be copied to the gateway's lib directory, so this is the foundation for that. I'm not there yet - need to do something with the file once its there, but I like the simplicity of using the mvn deploy task to push the artifact to the gateway for me. Ultimately my goal is to package up all of the dependent artifacts and push/deploy them to the gateway.

The policies for this one were a little more complicated because the static content service only gets me so far - it doesn't handle HTTP PUT requests- which is what Maven uses to push the files to the server. No problem - I simply used the Save to File filter - to store the file on disk. Again, I used the ${env.xxx} to define the location on disk for the repository.

In order for projects to take advantage of this capability, I again modified the parent POM:


<distributionManagement>
<repository>
<id>dev-integration-gateway</id>
<name>Dev Integration Gateway</name>
<url>http://localhost:9090/repo2</url>
</repository>
<snapshotRepository>
<id>dev-integration-snapshot-gateway</id>
<name>Dev Integration Gateway</name>
<url>http://localhost:9090/repo2</url>
</snapshotRepository>
</distributionManagement>


This means than when you run mvn deploy the artifact can be pushed and stored on the gateway. Presumably, in addition to just deploying the file, other actions could be taken - synchronously or asynchronously.

Implications for the SDLC


Notice that in the parent POM, there is the same server (localhost) referenced both times. I put the two separate repositories on different relative paths to simplify the implementation, but in practice these repositories are likely to be on separate instances. The idea is that a developer working on a sandbox instance can download the libraries to their local repository, develop the component and then deploy it to the dev-integration-gateway. The thinking here is that this gateway is the first managed gateway. The gateway's configuration is then pushed using the policy directory from the dev-integration gateway to QA. Getting all of this to work end-to-end using Maven is the goal of Maven Integration project on the incubator.

If you like where this is headed, get involved, join the incubator at cloudservicebroker.googlecode.com.

Thursday, February 24, 2011

REST API for message level and system level metrics for the XML Gateway

In my first few weeks at Vordel, I've been spending a lot of time on the "cool" part of the product - building circuits and policies. As a developer, I really enjoy (am amazed) at how quickly you can know things out. But this is a job after all, so I also have to spend time coming up to speed on some of the less "glamorous" yet really important and valuable features of the product.

I've started to look at the various administrative interfaces in the product and see what makes them tick. One really powerful feature of the Vordel XML Gateway is its out-of-the-box real time monitoring capabilities. The application itself is a Flash app that displays all of the details of the usage of the gateway - successful messages, blocked messages, failed messages - traffic to various remote hosts.

One thing that it also has is the system utilization - memory and CPU. This is really nice because you can get both the message (application level) and system-level information from a single source. This makes the task of integrating this information into an enterprise operations system much simpler. But how do you get at the information. Simple, http://gateway:8090/metrics



Notice that I'm just accessing the URL form a browser and you can see both the system information, as well as all of the statistics for the messages.

This is the same URL that the flash application accesses to retrieve the information in the real time monitor. The URL is protected with HTTP Basic authentication (all of the admin services are out of the box) so access is restricted as well as audited. Now that you know that the REST API is available, you can integrate this information into your environment.

Tuesday, February 22, 2011

How to Use an XML Gateway with an Asynchronous Web Service using WS-Addressing


In general synchronous web-services are simpler and more common than asynchronous web services. I like them, because for 99% of cases, the security can be done at the transport level using 2-way SSL. Asynchronous web-services introduce additional security challenges - mainly that messages are likely to be in memory or on disk where the transport is not there to keep the contents of the message secure. The purpose of this post is not to explore the security challenges of using asynchronous web-services, but another complexity - proper handling of web-services callbacks through an intermediary.

One of the main uses of an XML gateway is to encapsulate the end-point of the actual service from the caller. This approach is aligned with SOA best practices, but from a security perspective not letting people know where your service actual lives is a really good idea. This principal can also apply in the callback use case - we may want to hide the location of callback URL from the actual service - let's for the sake of this discussion consider it need to know. The end service can just callback to the gateway, and the gateway will deliver the message back to its appropriate destination.

Now assuming that we're not passing the location of the callback - in WS-Addressing this is called the wsa:ReplyTo address - then when the gateway finally receives the response, how does it know where to send the message? To solve this problem, the gateway needs to create a cache of replyTo URLs keyed off of the messageId. Each request has a wsa:MessageId. When the server sends its reply, the original message id is reference in the wsa:RelatesTo header. This way the gateway can correlate the request with the response.

Understanding the Example
I've created an example project that demonstrates how the gateway works in the above scenario. I'm using the gateway to play the role of 3 different use case actors - client, gateway, and server.


  • Client - SOAPBox is sending the initial request to the service. I created an HTTP service listening on port 11000 to serve as the destination of the final wsa:ReplyTo.
  • Gateway - When the service gets invoked, the gateway stores the wsa:ReplyTo in a cache (keyed by the wsa:MessageId) and modifies the wsa:ReplyTo and wsa:To fields accordingly. In the callback service, the gateway retrieves the original wsa:ReplyTo from the cache (pulling the key from the wsa:RelatedTo) field, and sends the request to the original wsa:ReplyTo
  • Server - This is just using the gateway to simulate the back end server. When it receives the message, it simply sticks the file on disk. The gateway has a directory scanner configured. Directory Scanner is the ability for the gateway to process files sitting on the file system. When the Directory Scanner finds a file, it modifies the response (read: appends "Hello" to the message) and then sends it to the address in the wsa:ReplyTo which is the gateway.
You can see what an end-to-end flow looks like in the Real Time Monitor

The Gateway Policy Details
The example contains policies for all three roles.


I wanted to spend some time here to review in a little more detail the gateway and what it does when it processes the request, and handles the callback. When the request arrives, the original message looks something like this:


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<soap:Header>
<wsa:MessageID>uuid:6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://localhost:11000/callback</wsa:Address>
</wsa:ReplyTo>
<wsa:To>http://localhost:12000/SoapContext/SoapGreeterPort</wsa:To>
<wsa:Action>Greet</wsa:Action>
</soap:Header>
<soap:Body>
<x1:greetMeOneWay xmlns:x1="http://apache.org/hello_world_soap_http/types">
<!-- Element must appear exactly once -->
<x1:requestType>Asynch Client using WS-Addressing</x1:requestType>
</x1:greetMeOneWay>
</soap:Body>
</soap:Envelope>


The message gets picked up and processed by the following policy:



I'm using policy shortcuts to encapsulate all of the details, but you get the basic idea. The message leaving the gateway has been transformed to have the gateway address in the wsa:ReplyTo and the server's address in the wsa:To. This is the resulting message sent to the server.


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<soap:Header>
<wsa:MessageID>uuid:6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>


<wsa:Action>Greet</wsa:Action>
<wsa:ReplyTo>
<wsa:Address>http://localhost:12000/SoapContext/GreetCallbackSoapPort</wsa:Address>
</wsa:ReplyTo><wsa:To>http://localhost:13000/SoapContext/SoapGreeterPort</wsa:To></soap:Header>
<soap:Body>
<x1:greetMeOneWay xmlns:x1="http://apache.org/hello_world_soap_http/types">
<!-- Element must appear exactly once -->
<x1:requestType>Asynch Client using WS-Addressing</x1:requestType>
</x1:greetMeOneWay>
</soap:Body>
</soap:Envelope>


So when the reply comes back from the server, and arrives back at the gateway, it has a new wsa:messageId, but the original messageId is available in the wsa:RelatesTo header.


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" />
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
uuid:Id-0000012e5303f409-0000000000a96fd2-2
</wsa:MessageID>
<wsa:RelatesTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
uuid:6B29FC40-CA47-1067-B31D-00DD010662DA
</wsa:RelatesTo>
<wsa:To xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
http://localhost:12000/SoapContext/GreetCallbackSoapPort
</wsa:To>
</soap:Header>
<soap:Body>
<x1:greetMeResponse
xmlns:x1="http://apache.org/hello_world_soap_http/types">
<!-- Element must appear exactly once -->
<x1:responseType>
Hello Asynch Client using WS-Addressing
</x1:responseType>
</x1:greetMeResponse>
</soap:Body>
</soap:Envelope>


The callback policy then picks this message up and applies the following filters:




This is the basic caching pattern used by the gateway. The cache's key is the wsa:messageId set by the incoming request. This can then be retrieved from the cache by pulling the wsa:RealtesTo messageId. The resulting URL is then set as the destination (wsa:To) of the response, and the reply is sent. The final message looks like this:


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" />
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
uuid:Id-0000012e53675a57-0000000001f76db2-18
</wsa:MessageID>
<wsa:RelatesTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
uuid:6B29FC40-CA47-1067-B31D-00DD010662DA
</wsa:RelatesTo>
<wsa:To xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
http://localhost:11000/callback
</wsa:To>
</soap:Header>
<soap:Body>
<x1:greetMeResponse
xmlns:x1="http://apache.org/hello_world_soap_http/types">
<!-- Element must appear exactly once -->
<x1:responseType>
Hello Asynch Client using WS-Addressing
</x1:responseType>
</x1:greetMeResponse>
</soap:Body>
</soap:Envelope>
I've exported this project and added it to the Vordel Incubator. You can download the config here. Let me know what you think.