Details
Description
Referring to Vikas's proposed model on Reclaiming User Account using security questions as follows :
"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>
As per David's Comments :
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
Attachments
Attachments
Issue Links
- breaks
-
OFBIZ-9966 Secure the login.secret_key_string
-
- Closed
-
- is part of
-
OFBIZ-1525 Issue to group security concerns
-
- Open
-
- relates to
-
-
- Closed
-