[
https://issues.apache.org/jira/browse/UNOMI-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francois Gerthoffert updated UNOMI-820:
---------------------------------------
Reporter: Romain Gauthier (was: Francois Gerthoffert)
> Management of non secured aliases
> ---------------------------------
>
> Key: UNOMI-820
> URL: https://issues.apache.org/jira/browse/UNOMI-820
> Project: Apache Unomi
> Issue Type: Improvement
> Reporter: Romain Gauthier
> Priority: Major
>
> h3. Context:
> With Unomi 2, aliases manage to simplify the merge logic and the data
> structure by removing the need to keep merged profiles. However, they cannot
> be used as they're described on the documentation website because of a
> security / design limitation: aliases ids need to be impossible to "guess"
> because if you guess the alias id, then you can access the related profile
> data.
> The goal of this ticket is to improve the current alias logic so that aliases
> values could actually be emails, logins, crm ids, etc.. so that developers
> using Unomi could easily retrieve in one API call any profile with a CRM id,
> email, etc..
> h3. Implementation
> h4. New "secure" field in aliases
> A new field should be added to the aliases object / index: "secure" (naming
> to be confirmed)
> For aliases ids that are secure, like java uuids used for profile ids:
> "secure" would be set to true
> For aliases ids that are not secure, such as emails, logins or CRM ids:
> "secure" would be set to false
> h3. Limitation / to be discussed:
> The system would assume that ids from different systems (email, login, crm
> id, ..) cannot be associated to different profiles:
> If the login of laurel is "abcd"
> If the CRM id of hardy is "abcd"
> Then unomi would consider these 2 profiles as the same
> One way to circumvent that limitation would be to add a new field "profile
> property" in the alias index.
> Aliases would look like:
> - Fields:
> alias id | profile id | profile property | secure
> - Document 1, storing 2 profile ids following a merge:
> 215b2708-7630-446b-8864-3d1c226106c3 | 36aa9313-7e17-4c43-ad24-9565f6ea272d |
> id | true
> - Document 2, storing a login alias, same profile as document 1:
> johnSmith | 36aa9313-7e17-4c43-ad24-9565f6ea272d | login | false
> h4. Merge logic
> Merge logic needs to be updated so that now, 2 aliases are created:
> - One to store the profile id of the merged profile, with secure set to true
> (already existing)
> - One to store the value of the mergeIdentifier property (email value or
> login value)
> h4. Update context.json / eventCollector implementation
> Public endpoints (context.json and eventcollector) implementation should be
> updated to only look up for aliases ids that are secure (or do not change the
> lookup logic but block/skip the process if the secure flag is false).
> h3. Tests scenarios
> Given a rule with mergeIdentifier based on login event and profile property
> "loginIdentifier" is running:
> - Create a first visit, get a profile id, called 1111
> - Update the profile to nbOfKids = 2
> - Send a login event associated to profileID, with johnSmith as
> loginIdentifier
> - Assert that one alias has been created: johnSmith, 1111, secure: false
> - Call the endpoint /cxs/profiles/johnSmith, assert that you get a profile
> with property nbOfKids = 2
> - Clear cookie / create a new visit
> - Set your profile id cookie to "johnSmith"
> - Read the profile properties values (using requiredProfileProperties [*]
> - Ensure that nbOfKids is empty
> - Clear cookie / create a new visit , get a profile id, called 1112
> - Send a login event with a loginIdentifier = johnSmith
> - Assert that one alias has been created: 1112, 1111, secure: true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
