When developing a Custom Authentication Scheme to include a reCaptcha
functionality, how to get the bad password count for a user, in order
to determine whether or not we should present him the captcha
Policy Server 12.8SP2 on RedHat 7;
Policy Server JDK 1.8.0_201 64bit;
Policy Store on CA Directory 14.1;
At first glance, out of the box the custom code would need to be able
to read the password data from the "Password Data" value from the User
Directory. Unfortunately for security reason, this one cannot be read
outside the Policy Server which needs the use of the Session Key (1).
To read it, you might be able to do so by using SDK custom code and
There's another way is to use the SMTRYNO cookie, but this one has
very limited scope (4).
Finally, when running Advanced Password Services (APS) on the Policy
Server, those login failure count can be read in an easier way, as APS
will write in clear in the LDAP User Attribute the login failure
Password policy data consideration when Upgrading Siteminder
- When configuring a Password policy for a User Directory, you need to
specify an attribute on the directory where Siteminder can store
their Password Data (PasswordBlob)
- The password data contains the user tracking details (last logon
,password changes ....) and is created as data Blob which is
encrypted by a session key
- This session key is stored within the key store along with the Agent
- The session key value is encrypted by the Policy server encryption
key by Default.
Problem to read the password data using SDK DMS API DmsApiSample.java
Using sdk\samples\javadmsapi\DmsApiSample.java) to get a user's
password state (SmDmsUserPWState).
Retrieval of information from user's Password Data from directory.xml
you can take advantage of the SM DMS API which has a
SmDmsUserPWState class which has methods available for accessing
and decrypting the PasswordData field.
Web Agent SMTRYNO cookie being reset on browser change
Note that smretries and SMTRYNO is like a counter browser-based,
which purpose is to limit the amount of authentication attempts that
can be done on the browser
Failure Count Retention
APS keeps track of the failure count for each user both in memory
and on disk (for ODBC and LDAP users)
Application Programming Interface (APSAPI)
APS includes three different Application Programming Interfaces (APIs).
A forward-facing API (APSAPI) allows applications to determine if a
given password conforms to the formatting rules defined for a
specific user, change a user password, or perform APSAdmin-like
functions using an XML-based interface. All APS utilities use this
API. This API is provided with both a C++ and a COM interface. Due
to the nature of the encrypted communications that are used by this
API, a native Java interface is not possible. However, a JNI
interface to the API can be built with minimal effort.
A rearward-facing API (SmAPSLog) that APS calls during processing
can be used to perform custom APS event logging. The published API
that is described in this document. A sample of this library is
provided in the source code.
A rearward-facing API (SmAPSEx) can be used by CA Professional
Services to customize APS behavior beyond the configurable
options. This API is restricted, for security reasons, to CA
Professional Services only.
Interfaces for Delegated Management Services (DMS2)
APS includes templates and interfaces for Delegated Management
Services (DMS) product line. Sites can create custom
self-registration, user self-service profile management, and
delegated user administration systems that communicate with APS to
enforce password policies, manage forgotten password options, and
control user account enabling/disabling.