The General Event Delivery Service Whitelist

The General Event Delivery service is the Identity Cloud’s new method for generating event information, maintaining a data warehouse of that information, and – equally important – making many of these event types available to customers. At the moment, the event types exposed to the SIEM Event Delivery Service include the following:

Event Name

Description

config_change

A customer configuration value was changed by using Identity Cloud APIs.

email_verification

A user successfully verified their email address.

legacy_otp_signin

A user successfully authenticated by using a one-time password (OTP).

legacy_social_registration

A user successfully registered by using a third-party identity provider.

legacy_social_signin

A user successfully authenticated by using a third-party identity provider (IDP).

legacy_sso_signin

An end user was automatically authenticated by using single sign-on (SSO). This event occurs because the user either (1) visited a new website within the collection of sites using SSO; or, (2) had their SSO access token refreshed by a previously-visited site.

legacy_traditional_registration

A user successfully registered by using an email address and password.

legacy_traditional_signin

A user successfully authenticated by using an email address and password.

profile_create

A new user profile database record was created. 

profile_delete

A user profile database record was deleted.

profile_update

A user profile database record was updated. This event is fired with numerous other events; for example, each successful login updates the lastLogin attribute of a user profile.

entityCreated

Indicates that a new entity type record (typically a new user profile) has been created.

entityUpdated

Indicates that an entity type record (typically a user profile) has been updated. This record includes the names of the attributes that have been modified, but does not include the old or the new values assigned to those attributes.

entityDeleted

Indicates that a record (typically a user profile) has been deleted from an entity type database.

authenticationFailedKnownUser

Indicates that registration has failed for a known user (for example, a user recognized by his or her email address). The reason property will contain one of the following values:

  • accountDeactivated. Authentication failed because the user record has been deactivated.
  • invalidCredentials. Authentication failed because the user submitted an incorrect password.
  • null. Authentication failed for an unknown reason.

authenticationFailedUnknownUser

Indicates that registration has failed for an unknown user (typically a user who submitted an unregistered email address). The reason property will contain one of the following values:

  • unknownUser. Authentication failed because the specified email address does not exist in the entity type database.
  • invalidGrant. Authentication failed due to an invalid access grant request (for example, the user provided an invalid social login token).
  • null. Authentication failed for an unknown reason (for example, a user did not complete social login).

credentialAuthenticationAttemptsExceededKnownUser

Indicates that a known user (as determined by a unique identifier such as the user’s email address) has exceeded the login attempts threshold. By default, a user is allowed a maximum of six login attempts in a 60-second period before being temporarily locked out of the system.

This event can be useful in identifying potential SPAM attacks or account breaches.

Alternatively, it can also point to a user who has simply forgotten his or her password.

credentialAuthenticationAttemptsExceededUnknownUser

Indicates that an unknown user (e.g., a user without a registered email address) has exceeded the login attempts threshold. By default, a user is allowed a maximum of six login attempts in a 60-second period before temporarily being locked out of the system.

This event can be useful in identifying potential SPAM attacks or account breaches.

Alternatively, it can also point to a user who has simply entered an incorrect email address when attempting to log on.

In addition to the events listed in the preceding table, additional events are being developed and will periodically be released to SIEM subscribers. That, needless to say, leads to an obvious question: what happens when the Identity Cloud releases new events? Will Akamai have to rewrite applications (such as the SIEM Event Delivery service) in order to allow for these new event types? Will customers have to reconfigure their current setup and create new event subscriptions? It’s nice that you want to extend airline service to our town, but what good does that do us if we don’t actually have an airport?

Fortunately, those are questions, and concerns, that you don’t have to worry about. Instead, any time new customer-exposed events are added to the event delivery system (a process referred to as “whitelisting”), those events are automatically made available to all SIEM event customers. There’s no need to reconfigure or reinstall anything, and no need to “subscribe” to these new events: those events will simply begin showing up in your delivery feeds. If Akamai decides to add 5 new events, Akamai support will make a single API call that adds those 5 events to the whitelist. And each and every SIEM-enabled application will automatically be subscribed to those new events. It’s that easy.

Note. And what if you don’t want those new events? That’s fine: you can always “blacklist” the new events, and then they won’t show up in your SIEM deliveries after all. And, if you later change your mind and would like to receive these events after all, you can just as easily remove events from your application-specific blacklist. The General Event Delivery service is designed to let organizations manage the service as they see fit. Do you want to receive notifications each time a user updates his or her user profile? That’s fine: by default the profile_update event (along with every other exposed event type) will be delivered to you. But you say you’d rather not receive notifications each time a user updates their user profile? That’s also fine: just add the profile_update event to your application blacklist. Like we said, it’s that easy.

The key takeaway here? There are actually two key takeaways. First, the whitelist is managed by Akamai and is global: whitelisted events apply to all SIEM-enabled applications without except. If the profile_update event type is available at Application A, that means it’s also available to applications B, C, D, and E.

Second, blacklists are managed by Akamai customers, and on an application-specific basis: if the profile_update event type is put on the blacklist for Application A, that has no effect at all on Applications B, C, D, and E. Those other applications all have their own event blacklist, separate and distinct from Application A’s blacklist. Manage the service -- and even your individual applications -- as you see fit.