Service Credentials

Transcript

Now let’s take a look at service credentials which are the real credentials an external app will use to programmatically access AEM. On the service, local development access tokens, and service credentials seem similar as they both are used by external applications to programmatically access specific aims of cloud service environments, author or published services, and they’re obtained for specific environment through its developer console. The major difference is that service credentials are actual static credentials rather than an access token. Service credentials themselves are not directly sent to AEM to be authenticated. Instead, the external application uses these to generate a JWT, which is exchange with Adobe IMS for an access token, which can then be used to authenticate http requests to aim as a cloud service. So let’s take a look at how we can obtain, and use service credentials. We’ll head over to the AEM developers console, tap the integrations tab, and then select the technical accounts tab.

This tab lists any technical accounts associated with the selected AEM environment. You can think of technical accounts as the service user that the service credentials will authenticate to AEM as. The technical accounts eventually manifest in AEM as AEM users, which can then be permissioned. Also, if credentials for a specific technical account are compromised, they can be revoked without affecting other consumers.

So let’s go ahead and create a new technical account. This takes a few seconds, but when it’s done, we’re presented with the service credentials JSON object.

We’ll download this and use it in our app in a few moments. Notice that these are bonafide credentials, even containing a private key. These credentials should be stored, managed, and accessed in accordance with your organization’s IT security policy.

Before we jump back to our external app, let’s close this window, and check out the developer console again.

We can see that our new technical account is listed with each of its private keys associated with it listed below.

If we need to retrieve the service credentials again, simply expand the current private key, and then select view next to the active certificate entry.

Do note that a private key can have multiple active certificates which is very useful when updating expiring credentials. So what I mean by this is you can keep an expiring credential active, and then create a new certificate which will by default be active for a year.

Take the credentials from the new certificate, and update your app with them, and then revoke the expiring certificate resulting in zero service interruption.

Before we jump back to our external app, it’s worth noting that in order to remove a technical account, you must revoke and delete all certificates associated with the technical account. Only then will the delete option on the technical account drop down become available.

Okay, enough with the developer console, let’s head back and use our service credentials, and our external application.

For convenience, I’ll copy them from the downloads folder to my project folder. But remember, don’t check these index.js since they are credentials.

Then let’s update the application to handle either local development access token, JSON or service credential JSON. It’s nice to think about designing your application to handle switching between both, so significant code changes don’t need to be made between local development and real life production use. And the get access function will add an else condition to handle the case when service credential JSON is provided. Then we’ll need to do two things. One, generate a JWT using the information in the service credentials and two, exchange the JWT with the Adobe IMS API’s for an access token, we can then use with our http request to AEM. Since this is a node.js application, the easiest and best way to facilitate this is using Adobe’s JWT OAuth and PM module, which takes the config object comprised of select data from the service credentials, and exchanges it with Adobe IMS for an access token to AEM. This MPI module conveniently abstracts all this away into a single function call. If you’re using another programming language, or want to review the inner workings of the JWT construction and exchange with IMS, see the other sample code links provided below on this page.

With our new code in place, the rest of our application should work as normal. Passing the access token on the http request to AEM as a bare token and the authorization http header.

Okay, now let’s turn our application from the command line using the service credentials. This looks like the command line used to execute with the local develop access token JSON.

However, I’ll specify a new property value, so we can tell if the service credential base update works, and in the file prem, I’ll point to the JSON containing the service credentials downloaded from AEM developer console.

Running command, we see the first http request which reads the list of assets in the folder succeeds. However, the following request for metadata update of each asset fails. So why did this fail here, but not with the local development access token? The reason is the local development access token authenticates the request as the user who generated it, and my user is in the AEM administrator’s group meaning it as full read and write access to AEM, service credentials, on the other hand, authenticate to AEM as a discrete technical account user that is part of the AEM user’s access profile, meaning by default it only has read access. So this is why the read operation listing the assets succeeded; however, the update of the assets which is a write operation failed.

We can see and resolve this by heading over to AEM as the cloud services, tools, security, users.

At the top of the list, we see our technical account user whose login name maps to the email field in the service credentials JSON, and was loosely created upon first access using these service credentials generated access token.

Opening this user, we see it’s a member of the contributors AEM group which only provides read access to AEM. We can adjust this technical account user’s permissions in the usual manner in AEM. So for simplicity, let’s add it to the DAM User’s group, which provides right access to AEM. We’ll save our changes, and then head back and rerun the application.

And there we go, all our http requests appear to be successful. We’ll jump back to AEM, so we can check to see if our assets metadata has indeed been updated with a new property value.

And there we go, it has been. -