Date: Fri, 29 Mar 2024 01:05:56 +0000 (UTC) Message-ID: <1896929515.7321.1711674356820@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7320_691433436.1711674356820" ------=_Part_7320_691433436.1711674356820 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The new USDU acronym in v2.5.x: Universal Subject Daemon Utility.&= nbsp; Yes we renamed it so we don't need to have people change their config= s.
In a Grouper v2.5 build, there is the USDU daemon that resolves subjects= (in batch) and does some tasks
In syncing data with target systems, the link to an entity might not be = the same sourceId/subjectId tuple that Grouper uses. Maybe an attribu= te or expression needs to be evaluated against the subject to link the enti= ties. This places an undo burden on these operations since resolving subjec= ts from an external system is expensive performance-wise. Further the= re are issues when subjects become unresolvable to clean up provisioned dat= a where the links are broken.
You might have a DN in an ldap provisioner that is based on a subject at= tribute. We want to keep a copy of that in the Grouper database so we= can efficiently do provisioning. If the attribute changes throughout= the day, there will be an error and the subject will be re-resolved as nee= ded.
If there is a config to cache this, then it will be cached by the new US= DU.
There are up to four values that can be cached for subjects in the group= er_sync_member table. Different provisioners will use these however t= hey want. It is intended that the "from" ID's will be Grouper or Subj= ect API things, and the "to" ID's will be for data in the provisioning targ= et (e.g. an attribute of the person in LDAP or a uuid from box).
grouper-loader.properties (note this will be configured on the UI in a w= izard). If the provisioner is enabled, and there is configuration in = member(From|To)Id(2|3), and the "auto" setting is not there or blank or tru= e, then do the update in the daemon.
if prov= isioner.<configName>.common.enabled is false, then skip provisioner.<configName>.common.subjectLink.memberFromId2 =3D ${subje= ct.whatever} provisioner.<configName>.common.subjectLink.autoMemberFromId2 =3D tru= e (blank defaults to true) provisioner.<configName>.common.subjectLink.memberFromId3 =3D ${subje= ct.whatever} provisioner.<configName>.common.subjectLink.autoMemberFromId3 =3D tru= e (blank defaults to true) provisioner.<configName>.common.subjectLink.memberToId2 =3D ${subject= .whatever} provisioner.<configName>.common.subjectLink.autoMemberToId2 =3D true = (blank defaults to true) provisioner.<configName>.common.subjectLink.memberToId3 =3D ${subject= .whatever} provisioner.<configName>.common.subjectLink.autoMemberToId3 =3D true = (blank defaults to true)
Lock on a provisioner
Get all sync members for a provis= ioner, change them, and persist back
GcGroup= erSync gcGrouperSync =3D GcGrouperSyncDao.retrieveOrCreateByProvisionerName= (null, <configName>); GcGrouperSyncJob gcGrouperSyncJob =3D gcGrouperSync().getGcGrouperSyncJobDa= o().jobRetrieveOrCreateBySyncType("usduSubjectCacheUpdater"); gcGrouperSyncJob.waitForRelatedJobsToFinishThenRun(true); try { // thread to update heartbeat this.setJobState(GcGrouperSyncJobState.running); this.setHeartbeat(new Timestamp(System.currentTimeMillis())); this.grouperSync.getGcGrouperSyncJobDao().internal_jobStore(this); List<GcGrouperSyncMember> gcGrouperSyncMembers =3D this.gcTableSync= .getGcGrouperSync().getGcGrouperSyncMemberDao().memberRetrieveAll(); ...make changes... # this will persist in batch only objects that have changed since being r= etrieved int objectsStored =3D gcTableSync.getGcGrouperSync().getGcGrouperSyncDao(= ).storeAllObjects(); } finally { GcGrouperSyncHeartbeat.endAndWaitForThread(this.gcGrouperSyncHeartbeat); gcGrouperSyncJob.assignHeartbeatAndEndJob(); }
See Also