EPBCS, REST and Authentication

I’ve always been a big proponent of REST and REST-based integrations as it relates to the EPM stack, or indeed, to any cloud solution. Here is some sample content that illustrates this. When you use the (E)PBCS REST API (or any EPM API, for that matter), one issue that crops up, is how to mask the username and password with “Basic” authentication. The EPM REST APIs use this mode of authentication to communicate with cloud applications. As such, a cURL request like this will allow you to get details of your (E)PBCS application:

The bolded part will translate to your domain.username:password. And you need all of those items (including the “.” and the “:”) to be able to make the request. You may get a result like this when you run this command:

The part that’s not great is that we have to add the username with the password, in clear text. There are ways to get around this, and this post covers just one of them. EPMAutomate gets around this by using the “encrypt” option.

But as far as I know, this won’t work with REST calls. If we use a scripting language like Groovy (covered here), we know that credentials need to be converted into base64 format. All we need to do is follow the same method, for cURL scripts, or indeed, with any scripting option. For instance, most *NIX-based machines offer a base64 converter from the terminal.

The text string below is the base64-converted credentials needed.

By the way don’t forget to add the “-n”, otherwise, you will get an unintended newline character added to the end of the string, which you don’t want.

All you need to do now, is update your cURL commands with an added header. Include the string “Authorization: Basic convertedbase64string” as seen below.

You should now be able to use that string until the password changes. Of course, you can make this string a parameter in your scripts as well.

Bonus

If you don’t have a converter available, you can use an online converter as well.

Of course, anything that can be encoded like this, can also be decoded, but at least we have a different way to tackle REST-ful development for our EPM products.