New feature to reclaim a user account - Using Security Questions

[Vikas Mayur-3]

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

[David E Jones-3]

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

[Adrian Crum-2]

And this doesn't happen in eCommerce only. A back office user could run into the same problem.

-Adrian


--- On Fri, 5/8/09, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: New feature to reclaim a user account - Using Security Questions
> To: [hidden email]
> Date: Friday, May 8, 2009, 5:01 PM
> 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