Task #384
closed
Archive user accounts on systems
100%
Description
Idm is authoritative source of data about identities to connected systems like LDAP, AD.
It is a common situation that when identity contract ends - the user lost its account in systems. The word lost have two meaning:
- account is deleted - standard IdM feature (e.g. removed from CN=FirstName LastName,OU=active,OU=users,DC=organisation,DC=cz)
- account is archived/moved - simply updated, definitely not deleted. In case of LDAP - the user is moved to separated tree (e.g. CN=FirstName LastName,OU=archived,OU=users,DC=organisation,DC=cz)
The aim of this ticket is to discuss and pick the best solution for the usecase above in 2.
Updated by Marcel Poul about 7 years ago
There are some restrictions that the solution should meet:
- account mapping is kept when the account is updated, so the CzechIdM is still the authority for account on system and provision data changes
- when the user is back to work (e.g. got a new contract), he must be updated not created again - maybe configurable?
on discussion - should he still have the role?
Updated by Marcel Poul about 7 years ago
- Description updated (diff)
One of the possible solutions:
Roles will have quarantine attribute. When the role is removed the user it is in new state (QUARANTINE) and is still practically assigned to the user. When the quarantine attribute is set to like 30000 days, it will be always assigne.
In this solution - the mechanism of assigning automatic roles in HR processes must change the state of the role and identity, when the role is assigned again. More over it should be skipped when automatic role is removed from the user when in state QUARANTINE.
To change the DN in LDAP as in the usecase above, the role just have the attribute mapping for distinguished name by Script (simple script - is role in quarantine -> give DN A, otherwise compute DN B)
Updated by Marcel Poul about 7 years ago
The same principle as role quarantine may be applied on Resources
One should specify the QUARANTINE on resource e.g. LDAP. The information about the users account state (in quarantine true/false) should be passed to the attribute mapping scripts like one for filling DistinguishedName. Based on it, the script computes DN and user is moved in LDAP.
I personally prefere Role quarantine, since it is more general. Role can represent more than account posession.
Updated by Radek Tomiška almost 7 years ago
- Assignee changed from Radek Tomiška to Vít Švanda
Updated by Marcel Poul almost 7 years ago
Marcel Poul wrote:
The same principle as role quarantine may be applied on Resources
One should specify the QUARANTINE on resource e.g. LDAP. The information about the users account state (in quarantine true/false) should be passed to the attribute mapping scripts like one for filling DistinguishedName. Based on it, the script computes DN and user is moved in LDAP.
This is the prefered and generally agreed on solution.
Updated by Vít Švanda almost 7 years ago
Description of the task (summary):
- On SystemMapping will be added fields:
- protectionEnabled (boolean)
- protectionInterval (int > 0) - count of days before delete account (IdentityAccount exactly)
- On AccAccount will be added fields:
- isInProtection (boolean)
- endOfProtection (timestamp)
- Basic use case:
- We have identity with two assigned roles. Both roles assignes same Account, but roleOne overrides account attribute One and roleTwo overrides account attribute Two. We have system mapping with set protection interval sets on 7 days.
- Process role request removes roleOne from the identity.
- IdentityRole entity for roleOne will be deleted.
- Call account management for identity.
- System mapping with enabled protection interval will be found -> protection will be not activated, because we have some other IdentityAccoutn (created by assigned roleTwo).
- IdentityAccount will be deleted.
- Do provisioning for identity and this account.
- System mapping does not have any information about protection (because one IdentityAccount relation lefts).
- Process role request removes roleTwo from the identity.
- IdentityRole entity for roleTwo will be deleted.
- Call account management for identity.
- System mapping with enabled protection interval will be found -> IdentityAccount will be not deleted, but set fields on AccAccount "isInProtection" on true and "endOfProtection" (TimeStamp counted by protection interval). IdentityAccount will still have relation on RoleSystem.
- Do provisioning for identity and this account. This provisioning must be realize as internal call provisioinig (or event). We need skip provisioinig break for protected accounts.
- System mapping does have information about account protection (in transformation to system).
- Breaking provisioning for protected accounts:
- Start of provisioning will be reimplemented as event.
- Provisioning will be newly started in processor. This processor will be do check on protected Account and will not do provisioning for them.
- This provisioning stop will works for all provisioning calls in application.
- Processor will be implemented bypass of this stop functionality (needs for first provisioning)
- "Retry" mechanism:
- roleOne or roleTwo will be again assigned to identity.
- Account management evaluated same uid as have protected Account.
- We use existed relation IdentityAccount and set RoleSystem for new added IdentityRole.
- Accounts field "isInProtection" set on false and "endOfProtection" to null.
- Do standard provisioning.
- Delete account:
- Scheduled task will be every day check protected Accounts with expired protection.
- Task delete this accounts.
- Delete of AccAccount trigger delete provisioning (delete account on target system).
Updated by Marcel Poul almost 7 years ago
Today we discussed what will happen with synchronization of the account from system to IdM, if the system is in protected state. I guess the situation should be the same as provisioning.
Just thinking that the provisioning/not provisioning during protection state may be configurable?
Updated by Vít Švanda almost 7 years ago
- Category set to Provisioning
- Status changed from New to In Progress
- Target version set to Citrine (7.3.0)
- % Done changed from 0 to 30
- Implemented events and processors for IdentityAccount delete.
- DB attributes
- ...
Updated by Vít Švanda almost 7 years ago
- % Done changed from 30 to 50
- Definition for protection on system mapping.
- Activation of protection for account, when last identity-account is deleted.
- Deactivation of protection, when next identity-account is created.
- Provisioning skip for protected account.
- Account management use DTO IdentityAccount service now (not repository)
Updated by Vít Švanda almost 7 years ago
- % Done changed from 50 to 60
- Implemented propagate information about protection of account to attribut transformation (to system).
- Transformation have access to instance of system (as variable).
- I do not propaget protection account information directly, but I created script returnes this information.
- Fixed many problems...
Updated by Vít Švanda almost 7 years ago
- % Done changed from 60 to 70
- Prepared for testing
- I created template for script (only draft without import) "isAccountInProtection". Template is here: https://github.com/bcvsolutions/CzechIdMng/blob/develop/Realization/backend/acc/src/main/resources/eu/bcvsolutions/idm/scripts/IdmAccIsAccountInProtection.xml.
- Settings for protection is on system mapping detail (only for provisioning and identity).
- My example for "email" attribute is here:
// Inserted script: isAccountInProtection /* Description: <p>Return 'true', if account for given UID and system ID is in protection state. Else return 'false'.</p> */ def isProtected = scriptEvaluator.evaluate( scriptEvaluator.newBuilder() .setScriptCode('isAccountInProtection') .addParameter('scriptEvaluator', scriptEvaluator) .addParameter('uid', uid) .addParameter('attributeValue', attributeValue) .addParameter('entity', entity) .addParameter('system', system) .build()); if(isProtected){ return 'archive.'+attributeValue; }else{ return attributeValue; }
- Limitations:
- Task for periodic delete accounts with expired protection is not created yet.
- Re-pairing mechanizm after UID attribute is changed (return different value for protection and unprotection mode) is not implemented.
- Tests are not created yet.
- Documentation is not created yet.
Updated by Marcel Poul almost 7 years ago
Quick scan - FE does not have Eng localization.
Updated by Marcel Poul almost 7 years ago
I quickly tested the feature at our project - only basic scenario.
Add LDAP role - Create provisioned
remove LDAP role - Update provisioned
updated identity - no provisioning
Add LDAP role - Update provisioned with attributes values from previous step.
Thx.
Updated by Vít Švanda almost 7 years ago
Eng localization was fixed and help block for protection (enabled) was added.
Updated by Vít Švanda almost 7 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Vít Švanda to Ondřej Kopr
- % Done changed from 80 to 90
Documentation created here: https://proj.bcvsolutions.eu/ngidm/doku.php?id=navrh:account_protection_system
Updated by Ondřej Kopr almost 7 years ago
- Status changed from Needs feedback to Resolved
- Assignee changed from Ondřej Kopr to Vít Švanda
- % Done changed from 90 to 100
Check archive user accounts on system on develop, everything works accounts still exists. Thank you for that. Your documentation is awesome!
Updated by Vít Švanda almost 7 years ago
- Status changed from Resolved to Closed