This looks like a great enhancement and this write-up is well thought
out. Thanks for sharing it and soliciting feedback.
About the data model, I'd recommend leaving out the
PartySecurityQuestion entity. It introduces a dependency on the Party
entity which is in a higher level component, and it appears that the
UserLoginSecurityQuestion entity is adequate and since authentication
is a UserLogin thing (and not a Party thing) it is better and makes
more sense there anyway.
-David
On May 8, 2009, at 4:46 AM, Vikas Mayur wrote:
Hi,
I would like to propose a new feature to reclaim a user account.
Before I go into details on the data model, here is a quick outline
of the business story.
"When a customer create an account on eCommerce site, he will also
need to answer few security questions. We can enforce restriction on
the minimum number of questions that must be answered by a user
before creating his profile successfully, through some
configurations which are discussed in the next section. These
security questions then can be used to reclaim the customer account
in case he forget his password. User can also be given a choice to
add his own custom questions and this would be enable/disabled again
through some configurations.
If the user correctly answer minimum required questions while
reclaiming his account, password will be send through email
notifications. This part would work in the same way as the existing
functionality of email password (forget password)."
We would probably need the screens to configures
1) Security Question in the system.
These questions will be called as Standard security questions and
can only be entered by an admin (or a person with similar sort of
privileges). These questions will be available to every user who
create or update his profile.
2) Giving user an option to create his own custom security questions.
A configuration/property that would determine whether this option is
available to the user or not. These questions will be called as
Custom security questions and can entered only by a user while
creating or updating a profile. These questions will be available
and applicable only to the owner of the questions, i.e the user who
create these questions.
3) Minimum number of questions that are required to answer.
This configuration/property would determine minimum number of
questions that a user must answer while creating an account and as
well as reclaiming an account.
I think we can save above (#1, #2) configuration in database and
provide screens to configure them. IMO, these configuration can be
also called as a security configuration, since they are some how
related to security.
At this moment I have not much idea about where these sort of
configuration should be saved but this could be part of the entity
that saves the security configurations (which does not exist at this
moment). In recent days certain properties are moved to entities and
this could certainly be the done with security properties at certain
point of time, until then these configuration can be kept under
security properties file.
Custom Data Model:
The new entities that would be required for this feature are
following (Scott did help in improving the data model few months
back):
SecurityQuestion: Security Question in the system. These questions
can be standard (added by admin and are visible/available to every
new user while creating a new account) as well as custom questions
(added by a user). We can differentiate between the type of
questions using questionTypeEnumId (STANDARD or CUSTOM) as defined
in the data model below.
PartySecurityQuestion: All the questions that are related to a User.
They can be mix of both Standard as well as Custom.
UserLoginSecurityQuestion: An entity to capture the answer of the
security question and tying it to a UserLogin very much like a
UserLoginSecurityGroup. When a User reclaim his account, the
question answered by this user would be matched with the answer of
the questions (corresponding to that user) in this entity.
<entity entity-name="SecurityQuestion" package-
name="org.ofbiz.security.login">
<field name="questionId" type="id-ne"></field>
<field name="questionTypeEnumId" type="id-ne"></field>
<field name="question" type="very-long" ></field>
<prim-key field="questionId"/>
<relation rel-entity-name="Enumeration" type="one" fk-
name="SECQ_ENUM" title="QuestionType">
<key-map field-name="questionTypeEnumId" rel-field-
name="enumId"/>
</relation>
</entity>
<entity entity-name="PartySecurityQuestion" package-
name="org.ofbiz.security.login">
<field name="questionId" type="id-ne"></field>
<field name="partyId" type="id-ne"></field>
<prim-key field="questionId"/>
<prim-key field="partyId"/>
<relation rel-entity-name="SecurityQuestion" type="one" fk-
name="PTYSECQ_SECQ">
<key-map field-name="questionId"/>
</relation>
<relation type="one" rel-entity-name="Party" fk-
name="PTYSECQ_PTY">
<key-map field-name="partyId"/>
</relation>
</entity>
<entity entity-name="UserLoginSecurityQuestion" package-
name="org.ofbiz.security.login">
<field name="questionId" type="id-ne"></field>
<field name="userLoginId" type="id-vlong-ne"></field>
<field name="question" type="very-long"></field>
<field name="answer" type="short-varchar"></field>
<prim-key field="questionId"/>
<prim-key field="userLoginId"/>
<relation rel-entity-name="SecurityQuestion" type="one" fk-
name="ULGNSECQ_SECQ">
<key-map field-name="questionId"/>
</relation>
<relation rel-entity-name="UserLogin" type="one" fk-
name="ULGNSECQ_ULGN">
<key-map field-name="userLoginId"/>
</relation>
</entity>
</entitymodel>
Please send in your comments so that I can plan the implementation.
Thanks,
Vikas
