Web sites need to balance the user’s convenience with the need for security. If security is critical, you will typically want to require the user to enter a user name and password to access your sites. If security is not critical, your site can use auto-login so the user does not have to manually log in.
In some cases, you may want to require users to log in manually only if they access certain pages. To do this, you can use a combination of auto-login and manual log in. A user can access a site without manually logging in, but must explicitly provide a user name and password before seeing restricted pages.
The securityStatus
property of the Profile
component is used to indicate the type of verification the user has passed through. When a user logs in (or is automatically logged in), the Personalization module sets the value of this property to an integer that indicates the login method used. You can then use this information in other areas of the site.
For example, if the user tries to access a restricted page, you can check the securityStatus
value. If securityStatus
indicates the user has already manually logged in, the restricted page is displayed; if securityStatus
indicates the user was automatically logged in, the site prompts for a user name and password before displaying the page, to ensure that no unauthorized person can access the restricted content. The system then changes the value of securityStatus
to indicate that the user has logged in manually, so future attempts to access restricted content during the session do not require re-entering the user name and password.
The following table lists the values of securityStatus
and the login methods to which they correspond. Note that the default value is 0. If a user accesses the site without logging in at all, the value of securityStatus
is 0. If the user logs in manually, or is automatically logged in, the system sets securityStatus
to one of the other values.
Value | Login Method Used |
---|---|
0 | Anonymous login |
1 | Auto-login by URL parameter By default this login method is disabled. You can enable it by setting the |
2 | Auto-login by cookie By default this login method is disabled. You can enable it by setting the |
3 | Login by http-(basic-authentication) The user has provided a login and password, but it was provided to and verified by the Web server, not the Personalization module. |
4 | Explicit login or registration in the Personalization module The user signed in or registered using a login form that invoked |
5 | Explicit login or registration in the Personalization module under Similar to 4, but login was through secure sockets layer ( |
6 | Certificate (not supported by ATG at this time). |
Repository Definition
The security status property is defined in the standard user profile template as follows:
<!-- The securityStatus property is transient but a column exists in the dps_user table.--> <!-- If you would like to use it, just put this property descriptor within the table tags.--> <!-- If this property is made persistent, you may also make it queryable.--> <property name="securityStatus" data-type="enumerated" default="ANONYMOUS" queryable="false" category-resource="categoryInfo" display-name-resource="securityStatus" property-type="atg.repository.SessionEnumPropertyDescriptor"> <option value="ANONYMOUS" code="0"/> <option value="URL-PARAM" code="1"/> <option value="AUTO-SIGNIN" code="2"/> <option value="HTTP-BASIC-AUTH" code="3"/> <option value="EXPLICIT-SIGNIN" code="4"/> <option value="SECURE-SIGNIN" code="5"/> <option value="CERTIFICATE" code="6"/> <attribute name="resourceBundle" value="atg.userprofiling.UserProfileTemplateResources"/> </property>
securityStatus
is a transient property by default, which means that it is not stored in the underlying database (for more information, see the ATG Repository Guide). It is also a property of type atg.repository.SessionEnumPropertyDescriptor
, which means that its state is maintained in the user’s session rather than in the cache for the profile repository item. This behavior ensures that each visit to the Web site produces a unique securityStatus
value, and that the securityStatus
always expires when the session ends.
Disabling Security Status
By default, security status is enabled. You can disable it by setting the enableSecurityStatus
property of the /atg/userprofile/ProfileTools
component to false
.
If you do not have the securityStatus
property configured in your profile definition file, the Personalization module automatically disables security status to avoid errors.
Security Status and Failover
In some cases you may want the security status to be reset for all users after server failover, requiring them to log in again. In other cases, it may be appropriate for your users’ security status to persist after failover. You can define this behavior through the failedOverSecurityStatus
property in the /atg/userprofiling/ProfileFailService
component.
By default, the property is set to 3 (basic authentication only; users must log in to the Personalization module again). If you set the value to -1, the users’ existing security status will be the same after failover.
If you change the value of the failedOverSecurityStatus
property, you must also add ProfileFailService.failedOverSecurityStatus
to the list of properties to fail over. See Enabling Session Backup in the ATG Installation and Configuration Guide for more information.