Changes between Version 14 and Version 15 of S3/S3AAA/OrgAuth


Ignore:
Timestamp:
09/03/12 13:55:13 (9 years ago)
Author:
Dominic König
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • S3/S3AAA/OrgAuth

    v14 v15  
    4141== Extended Restriction of Access ==
    4242
    43 Any role of a user is always only applied to the realms the role is restricted to. That is, the user can exercise permissions of role X only on the records of the entity he has this role '''for'''. E.g. a user who is "HR Manager" for OrgA can exercise the "HR Manager" permissions only on records "owned" by OrgA.
     43Any role of a user is always only applied to the realms the role is restricted to.
     44
     45  That is, the user can exercise permissions of role X only on the records of the entity he has this role '''for'''. E.g. a user who is "HR Manager" for OrgA can exercise the "HR Manager" permissions only on records "owned" by OrgA.
    4446
    4547If there is no restriction in the role assignment (for_pe=0), then the role applies for all records regardless of their owner entity (=site-wide role).
     
    4749The AUTHENTICATED, ANONYMOUS and ADMIN roles can not be restricted to realms, i.e. the permissions of these roles always apply for all records.
    4850
    49 '''NOTE:''' It is possible to define a dynamic realm in a role assignment (for_pe=None). This "dynamic realm" is the realm of all entities the user is directly affiliated with at the time of the request. This practice can though be dangerous and my be inappropriate for most multi-tenancy settings, because the user would automatically receive this role for any entity they will ever join in future - without that entity being anyhow in control of this. However, in certain deployments, this may still be convenient.
     51  '''NOTE:''' It is possible to define a ''dynamic realm'' in a role assignment (for_pe=None). This dynamic realm is the realm of all entities the user is directly affiliated with at the time of the request. This practice can though be dangerous and may be inappropriate for most multi-tenancy settings, because the user would automatically receive this role for any entity they will ever join in future - without that entity being anyhow in control of this. However, in certain deployments, this may still be convenient.
    5052== Delegations of Permissions ==
    5153