The Policies page in the RaaS settings area of the Gigya Console allows the Site Administrator to define site policies for user registration and login. You need to be logged-in to access this page.
Note: This page provides a user-friendly interface for specifying the most significant site policies. The extended list of site policies may be accessed through the usage of the accounts.setPolicies and accounts.getPolicies API methods.
Watch an Instructional Video
If you have an SAP logon, you can watch an instructional video about site policies here.
The Policies page may also be accessed by clicking Settings in the upper menu and then Policies in the left menu:
Select the preferred login identifier for your users; the options are Email, Username, or both. If you select both, your users can choose whether to use their email or username for logging in:
The system does not allow duplicate Usernames or Emails.
Link Accounts Support
Set whether account linking is required when a user enters the system with an unregistered social network, which shares an e-mail with a registered account.
- Disabled - The accounts are not linked: a new (separate) account is created in which the email is not used as a login identifier.
- Site identities only - (Default) The user will be prompted to link the social network to an existing account which uses the same email as a login identifier, only if that account is a registered site account (not created by a social network login). The user can choose to create a new unlinked account which will not use the email as a login identifier.
- All identities - If any account on the system uses the email entered by the user as a login identifier, the user is prompted to link the social network to that account. The user can choose to create a new unlinked account which will not use an email as a login identifier.
Note: When enabling social-to-social account linking (by choosing the 'All identities' option), the corresponding screen-sets must be created to support account linking. Make sure that these are created as part of the default screen-sets schema of Gigya, or create them if necessary. Any Sites or Screen-Set Collections created after September 15th, 2014, have the necessary screens created by default.
Default Login and Registration Screen-Set
Select the default "RegistrationLogin" screen-set you wish to use in web and mobile.
The screens of this screen-set may be displayed when Gigya's logic recognizes a potential error that can be solved by displaying an automatically triggered screen. It will not necessarily be displayed when the user is already in a screen-set flow. For example:
- In an SSO setting, where site A and B are part of the same site group and SSO segment, site A has a "last name" field set to required, and site B does not. The user registers to site B without providing a last name, and then navigates to site A. The server attempts to log them in automatically, but is missing the required field. In this case, the Registration Completion field of the screen-set specified here will be displayed.
- Your policy requires users to verify their registration via a verification email. After verification, a user is missing a required field, and again the Registration Completion screen that belongs to this screen-set is displayed.
The screens of this screen-set will not necessarily be displayed in the following scenario:
- A user registers via the social login widget that is built into Gigya's registration screen, and therefore is missing a field that has been set to "required". The Registration Completion screen that will be displayed is the one that belongs to the same screen-set used for registering the user.
For more information, see Screen-Sets.
When the user registers to a site that requires email verification, they are sent an email to verify their address. The link appearing in the verification email automatically redirects to the landing page, which in turn, finalizes the registration process and logs the user in to the site.
Check this box to require users to verify their email addresses:
Email verification is done by sending a verification link to the email address registered to the user. You can specify the format of the verification email using the Email Templates page in Gigya's website. For more information, see Email Templates.
Once Require Email Verification is enabled, you must enable users to be able to complete registration. To do this, you must first ensure that you have an email field on the Complete Registration screen of your site's Screen-Set. You must also make sure that this field is set as Required in the site's schema. If you are using Gigya Default Screen-Sets, you can accomplish this by opening the Complete Registration screen in the UI Builder, selecting the Email field and checking the Required checkbox under the Schema tab of the Properties menu. Not doing this will result in users being unable to complete registration if their social network does not provide an email address, i.e., Twitter.
The following options are available once email verification has been selected:
- Customize redirection URL - The page to which the user will be redirected after verifying their email.
- Customize verification link expiration time - The number of hours that verification emails are valid.
- Automatically login users upon email verification - When selected, users will be logged in automatically once their email address is verified.
Activating Automatic Login
In order to use the Automatically login users upon email verification option, make sure to specify a Customize redirection URL and that the Automatically login users upon email verification option is selected in the site's Policies.
A sample html page can be found below.
Default Verification Flows
When activating the email verification policy, new users encounter the following default login behavior:
- For site users - When a user registers using the site's registration form, the user will be prompted to verify the registered email address by clicking the link in the verification email sent to the specified address.
Note: The verification email can be customized. More details in the email templates section.
- For social users - When a user registers using a social network account - the email address obtained from the social provider is considered a verified email address.
This setting can be overridden by setting the ' verifyProviderEmail' parameter to true when calling the accounts.setPolicies method. If 'verifyProviderEmail' == true, the email address obtained from the social provider is considered an unverified email, until the user verifies it.
- If no email was obtained from the social provider - the user will be asked to enter their email address, and verify it through the authentication link. To see which providers deliver the users email address on login, visit the data availability table on the user object page.
- Customize redirection URL: The URL to which subscribers will be redirected after successfully confirming their subscription. Note that upon successful confirmation, Gigya automatically appends to the query string of the URL a comma-separated list of subscription IDs. You can use this list to add custom code to your page that references these subscriptions (e.g., "Thank you for subscribing to newsletters A, B and C")
- Customize confirmation link expiration time (hours): The length of time (in hours) for which the confirmation link is valid.
Multiple Login Attempts
Multiple failed login attempts are now configurable via RBA, for additional information, see Risk Based Authentication.
The password strength is defined by:
- Min Length - minimum number of characters
- Min Character Groups - the number of the different character groups that must be included in the password. The character groups are: capital letters, lowercase letters, numbers and special characters.
If you define "Min Character Groups: 3", it means that a password should include at least three different types of characters. In such case, the following passwords would meet the requirement: Fcc3d1, YH*77P. And the following passwords would not meet the requirement: hwi654yy, 6FG5VV because they only include 2 character groups.
- Regular Expression - an alternative/additional way to specify password strength is by defining a string pattern that the passwords must match.
Supported regEx syntax can be found here.
In this section you may choose whether the password should be changed, and if so, after how many days.
You can also decide to forbid reusing a specified number of previous passwords. Regardless of this setting, the password can never be reset to the current one.
Gigya will remember the previous 7 passwords for the Forbid reusing any of the previous X passwords field.
For additional information regarding how you can use RaaS to reset a users password see Email Templates.
Age Limit - COPPA Compliance
Gigya supports forcing age restriction in compliance with COPPA rules. Enable this option to apply COPPA compliance and force a minimum age limit on new registered users to your site:
By default this option is disabled. When enabled, each time a user registers with your site, Gigya will check their age. Users must be 13 years +1 day old (to guarantee compliance due to time-zone variations) to register for your site. If they don't meet the minimum age requirements, they are prompted with the message "Your age does not meet the minimal age requirement (13+) for this site", if you are using our client-side tools (UI Builder/Markup Extensions).
If you are using direct server-side API calls (i.e., accounts.register) you will receive the following error in the response: "Underage user" (error code: 403044). For more information, see Identity Compliance.
If COPPA is enabled, it is important that all Registration/Registration Completion screens contain the necessary birth date fields, if a user is unable to provide their age, the user will be unable to finalize and complete their registration.
If a user enters a birth date in the future, the following error will be returned:
- errorCode: 400006, errorDetails: "Birth date must be in the past.", errorMessage: "Invalid parameter value"
Additional Security Measures
Choose whether additional security measures should be employed when users register to your site.
A CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is an identification procedure used to ascertain that a registration attempt is made by a human and not a robot.
Gigya implements Google's Invisible reCAPTCHA freeware. This means that the CAPTCHA component is an unobtrusive part of the registration screen, and triggered only if Google's algorithms identify a cause for suspicion, in which case the user will need to prove that they are human:
Implement CAPTCHA in registration screens according to the following guide: CAPTCHA.
To ensure proper registration form validation, be sure to include the CAPTCHA widget in every registration screen.
Login identifier harvesting, also known as account harvesting, is the process of grabbing legitimate user IDs to gain access to target systems for illegal or malicious purposes. You can protect against login identifier harvesting by enabling this option.
When enabled, new users will not be notified if a requested log-in ID already exists, while existing users entering an incorrect password will receive an "Unauthorized access error".
Because of its detrimental impact on user friendliness, this option is disabled by default.
If you enable this option, the following API methods change their behavior:
- The gigya-loginID-availability widget does not function, preventing new users from easily checking the availability of user IDs.
- The accounts.getConflictingAccount method always returns a "Not supported" error. This means that you will no longer be able to link accounts.
- The accounts.isAvailableLoginID method always returns an "Unauthorized access error" (code 403026).
- The accounts.resetPassword method returns error code '0' (indicating success), even when the loginID passed with the method does not exist in the system or the email address is improperly formatted.
- If a site account already exists and the user subsequently logs in with a social provider using the same email address, the accounts will not be linked and the socialize.login method returns error code '0' (indicating success) and creates a new account which does not use the email address as the login identifier.
- The accounts.register method:
- The Email Verification, CAPTCHA Validation, or both policies must be activated. If neither are activated, the accounts.register method fails with error code 401000.
- If either Email Verification, CAPTCHA Validation, or both policies are activated, and an invalid loginID is passed, the method will return the same response it would return in the event that the loginID was valid.
Regardless of this setting, the Login screen (from the RaaS screen-sets) always displays a generic error message when a login ID doesn't exist and/or a password is incorrect.
- New user welcome - When enabled, a mail is sent after the user successfully completes registration. On sites where verification is required, the mail will only be sent after successful verification.
- Password reset confirmation - When enabled, a mail is sent after the user successfully resets their password, note that this is a confirmation email, and differs from thePassword Reset mail sent to a user who has forgotten their password.
- Account deletion confirmation - When enabled, a mail is sent after the user successfully deletes their account.
Email verification emails are enabled above.
TFA configuration is no longer set via site Policies and is now available as part of Risk Based Authentication.
Site Policies and SSO
You can override certain policies configured for the master site, in individual sites in a site group.
- Go to the Policies page for the relevant child site.
- Check the Override master settings checkbox for the relevant configurations (e.g., Additional Security Measures).
- Click Save Settings.
These are the settings that can be overridden by a child site:
- Default login and registration screen-sets
- Email verification
- CAPTCHA requirement for new registrations
- The sending of the following automated emails:
- New user welcome
- Password reset confirmation
- Account deletion confirmation
Some policies can only be activated or disabled on the master site, but can be fine-tuned on each member site.
For information about the parameters that can be overridden when using the REST API, see the following pages.
Advanced Policies Configuration
It is important to note that any time you make a field required in the site schema, you must include a field for the item within the Registration Completion screen of your site's Screen-Sets. Failure to do this will make it impossible for some users to register with your site.
While the Gigya console provides you with certain built-in policy schemas and options, these policies can be further customized using the accounts.setPolicies REST API.
The API allows for a greater range of flexibility when customizing site policies.
Please refer to the complete Accounts REST API documentation for all possible api methods available.