- DarkLight
Authentication
- DarkLight
Campaign Manager supports two types of authentications:
Inbuilt token-based authentication where the user access is managed within Campaign Manager and it uses token-based authentication for web service access.
Third party SSO providers such as Okta, support OAuth based on SSO authentication, where the identity management is done by identity providers.
SSO Support
Campaign Manager supports Single Sign On (SSO) authentication using any OpenID connect. Campaign Manager uses OKTA for SSO authentication. Campaign Manager also provides support for SAML 2.0.
In the SSO authentication model, user management is done by the identity provider and the Campaign Manager application validates the token with the identity provider.
Token-Based Authentication
Tokens are issued by the server after verification of the user credentials and are used in subsequent request as part of HTTP header, failing which an invalid token is written and the request is rejected, necessitating a fresh login.
Tokens are valid till a period of inactivity on the part of authorized user – this is configurable. The user is logged out of the application on the expiry of this period of inactivity. Campaign Manager has this default time-out set at 120 minutes; this is configurable by the users. Once timed out, the user has to mandatorily login afresh. This fresh login generates another token for user authentication and access.
To support the above authentication, anonymous authentication should be enabled in IIS for the Campaign Manager applications, to ensure users have access to the Campaign Manager console login page.
Enabling Windows authentication at IIS level is not supported. This is because it forces the user to input the credentials more than once to access various features of the Campaign Manager application. Since Campaign Manager can be accessed over the internet, it is not recommended to enable Windows authentication at IIS level.
Both the above authentication methods use Token-based authentication, widely used in single-page applications (SPA) and statelessness (RESTful APIs) of the application:
User provides credentials.
Server verifies credentials and returns a signed token.
Token is stored in client side.
Subsequent requests to the server are sent with the token as authentication header (HTTP header).
Note:
Authorization to various options in Campaign Manager Console are handled based on the roles and rights assigned to the users.
Websocket Server Client Authentication
The application authenticates clients accessing the Websocket server in the following ways:
AuthKey: This is configured in the component web.config file
APIKey: This is configured in the Campaign Manager application
SSO: Using the Single Sign-on (OKTA) authentication method
Token: Using the Token Authentication.