Basic Auth Header Injection

What is Basic Auth?

For a HTTP transaction, a method to pass the credentials in the form of username and password in the request header (encrypted) is considered to be Basic Authentication.

DataPower integration appliance supports SSL (Mutual Auth & Server Auth) as well as Basic Auth mechanism. The basic-auth header injection can be configured via a User Agent (Objects à Network Settings à User Agent). DataPower user agents provide additional interactions and customizations to the outbound requests. The user agent selection is part of an XML Manager configuration. Every service references a default XML manager and user agent when created. It is recommended that if any of these are to be changed, it is better to create a new XML Manager as well as new User Agent, so as not to affect the other services using the default ones.

In a WSP, the Proxy Settings tab holds the XML Manager field. For any WSP, a new XML Manager can be created and assigned using drop-down. Each XML Manager can be configured with specific User Agent and this is configured at the bottom of the Main tab.

The user agent panel has many tabs across the top. To setup Basic Auth, click on the Basic-Auth Policy tab. It has a URL matching expression used to determine when each entry is applied and it has Username and Password fields.

Dealing with Digital Signatures & Mutual Auth

We often come across the situation where several components in the mix do not understand the authentication mechanisms and we then tend to integrate those components using DataPower integration appliance. Phew! Thanks for DataPower XI50.

I came across a situation where I wanted to integrate Component A (digital signature) with Component B (mutual authentication). For such clients, a “Verify Action” in the processing rule determines wheather the payload was signed by a trusted certificate. The “Verify Action” specifies a Validation Credential containing all the public keys that are accepted as signers of a payload (Validation Credentials are like trust stores). Thus our Front End system (Component A) is using digital signature in a message but since our back-end is not expecting digital signature and on the contrary its authentication mechanism is Mutual Authentication.

So following the digital signature verification (Verify Action) is a “Transform Action” which can be used to strip the incoming security header. This can be done to simplify configuration of backend servers that would otherwise be obligated to also verify the digital signature. This transform object should refer to an XSLT which will have logic to strip-off the header.

Back End as expected will use mutual authentication with the crypto profiles having identification and Validation Credentials (for more details on how to setup mutual auth refer to a different blog).