Symantec Access Management

In our project we use a custom authentication scheme (custom java code). We also have a password policy to make user login inactive for 30 minutes after the user provides 3 incorrect passwords.

The custom authentication scheme talks to a web service which manages security questions and answers.

The issue we face is as follows.

User enters 3 incorrect passwords, account gets locked and the user is directed correctly to the smpwservices.fcc page.

The account gets enabled back after 30 mins. (Which is again the right thing to happen)

During the lockout period, if the user tries to login with the correct user name and password, then the custom auth module gets invoked and the user is prompted for a security question. (Which should not happen)

Even if the user enters the correct answer(so the custom module send an Accept response), siteminder redirects user to smpwservices page which shows the message that account is locked due to excessive login attempts.

The problem is that the user should not asked security question if the account is locked due to exceeded login attempts.

How do we correct this.

Any body able to help with this please.

Hello,

Not sure about your custom authentication scheme process but the security question is triggered before the authentication attempt and the account is locked and ckecked by during the authentication. You should modify your authentication scheme to do a first check before the security question or to do the security question one the authentication attempt has been done.

Hope it helps,

Julien

Thanks for the reply Julien. My thoughts are in the same direction. Is there any API which is available to check whether the user account is locked due to exceeded login attempts.

I am currently calling UserContext.authenticateUser() in my custom code before we reach the security question code. But its giving me a blank string back. It should return a null if the authentication fails, which is not happening...

Is there any other API that we can/should use in addition to authenticateUser.

Here's what I am planning to do . Check the disable user property in the custom authentication scheme and send the following response.

return new SmAuthenticationResult(SmAuthStatus.SMAUTH_ATTEMPT, <as given below based on the disabled attribute value>);

  private static final int ENABLED_STATE_DISABLED_BIT = 0x00000001; // 1

  REASON_USER_DISABLED

  private static final int ENABLED_STATE_MAXLOGINFAIL_BIT = 0x00000002; // 2

  REASON_EXCESSIVE_FAILED_LOGIN_ATTEMPTS

  private static final int ENABLED_STATE_INACTIVITY_BIT = 0x00000004; // 4

  REASON_ACCOUNT_INACTIVITY

  private static final int ENABLED_STATE_PWEXPIRED_BIT = 0x00000008; // 8

  REASON_PW_EXPIRED

  private static final int ENABLED_STATE_PWMUSTCHANGE_BIT = 0x01000000; // 16777216

  REASON_PW_MUST_CHANGE

Is this appropriate. I had earlier tried rejecting the user SMAUTH_REJECT if the disabled flag is 4. But that doesnt work.

From what I understand, when the user logs in after the set time interval (in my case its 30 mins) for the account to remain locked, if he/she provide the right password, siteminder then resets the disabled flag based on the values available in the "Password Data" attribute. This is done by the password policy module which gets invoked after the custom authentication module.

If I return SMAUTH_REJECT from my custom auth module, siteminder never reaches the password policy module and hence the disable flag is never reset.

Is this understanding/assessment correct.

I've worked around it and solved this.

As a matter of fact, password policy is only applied and verified after custom authentication is done. so rather than accepting/rejecting/failing custom authentication from my code and thus affecting the decision based on the user disabled attribute (here I was trying to stand in for password policy rather crudely),

I just make sure that if the password is expired/disabled, I will refrain from asking the security question and let the code go through. The password policy will then come into effect and take its course.

The only problem is once the user has ben locked for 35 mins lets say (which means that by the time you try to login the user is unlocked), the user disabled attribute is still set to 2 and I do not ask the security question. Once it hits the password policy module, the expired time is taken into account and the user is unlocked.

so for that login alone security questions are not asked where it should have been.

from then on normalcy resumes.

Its not a perfect solution.. but works!!