Project

General

Profile

Actions

Defect #1852

closed

Synchronization with Do_not_link linked an account to an inactive identity, LINK_PROTECTED linked it without protection

Added by Alena Peterová over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Vít Švanda
Category:
Synchronization
Target version:
Start date:
09/13/2019
Due date:
% Done:

100%

Estimated time:
Affected versions:
Owner:

Description

Version 9.7.6
The synchronization was started with the default role and specific settings DO_NOT_LINK for inactive identities.
But the account was linked (without role assignment) to the identity which doesn't have any contract yet.

Log:

2019-09-13T15:40:05.809+02:00: Account was not found. We try to find account for UID (xxxxxxxx) (generated from the mapped attribute marked as Identifier)
-------------------------
2019-09-13T15:40:05.809+02:00: SystemEntity for this uid doesn't exist. We will create it.
-------------------------
2019-09-13T15:40:05.813+02:00: Account doesn't exist in IdM
-------------------------
2019-09-13T15:40:05.815+02:00: Account does not exist, but an entity [2c3d0364-e7bf-4017-a43e-f2b8a00805fa] was found by correlation (entity unlinked).
-------------------------
2019-09-13T15:40:05.815+02:00: Unlinked action is LINK_AND_UPDATE_ENTITY
-------------------------
2019-09-13T15:40:05.827+02:00: Entity with id 2c3d0364-e7bf-4017-a43e-f2b8a00805fa was updated
-------------------------
2019-09-13T15:40:05.832+02:00: Account with uid xxxxxxxx and id 1d867f23-2aa2-403c-97a0-4886f3aa6f4f was created
-------------------------
2019-09-13T15:40:05.832+02:00: Default role [AMIS*H-users] is defined and will be assigned to the identity [xxxxxxxx].
-------------------------
2019-09-13T15:40:05.833+02:00: Warning! - Default role is set, but could not be assigned to identity, because the identity has not any suitable contract!
-------------------------
2019-09-13T15:40:05.833+02:00: Operation count for [LINK_AND_UPDATE_ENTITY] is [1]
-------------------------
2019-09-13T15:40:05.839+02:00: Entity account relation  with id (d596be1c-a1a8-4134-912b-14d17151860c), between account (xxxxxxxx) and entity (xxxxxxxx) was created
-------------------------
2019-09-13T15:40:05.839+02:00: Call provisioning (process IdentityEventType.SAVE) for identity (2c3d0364-e7bf-4017-a43e-f2b8a00805fa) with username (xxxxxxxx).


Files

sync_do_not_link.png (52.4 KB) sync_do_not_link.png Alena Peterová, 09/13/2019 04:37 PM
1852.png (36.8 KB) 1852.png Vít Švanda, 09/16/2019 02:02 PM
identity_contract_created.png (82 KB) identity_contract_created.png Alena Peterová, 09/16/2019 03:16 PM

Related issues

Related to IdStory Identity Manager - Defect #1549: Multiple accounts on system after sychronizationClosedVít Švanda03/12/2019

Actions
Actions #1

Updated by Vít Švanda over 4 years ago

  • File 1852.png 1852.png added
  • Status changed from New to Needs feedback
  • Assignee changed from Vít Švanda to Alena Peterová
  • Target version set to Rhyolite (9.7.7)

I was not able simluate this on current version. I configured (I think) same use case and my account was not created. Can't there be a problem in specific modifications on the project?

There is my configuration of sync (it was a good idea to print these metadata (they are useful), thanks for that ;)):

Synchronization was started in 2019-09-16T12:33:44.428.
-------------------------
Specific settings:
Default role: userRole
Assign default role to all valid or future contracts: false
Behavior of the default role for inactive identities: DO_NOT_LINK
Create default contract: false
After end, start the automatic role recalculation: false
-------------------------
Synchronization will use custom filter (not synchronization implemented in connector).
-------------------------
Start search with filter NONE.
-------------------------
Synchronization was correctly ended in 2019-09-16T12:38:58.551.
-------------------------
Start of the automatic role recalculation (after sync) is not allowed

Log of my item. There is strange, you doesn't have in the log 'Update of entity for account with uid *** is skipped'.

2019-09-16T12:33:49.045+02:00: Account was not found. We try to find account for UID (User_1852) (generated from the mapped attribute marked as Identifier)
-------------------------
2019-09-16T12:33:49.048+02:00: SystemEntity for this uid doesn't exist. We will create it.
-------------------------
2019-09-16T12:33:49.098+02:00: Account doesn't exist in IdM
-------------------------
2019-09-16T12:33:49.114+02:00: Account does not exist, but an entity [0e14f532-402c-456d-b123-b9ba3af913c1] was found by correlation (entity unlinked).
-------------------------
2019-09-16T12:33:49.114+02:00: Unlinked action is LINK_AND_UPDATE_ENTITY
-------------------------
2019-09-16T12:34:41.346+02:00: Update of entity for account with uid User_1852 is skipped
-------------------------
2019-09-16T12:35:35.553+02:00: Identity [User_1852] does not have any valid contract, account with uid [User_1852] will not be linked.
-------------------------
2019-09-16T12:35:39.623+02:00: Operation count for [UNLINKED] is [1]
-------------------------
2019-09-16T12:35:39.623+02:00: Link between uid User_1852 and entity User_1852 will not be created due to specific settings of synchronization. Processing of this item is finished.

Actions #2

Updated by Alena Peterová over 4 years ago

  • Assignee changed from Alena Peterová to Vít Švanda

Thanks for checking, that's a good message.
The interesting thing is that our identity didn't have any contract, but it had already some contract slices. Unluckily, the slices weren't recalculated. (You can see it from the attached screenshot - the contract was created on 14.9. when ClearDirtyLRT run, but it was after this synchronization which linked the account).

And it's true that we have overriden method getPrimeValidContract. But our version first checks if there are some valid contracts, only after that it runs our algorithm. So I don't see the reason why it "found" some contract...

    @Override 
    @Transactional(readOnly = true)
    public IdmIdentityContractDto getPrimeValidContract(UUID identityId) {
        Assert.notNull(identityId);
        //
        // find valid all identity working position
        List<IdmIdentityContractDto> contracts = super.findAllValidForDate(identityId, LocalDate.now(), null);
        if (contracts.isEmpty()) {
            return null;
        }
        return getPrimaryValidContract(contracts, identityId);
    }

Actions #3

Updated by Alena Peterová over 4 years ago

Actions #5

Updated by Alena Peterová over 4 years ago

I tried it locally in our project with debug and the problem is probably in the property prime-valid-contract in context properties. This property "remembers" the contract of the last successfully processed Unlinked account, so when IdentitySynchronizationExecutor.getPrimeValidContract is called, it returns wrong contract.
I tried it for an identity with no contracts and no slices.

Actions #6

Updated by Alena Peterová over 4 years ago

  • Subject changed from Synchronization with Do_not_link linked an account to an inactive identity to Synchronization with Do_not_link linked an account to an inactive identity, LINK_PROTECTED linked it without protection

Also, synchronization with LINK_PROTECTED linked the account without setting it in protection. Moreover, the result in the synchronization log is Success, not Warning.

2019-09-10T09:35:25.409+02:00: System entity (eafe4860-03d5-481e-9ed3-35797f2a8c37) for this UID (xxxxxxxx) was found. We try to find account for this system entity
-------------------------
2019-09-10T09:35:25.411+02:00: Account was not found. We try to find account for UID (xxxxxxxx) (generated from the mapped attribute marked as Identifier)
-------------------------
2019-09-10T09:35:25.411+02:00: Account doesn't exist in IdM
-------------------------
2019-09-10T09:35:25.414+02:00: Account does not exist, but an entity [091b2b5b-b38b-4803-951d-cc7f3da199db] was found by correlation (entity unlinked).
-------------------------
2019-09-10T09:35:25.414+02:00: Unlinked action is LINK_AND_UPDATE_ENTITY
-------------------------
2019-09-10T09:35:25.433+02:00: Entity with id 091b2b5b-b38b-4803-951d-cc7f3da199db was updated
-------------------------
2019-09-10T09:35:25.437+02:00: Account with uid xxxxxxxx and id c70f5a1b-7c81-4cfa-927f-22c4efcfa598 was created
-------------------------
2019-09-10T09:35:25.437+02:00: Default role [AD_ucet] is defined and will be assigned to the identity [xxxxxxxx].
-------------------------
2019-09-10T09:35:25.439+02:00: Default role will be assigned to all valid or future valid contracts [number of found contracts 0].
-------------------------
2019-09-10T09:35:25.439+02:00: Default role is set, but it will not be assigned - no contract was found for identity [xxxxxxxx], so the account will be in protection.
-------------------------
2019-09-10T09:35:25.459+02:00: Entity account relation  with id (14c341de-512c-4cf4-90d2-7ef484abbba3), between account (xxxxxxxx) and entity (xxxxxxxx) was created
-------------------------
2019-09-10T09:35:25.459+02:00: Call provisioning (process IdentityEventType.SAVE) for identity (091b2b5b-b38b-4803-951d-cc7f3da199db) with username (xxxxxxxx).
-------------------------
2019-09-10T09:35:25.481+02:00: Operation count for [LINK_AND_UPDATE_ENTITY] is [13]
Actions #7

Updated by Vít Švanda over 4 years ago

  • Assignee changed from Vít Švanda to Radek Tomiška
  • % Done changed from 0 to 90

Problem was in the method "IdentitySynchronizationExecutor.getPrimeValidContract" (thanks @apeterova for debugging), where is using cache for primary contract. Bug was in this cache, because I do not cleared that cache for next sync item.

Fix and tests for DO_NOT_LINKE and LINK_PROTECTED are here:

https://github.com/bcvsolutions/CzechIdMng/commit/8e13d662dbd23566fd6c11a1d5c975eea341803a

Bug was made within #1549.

Actions #8

Updated by Radek Tomiška over 4 years ago

  • Related to Defect #1549: Multiple accounts on system after sychronization added
Actions #9

Updated by Radek Tomiška over 4 years ago

  • Status changed from Needs feedback to Resolved
  • Assignee changed from Radek Tomiška to Vít Švanda
  • % Done changed from 90 to 100

I did test (hard to reproduce) and code review, it works and code looks nice, thx!

Actions #10

Updated by Radek Tomiška over 4 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF