On 12/11/2012 11:24, ernst Developer wrote:
> Hi Francesco,
> With the AD resource, I want to *sync* all attributes, but only
> propagate a limited set back. How can I achieve that kind of behavior?
Ah ok, now I understand why you have two separate resources!
Then, in order to avoid unwanted updates to "AD update" when syncing
from "AD Sync", you will have to extend the SyncJob [1] and change line
354 from
List<PropagationTask> tasks =
propagationManager.getCreateTaskIds(created, userTO.getPassword(), userTO
.getVirtualAttributes(),
Collections.singleton(((SyncTask) this.task).getResource().getName()));
to something like:
Set<String> resNotToPropagate = new HashSet<String>();
resNotToPropagate.add(((SyncTask)
this.task).getResource().getName());
resNotToPropagate.add("AD update");
List<PropagationTask> tasks =
propagationManager.getCreateTaskIds(created, userTO.getPassword(), userTO
.getVirtualAttributes(), resNotToPropagate);
so that during synchronization, no propagation will occur either towards
the synchronizing resource ("AD Sync" in your example) and "AD Update".
Hope this helps.
Regards.
[1]
https://svn.apache.org/repos/asf/incubator/syncope/branches/1_0_X/core/src/main/java/org/apache/syncope/core/scheduling/SyncJob.java
> 2012/11/12 Francesco Chicchiriccò <[email protected]
> <mailto:[email protected]>>
>
> On 12/11/2012 10:03, ernst Developer wrote:
>> Thanks for the reply Francesco.
>>
>> I have drawn a little diagram. Please find this diagram attached.
>>
>> We have a setup like drawn in the diagram:
>> - An AD instance, which is the source of the identities;
>> - An AD Sync resource for syncing the identities to Syncope;
>> - A Syncope instance;
>> - An AD Update resource for executing the updates to AD. We want
>> to use a separate AD Update resource, to be able to control what
>> (limited set of) fields in AD the resource can modify. This
>> resource is also responsible for the password provisioning to AD;
>> - An external service that performs updates in Syncope using the
>> rest interface;
>>
>> A typical flow when a new identity is created in AD is:
>> 1. the user is picked up by the sync enabled AD resource;
>> 2. the user is created in Syncope;
>> 3. the external service performs an update on the same user in
>> Syncope;
>> 4. the update is picked up by the AD Update resource *only*;
>> 5. and an update is performed in AD by the AD Update resource;
>>
>> A few questions remain:
>> 1. Is the update picked up by the AD Update resource only, if we
>> set the correct capabilities on the resource?
>
> Capabilities are set on connectors, not resources.
> Definitely: if you don't give the needed capability, no action is
> performed on the underlying connector.
>
>
>> 2. When the external service performs an update in Syncope, will
>> Syncope propagate this update using the AD Sync resource only
>> when we configure the correct capabilities on the resource?
>
> Again. capabilities are set on connectors, not resources. If the
> two AD resources share the same connectors, this is not possible.
>
>
>> 3. In the user template the AD Update resource is connected to
>> every user. How can we prevent an update performed by the AD Sync
>> connector to be propagated to the AD Update resource?
>
> For this purpose, you'd need to not assign the AD Update resource
> in the user template, but I guess that this is not what you want.
> Actually, I don't understand why are you defining two separate AD
> resources: why not have a single AD resource for either
> synchronization and propagation?
>
> With a single AD resource, having a connector with all
> capabilities set, you can just synchronize, assign the resource
> via user template and be safe that any synchronization won't
> generate updates back to AD, while updates from the external
> service will do that.
>
> Regards.
>
>
>>
>> 2012/11/12 Francesco Chicchiriccò <[email protected]
>> <mailto:[email protected]>>
>>
>> On 11/11/2012 21:21, ernst Developer wrote:
>> > Hi,
>> >
>> > I was wondering about the behavior of a setup in Syncope with 1
>> > connector having 2 resources (SYNCResource and UPDATEResource).
>> >
>> > SYNCResource : this resources is meant for handling the
>> synchronization.
>> > UPDATEResource: this resource is meant for updating. Only a
>> limited
>> > set of schema fields (subset of the configured mappings in the
>> > SYNCResource) is configured.
>> >
>> > When updating the user in Syncope, the propagation should
>> only execute
>> > on the UPDATEResource, not on the SYNCResource. Is this
>> possible by
>> > configuration in Syncope?
>>
>> Sure: by default SYNCed users are not assigned any role or
>> resource:
>> this means that by default no propagation occurs at all after
>> synchronization.
>>
>> You can, however, modify this behavior by editing the user
>> template
>> associated with the synchronization task you are running: in
>> this way
>> you can associate any role and/or resource (and customize any
>> attribute,
>> BTW).
>>
>> > What happens with the update in the corresponding connected
>> system?
>> > For the SYNCResource this is an update in its connector,
>> and the sync
>> > results in another update (the same) of the Syncope user,
>> including
>> > all the corresponding propagations. One of them is of
>> course the
>> > propagation by the UPDATEResource, and the party starts all
>> over again.
>>
>> In order to prevent circular endless updates, the immediate
>> propagation
>> on the same syncing resource is disabled: this means that
>> when you are
>> synchronizing from Active Directory and assigning a DB
>> resource and the
>> same Active Directory resource to synchronized users (via user
>> template), the actual propagation will only happen towards
>> the DB resource.
>>
>> > Is what I describe above the actual behavior, or am I
>> missing something?
>>
>> I hope this clarifies a bit.
>>
>> Regards.
>>
--
Francesco Chicchiriccò
ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
