Authentication and authorisation in the AEC

11 Nov 2018 » Admin Console

In the last few months, I have been writing about how to manage users in the Adobe Experience Cloud (AEC). However, I have noticed that there are two concepts that people do not understand well: authentication and authorisation. I should have known better, as I did not know the difference well enough until not long ago. My purpose today is to clarify these two concepts in the scope of the AEC.

Authentication

Doing a quick search in duckduckgo.com, I found a definition that I quite liked: “proof of the identity of a user logging on to some network”. Or, in my own words:

Process of verifying that you are who you claim you are

For a very long time, this process has been carried out with a combination of username and password. We all know how tedious it is to generate multiple passwords, one for each application. Password managers have partially solved this issue. More modern solutions include 2 factor authentication and biometrics.

Now, in the scope of the AEC (in fact, for all Adobe SaaS tools), there are 3 possible ways of authentication, or, using more technical words, 3 identity types: Adobe ID, Enterprise ID and Federated ID. I know I have already explained the identity types in another post, but I thought it made sense to include them here, with more details.

Adobe ID

With this type, Adobe takes care of the authentication. It all starts with the user him/herself creating an account in https://account.adobe.com/. It is then the user’s responsibility to manage it. For added security, it has the option of adding a 2nd authentication factor. I think this is a fairly recent addition, so, if you have an Adobe ID and do not have this extra layer of security, stop reading and add it now. Resume reading the post once you have finished with this task 🙂

What is important here, from an enterprise perspective, is that if you add a user with an Adobe ID, you do not take ownership of the account. As I said above, the account is owned by the user and you rely on him/her to take good care of it. All you can do is impose restrictions on the password, to make it more secure. Also worth noting you can use one single Adobe ID to authenticate for multiple AEC instances. For example, I have access to more than a dozen AECs, from my colleagues and clients.

Finally, let me clarify one point of confusion. When you go to https://experiencecloud.adobe.com, you will see the following screen:

Even if it says “Adobe ID”, it is the same button for Enterprise ID and Federated ID. Just click on the button regardless of the type of account.

Enterprise ID

This is probably the least popular of all the options. In fact, I have never used it. It is a hybrid between Adobe ID and Federated ID: Adobe takes care of the authentication, but it is owned by the organisation. With more and more organisations using Single Sign On (SSO) solutions, I would not be surprised that the Enterprise ID account type became redundant in the future.

You start by claiming a domain, for example, mydomain.com. This means that all users with an email address under @mydomain.com belong to your organisation and you, as system administrator, directly take care of the account: you create it, you can reset the password and you can delete it. This is the most important difference with and Adobe ID.

Regarding the similarities with the Adobe ID, Adobe manages the passwords and you can select some restrictions:

Federated ID

This is a radically different solution to the other two: your organisation’s identity provider takes care of the authentication. Adobe plays no role here. We generally refer to this option by the acronym SSO, although it is more than SSO. It is, by far, the most secure solution:

  • The organisation owns the account.
  • Adobe does not store the password is its servers; this is the responsibility of the identity provider.
  • Your organisation can add additional constraints to the passwords.
  • You can add multiple-factor authentication on top of the password: SMS, biometrics, secure cards…
  • You can add more restrictions, like only authenticate if you are in the corporate network.
  • By removing the user from your organisation’s identity provider, the user effectively loses access to the AEC, even if the user in the AEC has not been deleted.

It is also the most convenient for your users. Instead of having to remember an additional password, once they have authenticated against the identity provider, they do not need to authenticate again for additional applications. In summary, if your organisation has an identity provider and your users authenticate internally using SSO, you should also use it for the Adobe Experience Cloud.

The process to set it up is similar to the case of Enterprise ID. You start by claiming a domain (e.g. mydomain.com). The next steps are a bit more complex and tend to cause some confusion, so I will explain it in another post. For now, just note that Adobe only supports the SAML2 protocol. Once the setup has finished, the AEC will redirect all users under that domain (@mydomain.com) to the identity provider to authenticate. This happens as soon as you enter your email address in the login page.

Third parties and Federated ID

One particular limitation of a Federated ID is that you can only use it with the organisation’s employees. However, it is very common to have 3rd parties, like agencies or consulting firms, working on behalf of the organisation. If they need access to your AEC instance, we have a problem: they are not employees of the organisation, so they cannot use the Federated ID model.

There are 3 possible solutions:

  • Fall back to Adobe ID. This is the simplest and quickest option, but it also means that the users of these 3rd parties will not comply with the security policies of the organisation.
  • Create accounts for all 3rd parties under the organisation’s domain. I have seen this in a few cases, but not all organisations like this approach.
  • Use a different domain. Create accounts under another organisation’s domain, to keep them separate from regular employees. For example: mydomain.com for employees, mydomain.info for 3rd parties. Adobe supports multiple domains in the same AEC, so this works perfectly well. I believe this is the most secure option.

Authorisation

I have not found any definition that I have liked in this scope. The one that looks best is “permission or power granted by an authority”. In other words, it is granting a limited set of permissions to the user to work with the AEC and is irrespective of the identity type. Basically, this is where you manage users in the Adobe Admin Console, adding or removing them from products, product profiles or groups. This, in turn allows or forbids a user from doing certain things in the different tools: accessing report suites in Analytics, creating traits in AAM or publishing libraries in Launch.

And this is all I wanted to say about authorisation. I know, I have written a lot about authentication and very little about authorisation. But, if you have reached this point, I am pretty sure you have already understood the difference. In general, the authorisation part is what everybody usually understands, forgetting about the authentication.

Combining the two together

I hope that it is clear by now: authentication and authorisation are two different activities, very much decoupled. What happens is that most of the times one happens after the other:

  1. Authentication. This is when a user logs in to the system. In the case of the AEC, I have explained the 3 options it supports. And this authentication happens every time you visit the AEC. However, if you have already authenticated, the system will recognise you and will not request again your credentials.
  2. Authorisation. The output of authentication, your identity, is passed to the next step. Now that the AEC knows who you are, it looks in its database to see what permissions you have and allow you to do or block you from what you were trying to do. This is also done with every action.

To finalise, let’s see a summary of how authorisation and authentication look like together in the AEC, depending on the identity type:

Identity type Who does the authentication Who does the authorisation Who owns the account
Adobe ID Adobe Adobe User
Enterprise ID Adobe Adobe Organisation
Federated ID Organisation Adobe Organisation

Related Posts