erw-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Erw-devel] Feedback on authorisation


From: erw-devel
Subject: [Erw-devel] Feedback on authorisation
Date: 22 Sep 2003 16:51:43 +0200

I'm working at completing 1.0. The main improvement is that now the user
interface is sensitive to permissions, so, for instance, if you make a
relationship editing element read-only, you just get the relationship
list without Remove button, and the background is grey.

The second improvement is about security: things like read-only
attributes were relying on the form working correctly, but no check
was performed server-side upon submission. Now you cannot play any
longer. 8^)

I would like to have some feedback about authorisation. I'm trying to
nail down a reasonable policy (the present one works more or less OK,
but it is informal).

The process by which a user acquires select, update, insert and delete
privileges on an element is clear, and mathematically defined. Moreover,
list of elements in embedded relationships are loaded following the user
permissions.

The main question is: what about relationships and embedded weak
entities? More precisely: which authorisations are implied for them?

Presently, when you insert a new entity you can insert relationships,
and when you update an entity you can update, *delete* or *insert*
relationships.

Of course, delete permissions imply the same for relationships (when you
delete an entity you lose the related relationships, too), and the same
holds for select.

So the only non-orthogonal point is that if you have update permissions
on an entity, you get, beside update, also delete and insert permissions
for relationships. This seems to be natural, as updating an entity
should allow to modify its properties (which include relationships).
Note that with the current setup it is easy to restrict relationship
handling by making their input read-only.

The "mathematical" approach would be requiring delete permissions on the
entity to delete an incident relationship, but this would be IMHO very
unnatural, and would lead to uselessly complex schemes.

Thus, for relationship types the current setup is IMHO OK.

The situation is completely different for what matters embedded weak
entities. In that case, the authorisation system is completely skipped,
which does not happen with non-embedded weak entities.

I'm changing the current setup so that for embedded weak entities
authorisation IS necessary. Nothing is inferred from the main type. This
seems to be right because updating, inserting or deleting an embedded
entity is actually an entity-, not a relationship-based operation. This
also aligns embedded and non-embedded entity types.

Comments are welcome.

-- 
Ciao,

                                seba




reply via email to

[Prev in Thread] Current Thread [Next in Thread]