The section above describes the attributes that "belong" to APS; that is, the fields that APS needs and maintains for its own purposes or for auditing purposes.
The Forgotten Password Services (FPS) component of APS allows users to change (or recover) their password without knowing their old password. This is done by requiring the user to enter information, usually the answers to a series of questions, and matching that information with data stored in the user record.
Unlike the above attributes, the information used in the FPS process does not "belong" to APS and is not maintained by it. The FPS process merely uses this information in the way that it is configured to do so. APS/FPS does not care what this information is, it merely needs to know the attribute names and the format (in some cases) in which it is stored.
There are three FPS-related attributes described in the previous section. Those attributes are used for control purposes and are not end-user visible, nor are they typically modified by a site outside of the FPS process. This section talks about the fields/attributes that are used by the FPS process to interact with the user.
This information is defined and maintained by whatever user management tools used by the site. APS/FPS generally does not do anything with this data except to match it up against user input (with the possible exception of certain control information used internally by APS, described later).
Most of the FPS configuration process involves the mapping of input fields (from the input forms) to the user attributes and describes how the comparison is performed. For example, the configuration might indicate that an input field called "FirstName" is compared, case-insentively, to a attribute called "givenname". This comparison is generally performed during the "Identify" phase of the FPS process in order to figure out who the user is.
The second (optional, but commonly used) phase of the FPS process involves verification; the attempt by the user to prove that they are who they say they are. This is typically done by presenting the user with one or more questions, gathering the user's answers, then comparing those answers with the ones stored in the user record.
APS does not provide any mechanism for storing these questions in the user record, for updating it, or even for displaying it. This should all be part of the User Management Application. While APS does not require specific names for such attributes, it does need to understand how that information is stored so that it can perform its operations correctly.
The most trivial example involves a single question and answer. In these cases, two attributes can be used: a Question and an Answer. These attributes can be called anything the site wants to call them and are expected to contain character data. FPS is configured to pass whatever is in the Question attribute (the name of the attribute is identified in the APS.cfg file) to the Verify form and the posted data is compared to the data stored in the Answer attribute (also named in the APS.cfg file).
There is actually an even simpler case, where the question is fixed for the entire site, so only an answer is needed. This configuration is generally not recommended, since it is trivial to socially engineer an answer to break into the user account.
Most sites prefer to use the more complex case where a number of questions and their answers are stored in the user record, allowing FPS to select a subset of those questions for display. This is a much more complicated case.
The issue is not one of where the information is stored in the user record, it is an issue of how the information is formatted within the user record.
With multiple questions and answers, the answers must be tightly coupled with the question that they belong to; the two must be stored together, rather than in separate attributes (especially on LDAP directories, where the order in which multi-valued attributes are returned is not guaranteed).
Thus, FPS expects such data to contain a question and answer, stored together, separated by a "pipe" or "vertical bar" character ("|").
FPS will also select a subset of multiple questions. Because of this, FPS needs to "remember" which questions have already been asked and when they were asked. This information is updated by FPS and is associated with each question/answer pair by placing it in front of the question/answer pair and separating it with another pipe character.
Thus, a single question/answer should be stored in the form:
<control data>|<question>|<answer>
FPS does not care about the format of the question. Whatever is stored between tne two pipes will be passed to the verify page. That page can do whatever translations that it must in order to display the correct user question (challenge). Typically, this is not the actual text of the question (this is discussed in great detail elsewhere in this document). Usually, it is a code (in FPS parlance, a Question ID, or QID) that the Verify page uses to lookup the actual text of the question. This method accomplishes several things:
The control data portion of the data should be left blank at initialization (in other words, the entire field should just start with the pipe). FPS will write a date/time or the word DELETED into this area, depending on how it is configured.The answer is the text that FPS will match against the user input. This information is generally not encrypted, but can be, either using SmAPSEx or, in the case of ODBC directories, using stored procedures. The issue here is that the User Management Tool must be able to encrypt the information when it is stored in the user record, so both the User Management Tool and FPS must agree on the encryption scheme.
If the word DELETED appears, then this question has been asked and FPS is configured to consume questions. In these cases, FPS will never ask the question again. User Management Tools should keep such information in the user record and not allow the user to re-select the same question, because it has already been used. The question should remain in the user record to prevent the question from ever being selected again by the user.
If a date appears in the control field, it is important that the User Management Tool maintain this value, otherwise questions may not be selected correctly in the future.
The above discusses how each question/answer pair is stored in the user record. There is also an issue of how all of the question/answer pairs are stored together. FPS recognizes two different methods.
The name of the attribute used and the storage format is defined in the APS.cfg.
|
Copyright © 2014 CA.
All rights reserved.
|
|