[CORE-3421] Multi-Factor ID Sync implementation

[alexandr-simprints]

JIRA ticket
Will be released in: 2025.3.0

Notable changes

• This PR prepares the fundamentals in order to start supporting the Multi-Factor ID feature. No events are added yet, as they will be created in the following parts of the Multi-Factor ID implementations.
• External Credential model is added to the domain and data layers
• An External Credential can now be linked to a Subject
• CRUD operations for external credentials are implemented

Testing guidance

• Describe how the reviewers can verify that issue is fixed

Additional work checklist

• Effect on other features and security has been considered
• Design document marked as "In development" (if applicable)
• External (Gitbook) and internal (Confluence) Documentation is up to date (or ticket created)
• Test cases in Testiny are up to date (or ticket created)
• Other teams notified about the changes (if applicable)

[BurningAXE]

Have we abandoned the idea for many-to-many relationship between subjects and external credentials?
Also, do both subject and external credentials need pointers to each other? If they are in a parent-child relationship, usually only the parent needs a pointer to its children.

[alexandr-simprints]

This is done the same way as it is implemented in Subject and FingerprintSample/FaceSample - the subject has list of samples, and the samples have referenceId pointing to the subject.

It's important to remember that these are the domain-level models that are used for our convenience, and sometimes we require the external credentials of a subject, and sometimes - a subject id from the external credential. Pointing to each other shouldn't bring any technical overhead or confusion, as such approach has already been implemented in different models

[BurningAXE]

Sure, if it's needed, doesn't hurt.
What about the many-to-many relationship?

[alexandr-simprints]

It is already implemented. A subject can have multiple external credentials, an external credential can refer any subject. I.e.

Subject 1
- Credentials: ['ABC', 'DCE']

Subject 2
- Credentials: ['ABC']

Credential 1
- Name: 'ABC'
- Subject ref: 'Subject 1'

Credential 2
- Name: 'ABC'
- Subject ref: 'Subject 2'

Credential 3
- Name: 'DCE'
- Subject ref: 'Subject 1'

[luhmirin-s]

That is not a "many-to-many" relationship? 😕 In your example, you are mixing up values and IDs; it should have been something like:

Subject 1
- Credentials: ['Credential 1', 'Credential 3']

Subject 2
- Credentials: ['Credential 2']

Credential 1
- Name: 'ABC'
- Subject ref: 'Subject 1'

Credential 2
- Name: 'ABC'
- Subject ref: 'Subject 2'

Credential 3
- Name: 'DCE'
- Subject ref: 'Subject 1'

Which is actually one-to-many. Unless the name is part of the ID, but then it should not be possible to have separate "Credential 1" and "Credential 2".

Nothing wrong with the approach, we just need to be on the same page about the terminology.

[BurningAXE]

OK, I see. The confusion comes from the discrepancy between the semantic meaning of "a credential" ('ABC') and what the ExternalCredential model represents ('ABC'+subjectId).

[BurningAXE]

In general looks good but we must decide on the relationship between subjects and external credentials because it will be much harder to change later.

[sonarqubecloud]

Quality Gate passed

Issues
7 New issues
0 Accepted issues

Measures
0 Security Hotspots
83.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud