You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Harsha Chadhar (JIRA)" <ji...@apache.org> on 2012/08/07 14:47:07 UTC
[jira] [Commented] (OFBIZ-4983) New feature to reclaim a user
account - Using Security Questions
[ https://issues.apache.org/jira/browse/OFBIZ-4983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13430321#comment-13430321 ]
Harsha Chadhar commented on OFBIZ-4983:
---------------------------------------
The modifications in above proposal incorporating David's comment are :
# Doesn't require PartySecurityQuestion entity.
# The "question" field is not required in entity SecurityQuestion, the field description in entity Enumeration will work in place of it. The Questions will be defined in Enumeration and will have its reference in SecurityQuestion.
# The UserLoginSecurityQuestion entity also not requires question field, the reference question Id in entity SecurityQuestion will suffice.
# The field name questionTypeEnumId in SecurityQuestion should be renamed as questionEnumId. Also the foreign key reference title will be changed to Question instead of QuestionType.
# The Type Data will be as follows :
{code:title=Type Data|borderStyle=solid}
<EnumerationType enumTypeId="SECURITY_QUESTION" description="Security Question" lastUpdatedStamp="2012-08-07 15:51:53.197" lastUpdatedTxStamp="2012-08-07 15:51:53.197" createdStamp="2012-08-07 15:51:53.197" createdTxStamp="2012-08-07 15:51:53.197"/>
<EnumerationType enumTypeId="SQ_CUSTOM" parentTypeId="SECURITY_QUESTION" description="Custom Security Question" lastUpdatedStamp="2012-08-07 16:07:34.052" lastUpdatedTxStamp="2012-08-07 16:07:34.052" createdStamp="2012-08-07 16:07:34.052" createdTxStamp="2012-08-07 16:07:34.052"/>
<EnumerationType enumTypeId="SQ_STANDARD" parentTypeId="SECURITY_QUESTION" description="Standard Security Question" lastUpdatedStamp="2012-08-07 16:07:01.323" lastUpdatedTxStamp="2012-08-07 16:07:01.323" createdStamp="2012-08-07 16:07:01.323" createdTxStamp="2012-08-07 16:07:01.323"/>
<Enumeration enumId="SQ_STD_NCKNM" enumTypeId="SQ_STANDARD" enumCode="" sequenceId="0" description="What is your nick name" lastUpdatedStamp="2011-09-11 17:47:41.348" lastUpdatedTxStamp="2011-09-11 17:47:41.26" createdStamp="2011-09-11 17:47:41.348" createdTxStamp="2011-09-11 17:47:41.26"/>
<Enumeration enumId="SQ_STD_MOTNM" enumTypeId="SQ_STANDARD" enumCode="" sequenceId="1" description="What is your mother's maiden name" lastUpdatedStamp="2011-09-11 17:47:41.348" lastUpdatedTxStamp="2011-09-11 17:47:41.26" createdStamp="2011-09-11 17:47:41.348" createdTxStamp="2011-09-11 17:47:41.26"/>
<Enumeration enumId="SQ_STD_FAVTCH" enumTypeId="SQ_STANDARD" enumCode="" sequenceId="2" description="What is your favorite teacher's name" lastUpdatedStamp="2011-09-11 17:47:41.348" lastUpdatedTxStamp="2011-09-11 17:47:41.26" createdStamp="2011-09-11 17:47:41.348" createdTxStamp="2011-09-11 17:47:41.26"/>
<Enumeration enumId="SQ_STD_BSTFRND" enumTypeId="SQ_STANDARD" enumCode="" sequenceId="3" description="Who is your best childhood friend" lastUpdatedStamp="2011-09-11 17:47:41.348" lastUpdatedTxStamp="2011-09-11 17:47:41.26" createdStamp="2011-09-11 17:47:41.348" createdTxStamp="2011-09-11 17:47:41.26"/>
{code}
*Please provide suggestions so that I can provide the implementation as per the best approach.*
> 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
> Fix For: SVN trunk
>
>
> *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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira