For starters, we should emphasize that there isn’t any one “correct” way to set up Identity Cloud. After all, the Identity Cloud has many parts, some optional, and some definitely not optional. On top of that, even when it comes to the mandatory items there isn’t always consensus on whether you should start by setting up A or whether you should start by setting up B (or maybe even C).

Because of that, this document shouldn’t be viewed as a step-by-step guide to setting up Identity Cloud. Instead, this document is more a collection of things that you might want to think about before you get too far along with your Identity Cloud provisioning. As a general rule, the exact order in which you do these things doesn’t matter. On top of that, many of these tasks can be skipped altogether. For example, you might choose never to implement social login. That’s up to you.

📘

And if you change your mind somewhere down the road? That’s fine: social login can be set up before you set up, say, Customer Insights or after you setup Customer Insights. For the most part, it makes no difference.

In other words, our focus here is on the concept of social login and whether you need it, and not on when to setup social login.

With that in mind, here are some key things you should think about (or, in some cases, actually do) before you go too far down the Identity Cloud path.

SSL certificates for Akamai Identity Cloud

All public-facing Akamai Identity Cloud endpoints are protected with HTTPS using newer versions of TLS. Identity Cloud's vendors are currently updating infrastructure and the Certificate Authority might change at any time without notice.

Customers who manage their Certificate Authority set on their own should consider setting up Akamai ION to manage SSL certificates. Alternatively, these customers might switch back to traditional certificate management so they don't incur downtime when a Certificate Authority changes.

Verify access to the Console

Console is Identity’s Cloud primary tool for administration and system management. Admittedly, everything you can do in Console you can also do by using the Identity Cloud REST APIs. It’s just that, in many cases, Console makes in a little faster and a little easier to carry out those chores.

It’s also true that, when you first subscribe to Identity Cloud, some key configuration information – such as your OIDC login URL and your API client IDs and secrets – are stored in Console. If you can’t log in to Console this information will be difficult, if not downright impossible, to retrieve.

All of which means that one of the first things you should do after subscribing to Identity Cloud is to make sure you can log in to Console and that you have access to everything you’re supposed to have access to. To log in to Console, point your web browser towards (https://console.janrain.com) and log in. If everything goes according to plan, the left side of the Console window will contain all the different features you can manage. For example:

That’s what you want to see. Alternatively, your login might be rejected, or you might to log in only to see something like this:

Either way, there’s a problem: maybe you’re using the wrong email address to log in, or maybe you haven’t been assigned an administrator role. Contact your Identity Cloud representative for help.

Configure Console agents

Managing and maintaining Identity Cloud isn’t necessarily difficult, but, at the same time, it’s rarely a one-person show. As a general rule, multiple people in your organization will need permission to view user profile information, to modify flows, to create and delete API clients. That means you can need add or remove Console “agents” (administrative personnel) and you’ll need to occasionally modify the permissions assigned to an agent.

All of this can be done at any time: it’s expected that agent management will be an on-going process. At the same time, however, the fewer agents you have when you start the provisioning process the fewer resources you’ll have to call on as you get more involved in setting up and configuring Identity Cloud. Because of that, it doesn’t hurt to start right away on planning who’s going to be doing what.

Background reading: Agent roles reference
Introductory videos: Role-based access control

Verify access to the Social Login Dashboard

It’s possible to implement social login without ever using the Social Login Dashboard: in fact, if you need to create custom providers for social login the Dashboard won’t be any help anyway. On the other hand, if you’re planning to use Facebook, Twitter, Google, Apple or any of the other more-popular social identity providers, you might find the Dashboard a quick and easy way to get social login up and running.

To verify access to the Dashboard, point your web browser towards (https://dashboard.janrain.com) and try logging in. If you see something similar to this, that’s good; that means you have access to the social login applications (properties) listed onscreen:

And if you see something like this:

That means you don’t have access to any social login applications, at least not with the email address you just logged in with. In that case, get in touch with your Identity Cloud representative.

Verify access to the Identity Cloud APIs

Although Identity Cloud includes powerful and easy to use GUI tools such as Console and Customer Insights, Identity Cloud REST APIs remain indispensable to administrators. That’s because:

• In some cases, REST APIs are faster (and arguably easier to use) than the GUI tools. Do you need to create 100 new user accounts? Reading the account information from a text file and creating those accounts with a single API call is probably going to be faster than creating those same accounts, one-by-one, in Console.

• In other cases, REST APIs are the only way to manage an Identity Cloud feature. With an occasional exception, Hosted Login, Webhooks v3, the SIEM event delivery service, and custom providers are exclusively managed by making API calls.

Because of that, one of the first things you should do with the Identity Cloud is make sure than you can access the APIs. The following table lists Identity Cloud’s API collections and provides information about accessing the endpoints in those collections:

Set up Customer Insights access

Customer Insights is your primary tool for reviewing (and visualizing) information about your website or app: how many users are creating accounts, how many users are deleting accounts, how often are users logging in. When you subscribe to Identity Cloud you’re given 5 Customer Insights licenses; however, it’s up to you to determine who should get a license and who shouldn’t. After you’ve made up your mind on license distribution, you’ll the need to complete the Portal Access Management process in order to make sure those users get access to Customer Insights. This is something you need to do; might as well do it right now.

Background reading: Configure Customer Insights portal access
Introductory videos: Customer Insights training videos

Verify your discovery document and JSON Web Key URLs

As a new subscriber (and we’re assuming it’s primarily new subscribers who’re reading this article) Hosted Login is typically going to be your choice for managing user logins and registrations.

📘

Is there an alternative to Hosted Login? Yes: you can always use an API-based implementation of Identity Cloud. An API-based implementation offers more flexibility, but also requires more effort and considerably more programming skill.

Because of that, and before you start redoing Hosted Login screens or implementing Hosted Login authorization rules, you might want to verify that you can actually access Hosted Login in the first place. To do that, open up Console and, on the Manage Application page, look for the oidc_url setting:

The value for that setting is the issuer URL for your implementation of Hosted Login. For example:

https://v1.api.us.janrain.com/e0a70b4f-1eef-4856-bcdb-f050fee66aae/login

To verify that you can access Hosted Login, add /.well-known/openid-configuration to the end of the URL:

https://v1.api.us.janrain.com/e0a70b4f-1eef-4856-bcdb-f050fee66aae/login/.well-known/openid-configuration

That should be the URL to your Hosted Login discovery document. To verify that, enter the URL in the address bar of your web browser and see what happens. You should see something that looks like this:

If you see the discovery document you’re in business.

As long as you’re at it, you might tack /jwk onto the end of the issuer URL and give that a whirl:

Ideally, that takes you to the page shown in the preceding screenshot, a page that lists all your JSON Web Keys. If it doesn’t, contact your Identity Cloud representative.

Background reading: Discovery document; JSON web keys

Verify your Hosted Login components

There are plenty of decisions that need to be made when it comes to configuring Hosted Login: what do you want your screens to look like; do you want to use two-factor authentication; are you going to require more complex passwords – the list goes on and one. However, before you begin trying configuring two-factor authentication or before you begin writing regular expressions to enforce password complexity, you should probably verify that you have everything you need to get Hosted Login up and running. And probably the best way to do that is to follow the steps detailed in the article Verify components. And if that’s too much to read, don’t fret: each step is accompanied by a video that takes you through that portion of the verification process.

Background reading: Verify components

Decide if you want to use two-factor authentication

In its simplest form, two-factor authentication (2FA) works like this: a user visits your website or app and logs in, using either traditional login (i.e., an email address and password) or social login. If the initial authentication is successful, Identity Cloud sends the newly-authenticated user a one-time access code (this code can be sent either by email or by text message):

The user can’t be fully logged (for example, the user can’t access their use profile) until they supply the code sent to them.

📘

Again, that’s in its simplest form. When it comes to two-factor authentication, there are a number of options available to you.

Two-factor authentication provides you with an added layer of security: even if someone managed to get hold of a user’s password they won’t be able to log in unless they can manage to get the access code as well. At the same time, 2FA does add an additional step to user logins and registrations. You’ll need to decide whether the extra security outweighs any inconvenience (or at least any perceived inconvenience) on the part of your users.

And here’s another important factor to consider: two-factor authentication is only available with Hosted Login v1. If you’ve decided to use Hosted Login v1 then 2FA isn’t an option.

Background reading: Introduction to 2FA; Get Started Guide: 2FA & RBA
Introductory videos: Multi-factor authentication: Email; Multi-factor authentication: SMS

Decide which flow you want to use

The “flow” is a very large JSON file that contains configuration information on how your Identity Cloud infrastructure operates. The flow contains information about your fields and your forms and your translations and your transactional emails and …. When you subscribe to Identity Cloud, you’ll be given a single flow (standard) that can be modified as needed to meet your needs.

At the same time, however, you can also create your own flows (something typically done by copying an existing flow, and then making changes to that copy). For example, using Console we can see that this test implementation of identity Cloud has a large number of flows:

So is any of this really necessary for planning purposes? Well, it can be. Most likely you’ll end up with several different flows; at the very least, you’ll probably have a handful of flows used for testing and debugging. And if you do have multiple flows it’s important to know which flows are used in production and which flows aren’t. In a very simple case, suppose you have 2 flows; Flow A and Flow B. Flow A is your production flow, Flow B is your testing and development flow. Suppose an administrator adds a number of French translations to Flow B. Does that mean your Hosted Login screens can now be rendered in French? Well, sure, in the testing environment. But in the production environment, no, they can’t be rendered in French. And that’s because the translations exist only in Flow B, the test flow. Flow A, the production flow, is unchanged. To avoid this sort of confusion, decide which flows are to be used for which purposes and make sure to communicate those decisions to everyone who might edit those flows.

📘

Yes, it can get a little more complicated than that. See Why you must promote your flows for more information.

Decide which entity type you want to use

In Identity Cloud, users (and user accounts) are more technically known to as “entities,” and the user databases that store those accounts are known as “entity types.”

📘

One quick clarification: although an entity type is usually used to store user profile information, there’s no reason why an entity type has to store user profile information. In theory, you can store pretty much any type of information you want in an entity type.

When you subscribe to Identity Cloud you’ll be given a single entity type – user – set up to store your user profiles. This entity type is not set in stone: you can modify the database as needed. For example, the default entity type schema doesn’t include an attribute (e.g., newsletterSubscriber) to indicate whether a user has subscribed to your newsletter. That’s fine: it’s very easy to add attributes to an entity type. (Or, for those who aren’t fluent in Identity Cloud, adding a field to a database.)

It's also possible to create additional entity types; for example, you might want to keep customer accounts separate from employee accounts which are all kept separate from vendor accounts. There’s no problem with that either: create as many entity types as you need. Just remember two things:

• Hosted Login has specific requirements when it comes to entity types: it expects to see certain attributes and it expects those attributes to have particular names. Before you start using a custom flow with Hosted Login you might verify that your custom flow includes all the attributes found in the standard schema.

• Make sure other administrators understand what each entity type is supposed to be used for. Specifying the correct entity type is very important in user logins. Suppose Karim Nafir’s user account is stored in the user entity type. However, Hosted Login has been configured to use a custom entity type named customers. When Karim logs on, Hosted Login checks for his account in the customers entity type. When no account is found (because Karim’s account is in the user entity type) his login is rejected.

Background reading: Default user schema

Decide which version of Hosted Login you want to use

Although we tend to speak of Hosted Login (singular), there are actually two versions of Identity Cloud’s premier login and registration application: Hosted Login v1 and Hosted Login v2. As you might expect, the two versions have a lot in common, but there are some significant differences, most notably the fact that Hosted Login v2 allows you to use more advanced security functions such as two-factor and client-based authentication, and Hosted Login v1 does not. See Supported features for more information.

Regardless of the version you decide to employ, you must always start by installing and configuring Hosted Login v1, It’s only after the v1 version is installed that you can upgrade to the v2 version. Note that you can do this upgrade at any time: you don’t have to upgrade to v2 immediately after installing v1. Similarly:

• If you upgrade to v2 and then decide you don’t want this added functionality after all, it is possible to revert back to Hosted Login v1. Of course, a better approach might simply be to disable the v2 functions – such as two-factor authentication – that you aren’t interested in.

• It’s possible to run Hosted Login v1 and Hosted Login v2 simultaneously. Whether that’s a good idea or not is debatable (some of the differences between the two versions could cause confusion for your users) but it can be done.

Background reading: Introduction to Hosted Login v2; Get Started Guide: Hosted Login; Get Started Guide: Upgrade to Hosted Login v2

Set up a system for verifying token signatures

After a user has successfully authenticated with Hosted Login, that user is issued (among other things) a signed identity token. The token signature (affixed by Hosted Login) helps prove two things:

• That the token hasn’t been changed since it was issued.
• That the token was issued by Hosted Login.

Or at least it helps prove those two things as long as the signature is verified. There’s no requirement that says you have to verify token signature, but it’s highly recommended, in the interests of security both for yourself and the user, that you take this extra step. Identity Cloud doesn’t provide any tools for verifying token signatures, but you can find a large list of third-party tools for verifying signatures on the aptly-named Libraries for Token Signing/Verification page.

We should also note that, in addition to identity tokens, the security event tokens issued by Webhooks v3 are also signed and, as you might expect, should also be verified.

Background reading: Token reference

Design your Hosted Login screen

When it comes to customizing Hosted Login screens, the possibilities are (almost) endless: you can change fonts; you can change screen colors and layout; you can replace the default Akamai logo with a logo of your own; you can change all the messages and labels that appear on a screen. Although these changes can be made at any time, there’s an obvious advantage to making your modifications before your Hosted Login site is open for business. After all, that way, you aren’t disrupting the user experience by making a change today, and another one tomorrow, and yet another one the next day.

If you want to customize your Hosted Login screens (and, trust us, you do) we recommend checking out our guides to CSS (used to modify the look of your screens) and our guides to changing the text displayed on those screens. This, by the way, is one area where Hosted Login v1 and Hosted Login v2 differ: the screens often look identical, but they typically use different CSS classes and different JTL tags (used to manage screen text). If you decide to use Hosted Login v2, make sure you follow the guides for updating the v2 screens. (And, of course, the same is true for Hosted Login v1.)

Background reading: Add custom CSS stylesheets; Modify screen text
Introductory videos: Modify Hosted Login screen text; Screen customization

Translate your Hosted Login screens

In theory, Hosted Login screens can be displayed in any number of different languages (including – yes – Klingon). We say “in theory,” however, because Hosted Login ships with only one language: US English. That means that, by default, your Hosted Login screens all use US English. If you want your screen text localized into French or Pashto or even Klingon then you need to create those translations yourself.

What translations are we talking about? Well. for example, on the sign-in screen you’ll see the wording Sign in to reap all the benefits of this fantastic website:

To display this same text in Maori (Waitohu ki te kokoti i nga painga katoa o tenei paetukutuku whakahirahira), you need to create the translation and then add it to your Hosted Login flow. This isn’t difficult, but it can be a little time-consuming. Therefore, it’s best to determine your localization needs ahead of time, and not assume that you can simply create a fully-localized version of Hosted Login in the 15 minutes left before your site goes live.

Background reading: Localize screen text

Decide which authorization rules you want to use

Authorization rules provide a way to ensure that no one can log in to your site unless their user account meets the specified criteria. With Hosted Login (both the v1 and the v2 versions) you can enable authorization rules that prevent users from logging in if:

• They haven’t provided the requisite information. For example, if you need cell phone numbers before users can be logged in you can deny access to any user who fails to supply that number. You can do the same thing for the organization the user works for, the country they live in, or any other bit of information stored in the user profile.

• They don’t meet your minimum age requirements. This type of “age-gating” is based on the value of the birthday attribute in the user profile. For example, if you specify 21 years as the minimum age for your users, someone born in 2008 won’t be allowed to log in. And neither will anyone who declines to provide their date of birth.

• They haven’t verified their email address. When a user creates an account they’re given the chance to verify their email address. (How they do that depends on the version of Hosted Login you’re using.) Until that address is verified users won’t be able to log in.

• They haven’t agreed to your privacy policy and terms of services. (Collectively, these two items are also known as your “legal acceptances.”)

• They have agreed to (or at least made a decision on) one of more “user consents.” By default, Identity Cloud includes a single consent, one geared around marketing. However, you can create additional consents as needed.

Although authorization rules can be turned on and off at will, it’s usually best to have those rules ready from day 1. Nothing can be more frustrating to a user than a website they’ve patronized for months suddenly announcing that they can’t log in without providing their cell phone number or their date of birth.

📘

Yes, sometimes things come up that leaves you no choice but to start asking for X, Y, or Z. Nevertheless, it’s a good idea to minimize those times as much as possible.

Background reading: Authorization rules
Introductory videos: authorization.rules.consents (video); authorization.rules.email_is_verified (video); authorization.rules.min_age (video); authorization.rules.required_attributes (video); authorization.rules.legal_accepted (video)

Decide if you want to customize transactional emails and 2FA messages

“Transactional emails” are Identity Cloud emails automatically sent in response to user actions such as creating an account, clicking a Forgot Password link, or asking you to verify your email address. Two-factor authentication (2FA) messages serve a similar purpose, the main difference being that 2FA messages are often sent by using text messages rather than email. (Although 2FA messages can also be sent as transactional emails.)

Both transactional emails and 2FA messages are automatically configured for you when you subscribe to Identity Cloud and no changes to those messages are required. But while you don’t have to make changes to these messages you might want to make changes to them. For example, you might want to change the wording used in a 2FA text message or you might want to use CSS to add your organization’s branding to a transactional email. This might not be the most pressing issue when it comes to setting up Identity Cloud, but it’s something you should think about.

Background reading: Modify transactional emails; Modify a 2FA message; Format 2FA emails by using CSS

Update your Hosted Login links

We mention this one because it’s so easy to overlook. By default, Identity Cloud provides three links that are used on Hosted Login screens:

• A link to your help center.
• A link to your privacy policy.
• A link to your terms of service.

Having these links is a good: users should have access to these items. At the same time, however, Akamai has no way of knowing the actual URL to your help center or your privacy policy. Because of that, and by default, these links don’t actually go anywhere. Instead, clicking the help center link on, say, your sign-in screen simply opens another copy of the sign-in screen, either in a second tab or a second window (depending on your browser configuration).

That’s not an especially good customer experience, so before you declare your website open for business you might want to update these URLs.

📘

Can you add additional links to Hosted Login screens? Well, there’s a bit of trial-and-error involved, but yes, you can. See Create a Hosted Login link for more information.

Background reading: Change the target of a Hosted Login link
Introductory videos: Redirect the Visit our help center Link

Decide which existing user accounts you want to migrate to Identity Cloud

Many organizations (probably most organizations) have an existing set of user accounts, possibly accounts collected by another Customer Identity and Access Management platform. For some organizations, this is thought to be a roadblock to moving to Identity Cloud: what do they do with their current set of several hundred thousand (or even several million) user accounts? Can they really switch over to Identity Cloud and then ask their users to re-create their accounts, from scratch, on this new platform?

Well, they could. But a better approach might be to migrate all those accounts to Identity Cloud: that way no one has to re-create their account. Instead, Identity Cloud’s data migration process can move over the entire account for each user, including any personal information found there (address, phone number, favorite baseball team) and even the user’s current password. If all goes well (and it usually does) you can switch to Identity Cloud and no one will ever know the difference.

That said, depending on the number of user accounts you need to migrate and depending on the amount and the complexity of the data stored in those accounts, it can take at least some time and effort to get everything configured just the way you want it configured. (Although the data migration process does include a “dry run” option which enables you to test the proposed migration as many times as want, but without actually copying over any user accounts.) There’s typically no need to migrate user accounts immediately: after all, if you migrate accounts in January but don’t open your website for business until July those migrated accounts will be six months out of date. However, because there will be some work involved, there will be some tweaking and editing involved, and there will be plenty of testing and trial runs involved, the sooner you start thinking about data migration the better.

Background reading: Self-service data migration; Alternatives to self-service data migration

Decide if you want to use social login

The whole idea of social login is pretty straightforward: instead of requiring users to create a username and password specifically for your website or app, you enable them to log in by using, say, their Facebook account or their Twitter account.

📘

OK, technically, a user logs into Twitter, and Twitter passes information (and a Twitter access token) for that user back to Identity Cloud. If Identity Cloud has a user account that corresponds to the Twitter account then the user is logged on even though they never entered an Identity Cloud username or password.

Identity Cloud offers a wide array of options for social login, and for retrieving user information from a social login account. (Depending on the social login provider, it’s possible to retrieve a considerable amount of user data from Facebook or Twitter and then use that data to auto-populate fields in the user’s Identity Cloud user profile.) However, Identity Cloud also leaves social login entirely up to you. Don’t like the idea of using social login? That’s fine: don’t use social login. Happy to let people logon by using their Apple or Google account, but not so sure about some of these other social login identity providers? That’s also fine: enable social login but only configure Apple and Google as allowed providers.

Again, not something that must be done right this very moment, but something you should begin thinking about.

Create and configure social login identity providers

Adding social login providers to your sign-in screen is easy; for example, we added all these providers to Hosted Login in less than a minute:

Admittedly, it’s one thing to add social login providers to the sign-in screen but a whole ‘nother thing to ensure that users can employ that provider to log in to your website or app. Yes, you need to make sure your social login providers are available from the sign-in screen. In addition to that, however, you typically need to, at a minimum:

• Create a social login app on the identity provider’s developer site. For example, to enable people to log in by using their Facebook account you need to go to the Facebook developer site and create a social login app:

  

• Configure Identity Cloud to recognize (and to use) this new app.

If you use one of social login identity providers supported “out of the box,” it’s relatively easy to configure the provider for social login. (See our Social login identity provider configuration guides for more information.) But what if you want to use a social login identity that isn’t in the box, what if you want to let people log in with their Twitch account or their Spotify account or maybe their Baidu account? That’s fine: custom providers enable you to use almost any identity provider as a social login provider as long as that provider supports OAuth 2.0, OpenID Connect, or SAML 2. For example, here we’ve configured Hosted Login to use Dropbox and Slack as social identity providers:

To log in to identity Cloud you can click the Slack button and then log using your Slack credentials.

Of course, there’s a little more work involved here (not a lot, but ….). Therefore, while you don’t have to enable social login on Day 1, it’s, once again, never too early to start thinking about it.

Background reading: Configure social login in Hosted Login
Introductory videos: Configure social login (video)

Decide if you want to use password history

If you occasionally require users to change their passwords: 1) there’s usually a reason for that; and, 2) you typically don’t want them to simply re-use their old password as their “new” password. By default, Identity Cloud doesn’t prevent users from doing this: a user with the password p@ssw0rd can “change” their password to, well, p@ssw0rd.

But that’s the default behavior. If you’re not a big fan of that, you can enable password history (aka unique password enforcement) and prevent users from reusing their last password, their last three passwords, even as many as their last ten passwords.

Like most Identity Cloud features, password history can be enabled and disabled at any time. However, there are at least some repercussions to toggling password history on and off: among other things, each time you disable password history your users’ previous passwords (stored in their user profile) are deleted. That might be reason enough to decide whether you want to enable or disable password history before users start logging in and changing their passwords.

Background reading: Introduction to unique password enforcement

Decide on your password complexity requirements

By default Identity Cloud is pretty lenient when it comes to user passwords: as long as a password contains at least 6 characters that password will almost always be acceptable. The password 123456? Acceptable. The password password? Acceptable. The password abcdefg – well, you get the idea.

If password security isn’t an issue for you (and, depending on the nature of your site, it might not be) then you can skip this section altogether. However, if you don’t like the idea of users using a password like password you can modify the value of the regex_standard_newPassword setting. If you look at your application settings in Console, regex_standard_newPassword probably looks like this:

.*

In case you’re wondering, .* is a regular expression that means, “Enter any character you want; we don’t really care.” As long as the password has at least 6 characters, well ….

And if that’s not acceptable? Then replace .* with a different regular expression. For example:

^(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9]).{8,12}$

The preceding regular expression verifies that the password selected by a user has at least 8 characters (but no more than 12 characters), and contains at least one uppercase letter, one lowercase letter, and one number. And if that doesn’t fit your needs then replace it with one that does.

📘

We don’t explain how to create regular expressions in this documentation. But that’s mainly because the rest of the Internet has already taken care of that for us.

Decide if you want to use the SIEM event delivery service

Security Information and Event Management (SIEM) is probably the standard for collecting, aggregating, and analyzing security-related events that take place on your website. By combining Identity Cloud events with a dedicated SIEM analysis tool such as Splunk or IBM QRadar, you can keep tabs of practically everything that takes place on your site and, in at least some cases, be warned about potential security problems before they become actual security problems. SIEM is available as part of your Identity Cloud subscription, and you need to decide if you want to use it and, if so, what events you want to receive notifications for. In addition, you also need to make sure that Identity Cloud SIEM events can be imported into your SIEM analysis tool, something that can usually be done with very little effort on your part. But, as they say, better safe than sorry.

Background reading: Introduction to SIEM event delivery

Decide if you want to use Webhooks v3

Webhooks v3 can provide you with near real-time notifications any time a user creates, modifies, or deletes their user profile. And if that sounds like more trouble than it’s worth (do you really need to know every time a user changes their street address or zip code?) you can use event filtering to limit the number, and the type, of notifications you receive. For example, suppose you have a newsletter that customers can subscribe to, with that subscription status recorded in the user profile. In that case, you might want to receive a notification if a user’s subscription status changes, but not receive a notification if a user’s street address changes.

In other words, you have at least two decisions to make when it comes to Webhooks v3:

• Do you even want to use Webhooks v3? Although Webhooks v3 is available as part of your Identity Cloud subscription you’re under no obligation to use it. By default Webhooks v3 is disabled, and if you don’t need these notifications then you can simply leave the feature disabled.

• If you do choose to use Webhooks v3, which events do you want to be notified of and which events would you prefer to ignore? When making this decision keep in mind that Webhooks v3 deals only with user profile changes: creations, deletions, and modifications (any modifications). Before implementing Webhooks it might be worth taking the time to decide whether you need notifications for all these events or not.

📘

It’s also possible that you don’t care about user profile changes, it’s possible that you care more about failed login attempts or failed registrations. In that case, you might want to use the SIEM event delivery service instead of, or in conjunction with, Webhooks v3.

A note regarding webhook listener endpoints

When it comes to webhook notifications Identity Cloud keeps an eye on the event bus, watching for the events that you’ve subscribed to. When one of those events occurs, the event information is packed up as a Security Event Token (SET) and a notification containing the SET is sent to your listener endpoint. Identity Cloud makes up to six attempts to make a successful delivery. After the sixth attempt the notification is marked as failure and the event information is stored in the event store until: 1) 7 days have elapsed since the last delivery attempt; or, 2) you reschedule the notification for delivery. If 7 days have past and delivery hasn’t been rescheduled, then the notification is deleted from the event store. At that point, it’s gone for good.

Depending on how you want to look at it, that’s the extent of Identity Cloud’s responsibilities. The remaining steps in the process – setting up a listener endpoint, receiving and decoding the notification, verifying the token signature, archiving the event – are your responsibility. Which means it’s something else you’ll need to think about when it comes to Webhooks v3.

Background reading: Introduction to Webhooks v3; Introduction to Webhook event filters

Decide if you want to use Integration Bus

Integration Bus (a joint partnership between Akamai and SnapLogic) provides a way for you to share Identity Cloud user data with other platforms. Currently Identity Cloud supports two “data patterns”:

• An export data pattern that saves user data as a comma-separated values file (meaning that data can be imported by any platform that can read CSV files).

• A Salesforce data pattern that synchs Identity Cloud data with Salesforce Marketing Cloud.

If either (or both) of those capabilities are of interest to you, you might want to start thinking about what that actually means (for example, what user data do I want to include in my export; how often do I want to export data; what do I do with the data after its’ been exported).

Background reading: Get Started Guide: Integration Bus