Understanding Security Layers for User Authentication
Since your Sugar® instance contains proprietary information, it is important that only authenticated users access the system. In order to protect your instance from unauthorized access, Sugar offers multiple layers of security for user authentication. This article describes the various user-related security features.
Sugar's password-enforcement mechanism allows administrators to configure password strength requirements, password aging, and system-generated passwords. For more information on configuring the various password management options in Sugar, please refer to the Password Management documentation.
Note: For instances that use SugarIdentity, password rules are configured in SugarIdentity via the Cloud Settings console. Please note that only some SugarCloud instances use SugarIdentity. Refer to the SugarIdentity Guide to determine if yours is configured to do so. Existing customers will be notified before their instances begin using the service.
- Password Requirements : Administrators can configure the length of the password, as well as the required character types in passwords. Please keep in mind that the longer and more complex a password is, the harder it is for a malicious entity to guess. When a user creates a new password, Sugar will evaluate it against the company's password requirements. The new password must meet all the requirements in order for the password to save.
Note: You can also specify words or strings that are not allowed in the password by clicking "Show Advanced Options". For more information on setting Regex requirements, please refer to the Password Management documentation.
- User-Generated Password Expiration : Sugar can force users to periodically reset their passwords. This adds extra security by minimizing the impact of shared or otherwise compromised passwords. Administrators can configure the password to expire in "x" number (e.g. 60 days) of days, weeks, or months, or after a specified number of logins to the system. The actual expiration date is unique for each user and relative to the last date they reset their password.
Note: Each time a user resets their password, the expiration interval resets.
- Login Lockout : To prevent unauthorized logins, administrators can also configure the login lockout feature which can prevent access to the user's Sugar account after a specified number of unsuccessful login attempts have been made. Once you have defined the specific number (e.g. 5) of unsuccessful login attempts that can be made, you can configure the length of time (minutes, hours, days) before the lockout restriction is lifted.
- System-Generated Passwords : Administrators can direct Sugar to generate a secure password for users who need a password reset. For added security, the system-generated password can be set to expire after "x" number of days, weeks, or months, or after a specified number of logins. The user will receive an email with their temporary password, which should be changed shortly after logging into their account.
Bots are malicious software entities that attempt to infiltrate web forms such as your Sugar login form in order to compromise your system or steal your data. Sugar can protect your instance from bots via CAPTCHA or honeypot protection methods.
Using CAPTCHA makes it difficult for a bot to attempt to reset a user's password and gain access to your system. A CAPTCHA is a scrambled image that a human can read but a bot cannot. When a user attempts to request a password reset, the user must enter the characters shown on the screen to verify that they are human. Sugar integrates with the CAPTCHA service called reCAPTCHA. For more information on enabling the CAPTCHA validation, please refer to the Password Management documentation.
Sugar also supports the honeypot method for bot protection. This technique is a non-intrusive method for validating human form submissions. It is more effective than traditional CAPTCHAs, which can be difficult for some human users to read. Honeypot validation adds hidden fields to your Forgot Password form that only bots reading the HTML will be able to see. A human will not be able to fill out these fields as it is invisible to them, but a malicious bot trying to force its way into your application will be able to fill it out. Sugar responds to these unauthorized attempts by blocking the bot from logging in. For more information on enabling the honeypot validation, please refer to the Password Management documentation.
Sugar can also be configured to accept LDAP authentication and/or SAML for single sign-on if it is implemented within your organization. Administrators can configure these options via Admin > Password Management.
Note: For instances that use SugarIdentity, LDAP and SAML authentication are configured in SugarIdentity via the Cloud Settings console. Please note that only some SugarCloud instances use SugarIdentity. Refer to the SugarIdentity Guide to determine if yours is configured to do so. Existing customers will be notified before their instances begin using the service.
Directory Services Integration
Sugar supports LDAP or Active Directory for centralized management of passwords across multiple systems. This allows you to integrate Sugar with the identity management system you already have in your infrastructure. When users in your system attempt to log into Sugar, the application will authenticate them against your LDAP directory or Active Directory. If authentication is successful, the user is allowed to log into Sugar. If the authentication is unsuccessful, Sugar will then attempt to verify the provided credentials against its own database of valid usernames and passwords. For more information regarding LDAP, please refer to the Password Management documentation as well as the Configuring LDAP Authentication Using Active Directory and Restricting Which LDAP Users Can Log In articles.
Sugar provides SAML support for single sign-on (SSO) authentication as another option for centralized management of passwords across multiple systems. SSO allows a user to log in just once for affiliated but separate websites. Users can have one password to log into all of their applications, including Sugar, so that they do not have to remember multiple passwords. SSO also allows network administrators to manage users' passwords from one application. There are many authentication providers that utilize SAML for SSO. For more information, please refer to the following resources:
- Configuring SSO With Active Directory's ADFS in Sugar 7.9 and Lower article
- Configuring SSO With Active Directory's ADFS in Sugar 8.0 and Higher article
- Password Management documentation.
OAuth 2 Framework
OAuth 2 is a standard for authorization that enables users to share private resources stored on one site with another site without divulging personal credentials such as username and password. This acts as another single sign-on option that prevents unauthorized access through the use of security tokens. OAuth 2 tokens are also used to authenticate with the Sugar API. For more information on OAuth 2, please refer to the System documentation.
Session rules force the automatic termination of a user's session due to security reasons or when any suspicious behavior is detected.
Validate User IP Address
Sugar can be configured to forcibly log out if a user's IP address changes in the course of a session. This prevents hijacking of the session by an attacker who wants to take control of the connection. This security feature is labeled "Validate user IP address" in Sugar and may be toggled on or off via Admin > System Settings. For more information regarding this setting, please refer to the System documentation.
Prohibit Concurrent Sessions
Sugar only permits a username to be logged in under one session. So if a user is engaged in a Sugar session and any additional user sessions are started using the same username on a different browser or computer, Sugar will log the user out of their first session. This prevents multiple concurrent user sessions. While this means that a user may get logged out of Sugar, it also serves as a critical alert to the fact that a third party may have authenticated as the user somewhere else.
The following chart describes how concurrent sessions are handled when it comes to accessing Sugar via multiple devices. Please note that Sugar may also be accessed via the mobile app or via a mobile device's browser. Mobile browser access is the same as desktop browser access.
|Browser Logins||Mobile App Logins||Result|
|0-1||2+||Forced reauthorization in the mobile app|
|2+||0-1||Forced logout in the first browser session|
Idle Timeout Period
When a user does not perform any actions in Sugar for a certain period of time, the user is automatically logged out of the system and will be forced to log back in. For example, if the user is accessing Sugar from a public computer and fails to log out, this will help ensure that the user's account gets logged out eventually preventing any unauthorized access to the system. By default, users are logged out after 1 hour of inactivity. Please note that administrators can configure the inactivity timeout via a code-level customization.
When automatic notification queries are made (every 5 minutes by default) to the server, Sugar interprets these queries as user activity which can cause the inactivity time to start over and keep the current session active. In order to prevent this from happening, you can set Sugar's notification delay to be greater than the user inactivity timeout limit (e.g. 1 hour). For more information regarding the default inactivity timeout settings as well as configuring the logout period and Sugar's notification delay, please refer to the Troubleshooting Sugar Logging Out Unexpectedly article.
Administrators can run tracker reports to monitor active IP addresses in Sugar. The organization's security manager can then compare the IP addresses accessing your Sugar instance with a list of known IP addresses for your users to identify any anomalies. Unusual IP activity is a clue that unknown entities may be trying to use Sugar. For more information, please refer to the Understanding Tracker Reports article.
Last modified: 2019-11-14 21:45:14