Friday, July 29, 2011

Vordel and Oracle Entitlements Server - The power of direct integration

"Interoperability" and "Integration" are two words which are often used interchangeably. However, in systems architecture they have different meanings. "Interoperability" means that products will talk to each other, usually over the network or through shared understanding of a file format. "Integration" means something closer.

In the case of Oracle Entitlements Server (OES), this distinction is important. In Oracle's OES Product White Paper, a number of Gateways are listed as being able to use OES to manage authorization for Web Services. i.e. "interoperability". But only two are mentioned as being able to have OES directly embedded into the Gateway:
"To reduce latency, OES can be directly embedded into XML Gateways such as Oracle Enterprise Gateway and Vordel."
http://www.oracle.com/technetwork/middleware/oes/oes-product-white-paper-405854.pdf

This direct embedding of OES into the Gateway is true integration. It reduces latency for customers, which is vital in environments such as financial transaction processing and telecoms. To see how this works in practice, check out the video below which shows how the enforcement of OES authorization policies is directly embedded into the Vordel Gateway:


video

How to configure XML Signature on the Vordel Gateway

Validating XML Signature is relatively simple to setup on the Vordel Gateway. Here are the steps:

Step 1:
Open the Vordel Policy Studio. Connect to the Gateway you wish to configure your policy on. Either connect directly or login through Policy Director (Policy Director allows you to push out policies to a number of Gateways at once).

Once you connect, choose "Edit Active Configuration".

You will see the screen below:




New Web Services are registered in the "Web Service Repository" which is accessed under the "Policies" group on the left-hand-side.

Step 2: Right-click on the "Web Service Repository" and choose "Register Web Service". Note that the Web Services are arranged in groups, and you can rename these groups. In the screenshot below you can see that we've created a group called "B2B Web Services" and one called "Internal Web Services".


Step 3: Select your WSDL (either via URL, file, or use the UDDI interop with registries such as HP Systinet) and then walk through the wizard. Choose the location to deploy your virtualized service. Out of the box, there is a set of services called "Default Services" on port 8080 in the Vordel Gateway, but you can rename this or change the port. You can also add a new service group (e.g. called "SSL Services") with a different listening interface (create the new services, then right-click and choose "Add interface").

Don't check the box right now to "Secure this Web Service" (that's what we'll do next). You'll then see a "Summary" screen in the wizard, which says what path the Virtual Service has been deployed on. Take note of this path, but note that you can always see it again by right-clicking on the service and choosing to "Quick Edit" it. Press OK and then press the "Deploy" button on Policy Studio to deploy. Now open the WSDL in the browser. Note that the Vordel Gateway will automatically virtualize the service hostname in the WSDL.

Step 4: Right-click on "Policies" in the Vordel Studio and select "Add Policy". If you already have created a contained to contain your policies, you can right-click on your container and make your policy there. Note that containers are a way to group policies together, e.g. for importing and exporting them together, but don't affect the running of the policies.

Call your new policy "Validate Signature"

Step 5. Drag in a "XML Signature Verification" filter, which you can find in the "Integrity" group in Policy Studio [tip: in the searchbox above the list of filters in Policy Studio, start typing "Signature" and it will narrow down your choices to just those which include signature functionality). Configure it as shown below:

When you drag in the filter on to the policy canvas, it is initially gray because it is not being used yet. Right-click on this filter and choose "Set as start". Now it is no longer grayed out. However, it is outlined in red because it requires an input (the messages) which it is not getting at the moment. For it to get this input, it must be "wired up" to policy that is receiving a message through a listening interface.

Step 6: In Policy Studio, look under "Policies" and then "Generated Circuits" to find the service you've registered in Step 3. Double-click on the filter called "Service Handler for ''. Then open the "Message Interception Points" tab. Under "Before Operation-specific Policy" press on the "..." button to choose the policy you made in step 5 to do Signature Validation. Once it is mapped, you should see the mapping set. Make sure you press the "Deploy" button on the Studio toolbar to deploy this policy.

Step 7: To test this service, we'll use SOAPbox, which is Vordel's free Web Service testing tool. We will import the Virtual Service WSDL which you obtained from Step 3. In SOAPbox, press on the Import WSDL button (on the toolbar) and import the Virtualized WSDL from the Gateway.

Step 8: You'll see a sample message created for you in SOAPbox. Send the message through to the Vordel Gateway, by pressing the green triangular "play" button on the toolbar of SOAPbox. This message will be blocked because it has no signature. Note that you can customize the response message, since in a production system it is not usual to return a SOAP Fault to clients.

Step 9: View the blocked message in the Vordel Gateway's Real-Time Monitoring by pointing a browser to :8090/ and then clicking on "Real-Time Monitoring". Note that you'll have to login as a user with a role which allows viewing of Real-Time Monitoring. The screen is shown below:



Step 10: In SOAPbox, choose "Security" then "Sign Request" on the menu. Under "Signing Key" you can simply choose the sample key which ships with SOAPbox (called "CN=SOAPBoxConfig"). Under the "What to Sign" tab, choose the "Xpath" sub-tab and then choose "The SOAP 11 or SOAP 12 Body". Leave the other settings as they are, and press "Finish". You should now see the signature in your message in SOAPbox. Send the signed message through and it will be validated successfully , as shown below:



Other steps: In Studio, note in the "certificates" group that you can then check the trust of the certificate from the signature (i.e. check that its issuing CA is trusted). you can also validate the certificate against a CRL, an OCSP responder, or an XKMS service. To do these steps, drag one or more of these filters after your Validate XML Signature filter and drag a green line from the Validate XML Signature filter to it, indicating that you wish to check the certificate after you have checked the signature. Note that the "certificate" attribute is populated after the signature filter runs, and it then is passed to the certificate validation filters which require it.

Thursday, July 28, 2011

Signing and inserting SAML Tokens at the Vordel Gateway for Oracle OSB

Oracle OSB embeds the Oracle OWSM functionality for security features such as SAML and WS-Security. When using a Gateway in front of Oracle OSB, it is important to configure it so that the Gateway inserts and signs SAML tokens in such a way that Oracle OSB can successfully consume them. Usually the simplest way to do this is to import the WSDL of the service into the Vordel Gateway, and it will see the "advertised" WS-Policy inside the WSDL and kick off the wizard setup the appropriate policy. But if you find yourself setting this up manually, here are the details:

1) Insert the SAML Token and choose SAML Version 1.0 (assuming that is what is being expected at the OSB side), Sender Vouches, and choose to not insert the SAML Token into a Security Token Reference (STR). [the STR is made at the signing point, which comes next...].

then...

2) Sign the SAML Token, and under "What to Sign", choose "Use WSU Ids", "Use SAML Ids for SAML Elements", and "Add and dereference Security Token Reference for SAML". Under "Node Locations" in "What to Sign" choose the SAML 1.0 assertion and the SOAP body. Under "Signing Key" and "Key Info" choose "x509vs", and "include TokenType".

This works great and allows a SAML token to be used to propagate identity from the Vordel Gateway through to Oracle OSB.


Friday, July 22, 2011

Mapping the Cloud: Cisco ACE upgrade to Vordel Gateway

Vordel is presenting a webinar next month about how BNSF Railway upgraded their Cisco ACE XML Gateway to the Vordel Gateway. We're pretty excited about this, and it looks like other people are, because it's been retweeted a lot.

One particular tweet piqued my interested, and I click on it. It's the tweet below:

CloudWebinars provides a useful service on Twitter by placing upcoming cloud webinars into Google Calendar. So, when I clicked the link, I noticed that the calendar entry links to a map of where the webinar is located. I could not resist clicking on the Map link below. I was wondering "How would Google map the Cloud?"


And sure enough, when I clicked on the link, I see that Google tries to map where "The Cloud" is located in Boston:


But, rather than following Google's attempt to locate The Cloud in Boston, here's the correct link :-)
https://www2.gotomeeting.com/register/741348594


Friday, July 15, 2011

How to convert XML to SOAP on the Vordel Gateway

When you think about converting XML in general, it's natural to think "use XSLT". But it's important to note that the Vordel Gateway actually supports conversion of XML to SOAP out-of-the-box without having to resort to using xslt. Simply use a "Set Message" with a SOAP Envelope and inside the SOAP Body put a ${content.body} attribute and then the incoming XML will be automatically placed into a SOAP envelope on-the-fly. Like this:

... and, as they say in the UK, "Bob's your uncle".

But if you want to do this using an XSLT transformation, here is one you can use (import it using the "Stylesheet Conversion" filter):

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<xsl:text disable-output-escaping="yes">
&lt;</xsl:text>SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"<xsl:text disable-output-escaping="yes">&gt;</xsl:text>
<xsl:text disable-output-escaping="yes">&lt;</xsl:text>SOAP-ENV:Body<xsl:text disable-output-escaping="yes">&gt;</xsl:text>

<xsl:copy-of select="*" />

<xsl:text disable-output-escaping="yes">&lt;</xsl:text>/SOAP-ENV:Body<xsl:text disable-output-escaping="yes">&gt;</xsl:text>
<xsl:text disable-output-escaping="yes">&lt;</xsl:text>/SOAP-ENV:Envelope<xsl:text disable-output-escaping="yes">&gt;</xsl:text>
</xsl:template>

</xsl:stylesheet>

Thursday, July 14, 2011

How to configure Throttling on the Vordel Gateway

Here's a guide to setting up throttling in the Vordel Gateway:

If you've already registered a WSDL, skip forward to step 4.

Step 1: Open Policy Studio. Connect to the Gateway you wish to configure your policy on.

Once you connect, choose "Edit Active Configuration".

New Web Services are registered in the "Web Service Repository" which is accessed under the "Policies" group on the left-hand-side.


Step 2: Right-click on the "Web Service Repository" and choose "Register Web Service". Note that the Web Services are arranged in groups, and you can rename these groups. In the screenshot below you can see that we've created a group called "B2B Web Services".



Step 3: Select your WSDL (either via URL, file, or UDDI) and then walk through the wizard. Choose the location to deploy your virtualized service. Out of the box, there is a set of services called "Default Services" on port 8080 in , but you can rename this or change the port. You can also add a new service group (e.g. called "SSL Services") with a different listening interface (create the new services, then right-click and choose "Add interface").

Don't check the box right now to "Secure this Web Service". You'll then see a "Summary" screen in the wizard, which says what path the Virtual Service has been deployed on. Take note of this path. Press OK and then press the "Deploy" button on Policy Studio to deploy. Now open the WSDL in the browser. Note that will automatically virtualize the service hostname in the WSDL (as explained here: http://www.soatothecloud.com/2011/06/how-to-enable-service-virtualization.html ).

Step 4: Right-click on "Policies" in Policy Studio and select "Add Policy". If you already have created a contained to contain your policies, you can right-click on your container and make your policy there. Note that containers are a way to group policies together, e.g. for importing and exporting them together, but don't affect the running of the policies.

Call your new policy "Throttling"

Step 5. Drag in a "Throttling" filter, which you can find in the "Content Filtering" group. Configure with "10 messages in 1 minute" as shown in the screenshot below. Note that the Gateway must retain state for the messages, because it stores the message count. So, this is stored in a cache [called "Maximum Messages" in the screenshot]. You can add another cache, or edit the cache name, under "External Connections" in Policy Studio.



When you drag in the filter on to the policy canvas, it is initially gray because it is not being used yet. Right-click on this filter and choose "Set as start". Now it is no longer grayed out. However, it is outlined in red because it requires an input (the messages) which it is not getting at the moment. For it to get this input, it must be "wired up" to policy that is receiving a message through a listening interface.

Step 6: In Policy Studio, look under "Policies" and then "Generated Circuits" to find the service you've registered in Step 3. Double-click on the filter called "Service Handler for ''. Then open the "Message Interception Points" tab. Under "Before Operation-specific Policy" press on the "..." button to choose the policy you made in step 5 to do throttling. Once it is mapped, you should see the mapping set. Make sure you press the "Deploy" button on the Policy Studio toolbar to deploy this policy.

Step 7: Open the
SOAPbox testing tooll (a free download from here) . We will be using SOAPbox to test our throttling policy. Open the Virtual Service WSDL which you obtained from Step 3. [Tip: The Service Manager interface, under :8090/ , also allows you to see the Virtual Service WSDL, if you connect with a role which allows you to use Service Manager]. In SOAPbox , press on the import WSDL and import the Virtualized WSDL (note: not the actual WSDL from the back-end service you've registered, otherwise you'll simply send your messages to the back-end services and not through ).

Step 8: You'll see a sample message created for you in
SOAPbox. Send the message through to with SOAPbox, by pressing the green triangular "play" button. Keep pressing the button until you reach the throttling limit. This message will be blocked. Note that you can customize the response message, since in a production system it is not usual to return a SOAP Fault to clients.

Step 9: View the blocked message in the Vordel Gateway's Real-Time Monitoring by pointing a browser to :8090/ and then clicking on "Real-Time Monitoring". Note that you'll have to login as a user with a role which allows viewing of Real-Time Monitoring. The screen is shown in the screenshot below:


Other steps: If you add a Distributed Cache (under "External Connections" then "caches" then "Add" in the botton-right) then you can set two or more Gateways to use the same cache. This means that if the traffic is being distributed across them, then the throttling count is cumulative over them (e.g. if 5 requests come to 1, and 5 to 2, then the value in the cache will be 10).

Monday, July 11, 2011

Getting started with the Vordel Gateway

My colleague Ian Marsh has written some really useful blog posts about how to get started with the Vordel Gateway, including the ubiquitous "Hello World" and then some really useful pointers to how to create policies inside the Gateway. Definitely useful and worth following Ian over at http://enterprisegateway.wordpress.com/

Friday, July 8, 2011

OAuth, SAML, Query APIs, oh my - Finding the right Cloud integration standard

I've written an article for SD Times about the proliferation of standards for Cloud security. In the article I mention the Amazon Query API method of authentication, which although not an actual standard, has become something of an "industry standard" for authentication to Cloud-based APIs. It is widely used, not least for Amazon's own APIs of course.

The article didn't allow space for message examples, but here in this blog I can show an example of the Amazon Query API. This request is generated by a Vordel Gateway, acting as a client in this case. You can see that the request contains an "Authorization" header which is an HMAC signature computed over data including the URL, the timestamp, and the nonce ("number once" - a value which changes with each request, to combat capture-replay attacks). The signature is created using a shared secret key. An advantage of the Query API is that it is *much* smaller than using XML Signature, for example. It is also RESTful, because the request is a regular HTTP POST with the parameters passed as HTTP parameters. In effect it mimics a HTML Form POST. Here is the example below:

GET /ProcessAPIRequest HTTP/1.1
Connection: keep-alive
Transfer-Encoding: chunked
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
timestamp: 110708054739159GMT
Nonce: Id-0000013108497d0e-0000000001bed3d1-57
encryption_type: HmacSHA1
client_ref_id: client
Authorization: MGJ4aVdxeTIwWXltNTNSSUIvQW9vT2xOOE1BPQ==
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Via: 1.1 Dell-PC (Gateway)
Host: 127.0.0.1:7071
Content-Type: application/x-www-form-urlencoded

firstname=fname&lastname=lname&id=xyz

Friday, July 1, 2011

Halt: Who goes there? [... and what are their attributes?]

Access control is not only about identity, it's also about attributes. In the government/defense area, an access control decision may be made on rank, for example. A rank (e.g. an army captain) is an example of an attribute.

These attributes have to come from somewhere, and thanks to hard work by Anil John and others, there is a specification explaining how to look up these attributes. Vordel implements this specification, which is called the BAE (Backend Attribute Exchange) profile. Anil has a write-up on BAE v2 here, including how it uses SAML and SPML. If you're interested in seeing a demo of how Vordel implements BAE, give us a shout on info@vordel.com. We're proud to implement this spec which makes access control more "joined up", and always happy to show it in action.