Why do I need to enable third-party cookies to log into the Alert Logic console?

While Alert Logic® understands that the use of third-party cookies may be viewed as a privacy concern for some customers, we believe that cookies and federation are the only viable mechanisms to provide you with a reliable single sign-on (SSO) experience.

SSO is based on a chain of trust, and federation and cookies are well-documented and accepted mechanisms for asserting that trust:

• Through federation, a trusted system of the consumer (you, the customer) has a shared secret key with a trusted system of the provider (Alert Logic). This requires coordinated configuration of the consumer and identity provider systems in advance. It then allows the customer to assert an identity to the provider that is "trusted" and does not force the client (you, the user) to re-authenticate to the provider. Examples of federation include Okta and Zendesk, which are federated by an internal Alert Logic system, Auth0, that allows a login from any of the systems to be valid for all other systems.
  
  
• Through cookies, the client (you, the user) can authenticate against a system that is not trusted, and that system then sets a third-party cookie under the provider (Alert Logic) domain. The provider reads that cookie and authenticates it transparently to accept or reject the client.

There are other possible mechanisms for chains of trust, but federation and third-party cookies are the most widely accepted.

As for security or privacy concerns, third-party cookie schemes are widely used by advertisers and tracking systems in ways that can be suspicious or entirely illegitimate. Some web browsers will allow you to set per-domain rules for things like third-party cookies. You could choose to configure *.auth0.com, *.alertlogic.com, and *.alertlogic.co.uk to accept third-party cookies, and not allow any other sites. Depending on your browser, you may have to trust additional Alert Logic domains and those of our trusted providers, such as Zendesk, to have a complete SSO experience.

There is generally no other reliable way to provide an SSO experience without third-party cookies, other than federation or browser plugin schemes that limit our clients' ability to choose their consumption model and would significantly increase our cost of provider per-user access to our services. Ultimately, cookies have no implicit security violations, as a third-party cookie can be set by any domain, but can only be read by the trusted consuming domain, and provide no possibility of data leakage of any sort on the public Internet.