Policy¶

Overview¶

Since the first version of the Swivel Secure product was released in the year 2000, it has evolved to meet customer expectations and technological developments placed upon it. The authentication policies available to the administrator are wide ranging and can be complex in nature. This has resulted in a very granular product with many possible policy combinations.

Where is Policy configured?¶

The Swivel Secure ‘Core’ software contains a policy engine dictating a wide array of policy options from authentication method customisation parameters, credentials management, mobile and hard token policy, account lockout threshold and so on. The Policy menu can be found in the left hand menu under ‘Policy’, however you will also find many other settings in many other areas of the product that could be classed as policy.
The Swivel Secure ‘SSO’ software contains a Risk Based Authentication engine where a risk model can be defined for users logging in via the Identity Provider unified login portal (primarily for SAML based integrations). These ‘rules’ (or policies) can be defined under ‘Rules’, ‘Applications’ and ‘Authentication Methods’.

Policies can vary in their impact from being:

Global policy affecting all users
Authentication specific
Application specific
Group specific
Agent or RADIUS NAS specific

AuthControl Sentry Core Policies¶

In this section, we detail all of the available policies in the AuthControl Sentry Core. We include the functionality that these policies provide and where the policies are located within the software menus.

Security string type:¶

Description: Security strings can be comprised of numbers, upper case letters, lower case letter, mixed case letters or a mix of upper case letters and numbers.

Menu location: Policy -> General

Default setting: Numbers

Non-Existent Users appear to be:¶

Description: When a TURing image is requested for a user that does not exist, Swivel will still produce an image. This is to prevent a hacker determining which usernames are valid accounts. You can specify the type of image that is presented when a image for a non-existent user is requested. Therefore if all your users have PINs you should set this to PINned. If all your users are PINless, this should be set to PINless and if you have a mixture of users you should set this value to mixed.

Menu location: Policy -> General

Default setting: PINned

Account lockout time (minutes):¶

Description: Specifies how long an account will be locked out in the event of too many failed authentications. The default is 0, which means the lock will remain until an administrator or helpdesk user unlocks the user. If a period is set then after that period the account will be usable again. Note, however, that the lock flag is not reset until the user attempts to authenticate, so users will still appear to be locked even after the lock time has expired.

Menu location: Policy -> General

Default setting: 0

Maximum login tries:¶

Description: Maximum number of consecutive failed login attempts a user can make before their account is locked. Setting this value to ‘0’ allows infinite attempts. Note that setting the maximum to a high value or disabling it entirely greatly increases the risk of a brute force attack resulting in a successful authentication.

Menu location: Policy -> General

Default setting: 5

Audit Log Length (days):¶

Description: Swivel maintains an activity log for users. This setting determines how long this log is maintained. Entries older than this are removed by a scheduled job.

Menu location: Policy -> General

Default setting: 30

Inactive account expiry (days)¶

Description: Maximum number of days for which an account may remain inactive before it will be automatically locked by the inactive user check job. 0 means that the account will never be locked due to inactivity.

Menu location: Policy -> General

Default setting: 0

Auto. set credentials on user creation:¶

Description: Enable/disable the automatic creation and setting of user credentials when they are initially added to the user population. Note that users must be correctly associated with an alert transport in order for them to receive notification of their credentials.

Menu location: Policy -> General

Default setting: Yes

Auto. send provision code:¶

Description: If Yes, then new users will automatically be sent a provision code if they are configured as mobile app users and have a valid alert transport.

Menu location: Policy -> General

Default setting: No

Show bulk provision on User Admin page:¶

Description: This option controls whether the bulk provision feature is enabled. This feature will send a new provision code to everyone that is not currently provisioned or has a valid pending provision code, is configured a mobile user, and has a valid alert transport.

Menu location: Policy -> General

Default setting: No

PIN expiry (days)¶

Maximum number of days for which a PIN may be used. This policy is enforced both at the point of authentication and by the PIN expiry check job. In both cases the account will be locked if the number of days since the PIN was set exceeds the maximum. 0 means that the PIN never expires.