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.


Login Method Used


Anonymous login


Auto-login by URL parameter

By default this login method is disabled. You can enable it by setting the extractProfileFromURLParameter property of /atg/userprofiling/ProfileRequest to true.


Auto-login by cookie

By default this login method is disabled. You can enable it by setting the extractProfileFromCookieParameter property of /atg/userprofiling/ProfileRequest to true.


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.


Explicit login or registration in the Personalization module

The user signed in or registered using a login form that invoked /atg/userprofiling/ProfileFormHandler.


Explicit login or registration in the Personalization module under https protocol.

Similar to 4, but login was through secure sockets layer (https protocol).


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"
       <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"

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.