Hi Vedrin,

Vedrin Jeliazkov wrote on 06/22/2010 01:30 PM:
> Hi Andreas, All,
>
> On 22 June 2010 12:28, Andreas Maunz<andreas at maunz.de>  wrote:
>
>> Creation and deletion:
>> - Webservice developers are encouraged to tie resources and policies as
>> close as possible together in order to avoid "orphans", i.e. resources or
>> policies that have no matching policy or resource, respectively. This is a
>> design task, but could in the future also be more soundly tackled by a
>> technology that attaches policies more directly to a resource.
>
> IMHO this would be a nice feature to have, however a very careful  and
> detailed investigation of possible pitfalls, especially in a
> distributed context needs to be carried out. As we have discussed
> already in a recent conf call, there are (at least) two cases where
> resource-policy synchronisation could suffer, leading to "orphans"
> (deadlocks):
>
> 1) Synchronisation at creation time -- we need to specify in details
> how this is achieved. Somehow more tight requirements might be:
>
> 1.1) a resource cannot be published without a corresponding policy
> being already in place;
> 1.2) a policy should be dropped if the corresponding resource is not
> published successfully;
>
> Discussion: Compliance with (1.1) could be achieved rather easily
> through changes in the corresponding OT web service, which holds the
> resource to be published. On the other hand (1.2) is trickier -- it is
> not obvious who'll take care to delete a policy, which has been
> created for a given resource that subsequently is not published
> successfully. We might decide that again the OT web service,

I would go for that, because... (see next comment)

> holding the resource in question should delete the policy, or alternatively,
> the policy service should check whether the resource is published and
> in case that it is not, then delete the policy.

... that could only be done by periodically checks of the policy 
webservice, which seems not good practice to me (however, we might need 
such a "garbage collection" despite that).

> A further complication
> arises from possible network/service outages, which might happen at
> random time and interfere with the desired atomicity of
> resource-policy creation.

Yes, it feels somehow awkward having them separated. We try our best to 
have the AA service up at all times. Christoph is currently preparing a 
hot-spare system. However, please also keep in mind that OpenSSO 
(formerly SUN Access Manager) has been used in companies for decades(!) 
like that, e.g. Deutsche Telekom is one big customer.

> 2) Synchronisation at delete -- again, we should study all scenarios
> that might happen when a given resource and its corresponding policy
> have to be deleted. Let's state again some requirements:
>
> 2.1) the resource should be deleted before its corresponding policy;
> 2.2) there shouldn't be any policies without a corresponding resource;
>
> Discussion: It looks like both in (1) and (2) we would need an
> additional state where a policy can exist for a short period of time
> (how long?) without a corresponding resource in place.

Only for a "virtual second". Exceptions during resource deletion must be 
caught and policy only deleted on succesful resource deletion.
Of course, policy deletion could fail as well. In that case, resources 
would have to be restored. However, this might be impossible. Therefore, 
a workaround would be to first delete the policy instead of the 
resource. This would be safe, since, without a policy, access is blocked 
completely. Also, policies can be downloaded before deletion (in order 
to back them up for easy restore).

> In (1) the
> policy will be waiting for the corresponding resource to be published,
> while in (2) the policy will be allowed to exist without a
> corresponding resource while the policy is being deleted (I imagine
> that this could take a while if the policy is complex and the policy
> service has to respond to many requests simultaneously). We should
> also think what would happen if the policy service does not delete a
> given policy reasonably fast (how fast?) -- should the resource holder
> service cancel the request and re-publish the resource? Who will
> remember the previous policy state, allowing to perform such cancel
> operation? And what about the resource to be re-published? Again,
> atomicity of resource-policy deletion might be not easy to achieve in
> all cases in our distributed framework.

Policy deletion before resource deletion could also address some of 
these issues.

Regards
Andreas