Vordel XML Gateway
As members of the Vordel Solution Architects team, we deal with a number of interesting technical challenges in deploying the Vordel XML Gateway in a wide range of SOA and Cloud architectures. This blog will focus on detailing those solutions for the benefit of our customers and the Cloud and SOA Security communities in general.
Wednesday, August 24, 2011
Live from 36000 Feet - How to deploy the Vordel Gateway in Multiple Environments
Friday, April 22, 2011
Finalized Agenda for First Meeting of the Boston Chapter of CSA - NOTE: NEW LOCATION
When: Wednesday April 27, 2011 - 6:00 PM - 7:30 PM
Where: CA Offices in Framingham, MA
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.
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
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
- 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
- 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
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
- 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.
<?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:
I've exported this project and added it to the Vordel Incubator. You can download the config here. Let me know what you think.
<?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>