Hello! My name is Kerry Nelson and I am a Global Team Lead and a SME for SSO for the Cloud, I oversee the Digital Marketing side of the Cloud for such products like Analytics, Target, Audience Manager, Campaign, Adobe Experience Manager, Adobe Media Optimizer, Dynamic Tag Manager, etc. I have worked for Adobe for seven years. So that is a little about me, today I thought I would take a moment and post up here on SSO for the Cloud what it is and how do you get started. Try to help you understand what it is and how to get started.
Types of IDs out there:
There are three different account types that exist that users can use within the Cloud.
They are as follows: Adobe ID, Enterprise ID, and Federated ID.
I will explain on all of these below:
Adobe ID - is created, owned, and managed by the end user. Adobe performs the authentication and the end user manages the identity. Users retain complete control over files and data associated with their ID. Users can purchase additional products and services from Adobe. Admins invite users to join the organization, and can remove them. However, users cannot be locked out from their Adobe ID accounts. And the accounts can't be deleted or taken over by the admin.
The following are a few requirements and scenarios, where Adobe IDs are recommended:
By default, when we first setup your Cloud the users created inside are Adobe IDs represented by the Adobe logo.
Enterprise ID - is created, owned, and managed by an organization. Adobe hosts the Enterprise ID and performs authentication, but the organization maintains the Enterprise ID. End-users cannot sign up and create an Enterprise ID, nor can they sign up for additional products and services from Adobe using an Enterprise ID.
Admins create an Enterprise ID and issue it to a user. Admins can revoke access to products and services by taking over the account, or deleting the Enterprise ID to permanently block access to associated data.
The following are a few requirements and scenarios where Enterprise IDs are recommended:
Federated ID - is created and owned by an organization, and linked to the enterprise directory via federation. The organization manages credentials and processes Single Sign-On via a SAML2 identity provider.
The following are a few requirements and scenarios where Federated IDs are recommended:
So now that we have covered what the IDs are and the uses, let's talk a bit more about SSO for the Cloud so you can understand what our SSO looks like:
Typically, I find that most users that come to us when asking about SSO for the Cloud are actually looking to do Federated IDs, this uses SSO using SAML2 as mentioned above. What you also must understand is the SSO process we use is SP initiated NOT IDP initiated.
What that means is instead of you coming in by way of a dashboard icon this requires you to go to a URL address to start the connection.
What does login look like into the Cloud?
Here is what that workflow looks like:
Then once authenticated where we compare the record in the Cloud located in the Admin Console of the Cloud (adminconsole.adobe.com) to what is coming in on the attributes then we allow you in. Users will typically be taken to Feed as being the first place they will go depending though on permissions that they have setup.
So that is what your work flow currently looks like. There is a way to set a landing page for the user but it is by a per user setting where you go to the upper right corner of the screen you select the User circle icon, then you select Edit Preferences and then on the left of the new page will be Landing page where you will see the different landing pages you can set. Typically the default will be "Automatic". Once you save this setting the next time you login you will be redirected to that tool.
How do you get started with Adobe's SSO?
First you are required to claim a domain (I.E. tell us which domain you own). Usually, this domain is going to match the email address domain used to sign in on marketing.adobe.com. Unfortunately, sign in must always be done with a email address, usernames only are not an option.
To claim a domain, you'll go to the Admin Console (adminconsole.adobe.com). This requires you to have System Administrator access.
From the Cloud when you first login this is the process to get there:
1. Login to Cloud (marketing.adobe.com)
2. Once signed in select the product selector in the upper right corner (looks like 9 dots or checker board).
3. Select Administration on the list which will be the second on the list there.
4. Select Launch Admin Console.
5. Navigate to the tab in black called "Settings" the Identity section located on the left will be the first area where you get dropped off.
You will be then asked to select between claiming a domain as Enterprise, or Federated. Going back up to our Identity types at the top, if you intend to use this with SAML, then you will want to select Federated. If you just want it to be an extension of the network and just put people on the Cloud list to get in where all assets are owned by the organization when purchased then select enterprise.
Once selected, you'll enter the domain name and click submit. If the domain has already been claimed, it will tell you that the domain has been claimed. This typically means someone in your organization has already claimed your domain. It will ask you if you want to domain trust. What that means is you can effectively piggy back off of the settings already done by the previous team and link your Cloud to their Cloud setup. By clicking yes, I want to domain trust, this sends an email to the admins who claimed that domain that they will have to accept the approval. Once its done, the domain is linked and you can just go create users as Federated IDs and you are all set.
If its not done, then you will be taken to a screen giving you a DNS token. This DNS token is good for 365 days. It needs to go to the DNS team within your company. They put this token which we have given you in a copy/paste method to paste the token exactly as you see it send it to them. They put it on the DNS servers which will take about 48/72 hours to show up. Then you come back to this same spot in the Cloud and click the box of yes I have this on the DNS servers and validate. Once validated, we check to see if we can see that token. If we can, then the domain goes into the approval process where we validate if anyone else can use this domain. If not, then an email notification is set to you after we approve that your domain is ready for configuration. Sometimes though we are going to email you and ask you: "Hey did you mean to claim this domain as Federated or Enterprise? This is called a "Letter of Intent" just so we can get in writing that is what you meant to do. We do expect a reply on the email.
Usually along the lines of "Yes I did mean to claim domain: x" and it must be claimed as either Enterprise or Federated ID.And then we can release the domain to you for configuration or in the case of Enterprise ID setting up users.
The DNS token I mentioned at this point can be then removed from the DNS server as we have validated the domain.
Our requirements for setting up SSO:
To successfully set up SSO for Adobe software, IT Admins need the following:
Once you get your domain claimed, you and all admins for the organization will receive a notification from the cloud saying its ready to configure.
At configuration, we are going to ask you for the IdP Certificate which comes from the "Project" for your SSO setup. We will ask you for the IdP Login URL which will also be in that "Project" that you will need to setup usually done by the IT Admins. We are going to ask you which IdP binding you want to use. And then last on the list is the NameID so either Email address being the first thing you are going to use as a key to send us in the SAML response or Username.
As I have explained previously, email address means you send us: FirstName, LastName, Email
UserName means you send us: FirstName,LastName, Email, Username
Formatting of these attributes has to be as shown above or the system will reject the response and you will be scratching your head wondering why its not working.
Now before I go further let's talk about the certificate you need to send us:
Certificate tips: the certificate must be:
We give you our file with our cert info you need and you can configure your SSO setup. Then Activate the domain. Once a domain is activated Adobe cannot move it.
Tip: Renewal of an SSO cert you just have to come into the Admin Console go to Settings - Identity - Select Domain - click the Edit SSO configuration option and then select upload cert. See the section on Cert details below that explains what that cert must look like for us to accept it.
Then you go create the user as a Federated ID sometimes that means removing a user from Admin Console who is an Adobe ID. As a note you cannot remove yourself someone has to remove you if you are going to use your own account for testing.
I recommend having at least two or three people to do the testing check the permissions for the products so you have people in products. Side note if you try to just have someone login using the SSO process with just System Administrator access to the Cloud this will not work and you will be greeted with a 500 error. So make sure you give them more than just that.
Let's talk about troubleshooting. If you have to troubleshoot SAML our logs for SSO is inside of the Settings area in the Admin Console under the domain you claimed you will see a tab called Event Logs. These logs come from Okta who is our partner for SSO. They are delivered to the Cloud every 15 minutes.
Here is a link you can go to for the most common errors with SSO:
Errors signing in to Adobe products with Federated ID (SSO)
At the very bottom of this page you will also see for those of you reading this will see how to configure with different types of systems such as Azure, OneLogin, etc.
If you are still having issues with your SSO users please open a ticket to email@example.com put in the subject line SSO for the Cloud configuration help.
Also, we do offer consulting assistance for managing the SSO project and doing the setup if you would like to explore that option reach out to your CSM.
I hope that this has been informative, apologizes that this is long winded. If you have questions let us know!
Sign in to like this content
If the user doesn't exist in adobe marketing cloud , Will this sso configuration will create the user manually on log in for new users or it works only for the users who exist in marketing cloud only ?
We are having a requirement where all federated users should have access to analytics ? Can we configure the SSO such way that it provides the users with some default access .
Sign in to like this content
You need to create the user in the Admin Console its not Adhoc provisioning at all. So it is something you have to do.
Sign in to like this content
If The domain is claimed which matches your SSO then you will be first presented with the option to create the user as Federated ID and then there will be a secondary link below to do Adobe ID.
SSO does not mean user permissions so if users need access Analytics through SSO you can setup the users for SSO and then create what we call “User groups” and then create a user group of those users which would give them access to Analytics. If that is there only product then that would automatically drop them to Analytics as being where they get directed when they authenticate.
Let me know if you have any other questions.
Sign in to like this content
Do I need to delete and redo the set-up of a domain in the Identity tab at the Adobe adminconsole if that domain changed from primary to a secondary domain in GSuite? The domain is green and still shows as active but when I tried to login an account at the enterprise login when an app is launched in a deployed Macintosh, I get an error 403 “Service is not configured for this user”. Before the change, we were able to login users, shows the correct license and no errors.
We recently had to make changes to our GSuite domain from primary to a secondary at Google after we previously set-up the domain at the Adobe adminconsole.
The reason we had to do this is because of a conflict at our Google for education GSuite account when Google informed us that we can't have two primary accounts for our institution. We actually did not know that an older GSuite account existed when we set up the GSuite account which turned out to be a second account. The older GSuite account was set up over 10 years ago by another person and had forgotten that it existed.
I want to add in the above post that I redid the custom SAML app at Google admin since we have to start from scratch after changing the domain to secondary. The only difference is it's "On for selected orgs" narrowed to the secondary domain only.
I also edited the directory in the Adobe adminconsole to reflect the changes in the now secondary GSuite domain but stop short of deleting the domain at the Adobe adminconsole.
Sign in to like this content