I'd guess that many of us who have been working with DataPower long enough have faced a challenge of clear text "secrets". Usually there isn't an easy-to-integrate type of password vault at your disposal and you are faced with a dilemma of where to store shared secrets. DataPower offers an object called password map alias that can solve the problem in some cases. However, if you for example need to insert your shared secrets into a message payload, a password map alias cannot be used directly.
As I stated above that a password map alias cannot be used directly, here is a trick that you might find useful... We can extract the value of a password map alias using a simple loopback XML firewall. Let's start by creating a new loopback XML firewall.
Figure 1. XML Firewall general tab
Type should be "Loopback" and local address "127.0.0.1" (localhost) so that the requests are kept internal. If we want to make the loopback calls using GET HTTP method "Process Messages Whose Body Is Empty" should be set to "on". Also we might want set "Enable Persistent Connections" to "off" as described in figure 2 below.
Figure 2. XML Firewall advanced tab
Next we can add a new processing policy that is very simple. An example of a demo policy is shown in figure 3 and it contains only one transformation action.
Figure 3. XML Firewall policy
The configuration of the transform action is shown below. In my example the stylesheet has been uploaded into it's dedicated folder but you can pretty much decide the location yourself.
Figure 4. XSLT transform action
The content of the stylesheet is as follows:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions"
xmlns:dpconfig="http://www.datapower.com/param/config"
extension-element-prefixes="dp dpconfig">
<xsl:output method="xml"/>
<xsl:template match="/">
<!-- Extract authorization header -->
<xsl:variable name="authorization" select="dp:request-header('Authorization')" />
<!-- Decode authorization header -->
<xsl:variable name="decoded-creds" select="dp:decode(substring-after($authorization, ' '),'base-64')" />
<!-- Create output that contains extracted credentials -->
<creds>
<uid>
<xsl:value-of select="substring-before($decoded-creds, ':')"/>
</uid>
<pwd>
<xsl:value-of select="substring-after($decoded-creds, ':')"/>
</pwd>
</creds>
</xsl:template>
</xsl:stylesheet>
The idea is to extract and encode the password map alias value from the contents of an Authorization HTTP request header and the output it as a XML output.
After the new XML firewall has been configured we can add the password aliases that contain our shared secrets.
Figure 5. A new password map alias
Figure 6. Password map aliases
For the demo setup I have created two password map aliases as shown in figures 5 and 6. Next they can be added to a user agent configuration as Basic-Auth Policy "rules". Best practice is to create a new user agent, not to modify the default one. The trick is to separate password map aliases with URL Matching Expressions that can be used later in an url-open call.
Figure 7. User agent Basic-Auth Policy
The newly created user agent has to attached to a XML manager configuration. Again, we want to create a new manager and not to modify the default one. The new XML manager configuration is shown in figure 8.
Figure 8. XML Manager configuration
After the new XML manager configuration is ready we can add it to our existing service definitions. An example is shown in figures 9, 10 and 11. XML manager is changed from "default" to newly created "password-map-xml-mgr" and a new transform action is added to the processing policy.
Figure 9. Multi-Protocol Gateway configuration
Figure 10. Multi-Protocol Gateway policy
Figure 11. Call loopback transform action
The stylesheet used to call the credential loopback service is shown in the code block below:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions"
xmlns:dpconfig="http://www.datapower.com/param/config"
extension-element-prefixes="dp dpconfig">
<xsl:output method="xml"/>
<xsl:template match="/">
<!-- Extract incoming URI for testing purposes-->
<xsl:variable name="uri" select="dp:variable('var://service/URI')"/>
<!-- Construct the loopback url that can be used to extract the credentials -->
<xsl:variable name="loopback-url" select="concat('http://localhost:9080',$uri)"/>
<!-- Call credential loopback and store respose to a variable -->
<xsl:variable name="credential-loopback-response">
<dp:url-open target="{$loopback-url}" response="xml" timeout="1"/>
</xsl:variable>
<!-- Create output that contains extracted credentials -->
<xsl:copy-of select="$credential-loopback-response"/>
</xsl:template>
</xsl:stylesheet>
As you can see we just create a simple url-open call to the loopback with the URI that maps to the correct password map alias. In this example I'm just forwarding the incoming URI into the loopback for demonstration purposes. After the changes a call to RESTProxy MPGW results an added call to loopback XML firewall. Calls with two different URIs are shown in figures 12 and 13. You can clearly see that the loopback returns different "secrets" based on the URI used in the loopback call.
Figure 12. The first loopback call
Figure 13. The second probe view
Hope you find the example shown in this blog post useful. In case you have any questions just throw in a comment or two.
#DataPower#Featured-area-1#Featured-area-1-home