You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by ernst Developer <er...@gmail.com> on 2012/11/11 21:21:23 UTC
Sync enabled resource combined with update enabled resource
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?
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.
Is what I describe above the actual behavior, or am I missing something?
Regards,
Ernst
Re: Sync enabled resource combined with update enabled resource
Posted by ernst Developer <er...@gmail.com>.
Ok, thats clear. Thanks a lot.
2012/11/12 Francesco Chicchiriccò <il...@apache.org>
> 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ò <il...@apache.org>
>
>> 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ò <il...@apache.org>
>>
>>> 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 Memberhttp://people.apache.org/~ilgrosso/
>
>
Re: Sync enabled resource combined with update enabled resource
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò <ilgrosso@apache.org
> <ma...@apache.org>>
>
> 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ò <ilgrosso@apache.org
>> <ma...@apache.org>>
>>
>> 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/
Re: Sync enabled resource combined with update enabled resource
Posted by ernst Developer <er...@gmail.com>.
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?
Regards,
Ernst
2012/11/12 Francesco Chicchiriccò <il...@apache.org>
> 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ò <il...@apache.org>
>
>> 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 Memberhttp://people.apache.org/~ilgrosso/
>
>
Re: Sync enabled resource combined with update enabled resource
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò <ilgrosso@apache.org
> <ma...@apache.org>>
>
> 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/
Re: Sync enabled resource combined with update enabled resource
Posted by ernst Developer <er...@gmail.com>.
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?
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?
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?
Regards,
Ernst
2012/11/12 Francesco Chicchiriccò <il...@apache.org>
> 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/
>
>
Re: Sync enabled resource combined with update enabled resource
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/