[jira] [Updated] (OFBIZ-4983) New feature to reclaim a user account - Using Security Questions

["Harsha Chadhar (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-4983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harsha Chadhar updated OFBIZ-4983:
----------------------------------

    Attachment:     (was: OFBIZ-4983.patch)
    
> New feature to reclaim a user account - Using Security Questions
> ----------------------------------------------------------------
>
>                 Key: OFBIZ-4983
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-4983
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Harsha Chadhar
>            Assignee: Jacques Le Roux
>             Fix For: SVN trunk
>
>         Attachments: 1.png, 2.png, 3.png, 4.png, 5.png, OFBIZ-4983.patch, OFBIZ-4983.patch
>
>
> *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 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira