syncope-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ilgro...@apache.org
Subject [2/3] syncope git commit: [SYNCOPE-700] Roles
Date Fri, 05 Aug 2016 13:21:38 GMT
[SYNCOPE-700] Roles


Project: http://git-wip-us.apache.org/repos/asf/syncope/repo
Commit: http://git-wip-us.apache.org/repos/asf/syncope/commit/96048866
Tree: http://git-wip-us.apache.org/repos/asf/syncope/tree/96048866
Diff: http://git-wip-us.apache.org/repos/asf/syncope/diff/96048866

Branch: refs/heads/master
Commit: 9604886626041378511e47bbe029051018b42790
Parents: a1149b2
Author: Francesco Chicchiriccò <ilgrosso@apache.org>
Authored: Fri Aug 5 10:00:51 2016 +0200
Committer: Francesco Chicchiriccò <ilgrosso@apache.org>
Committed: Fri Aug 5 15:21:30 2016 +0200

----------------------------------------------------------------------
 .../reference-guide/concepts/concepts.adoc      | 58 +---------------
 .../reference-guide/concepts/roles.adoc         | 69 ++++++++++++++++++++
 2 files changed, 72 insertions(+), 55 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/syncope/blob/96048866/src/main/asciidoc/reference-guide/concepts/concepts.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/concepts.adoc b/src/main/asciidoc/reference-guide/concepts/concepts.adoc
index 841c88a..fa262e4 100644
--- a/src/main/asciidoc/reference-guide/concepts/concepts.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/concepts.adoc
@@ -28,61 +28,7 @@ include::realms.adoc[]
 
 include::entitlements.adoc[]
 
-=== Roles
-
-[TIP]
-.Static and Dynamic Memberships
-====
-Users are _statically_ assigned to roles when assignments are explicitely set.
-
-With role definition, however, a condition can be expressed so that all matching users are
_dynamic_ members of the
-role.
-====
-
-==== Delegated Administration
-
-The idea is that any user U assigned to a role R, which provides entitlements E~1~...E~n~
for realms Re~1~...Re~k~ can 
-exercise E~i~ on entities (users or groups, depending on the type of E~i~) under any Re~j~
or related sub-realms.
-
-About group membership and any relationships:
-
-* User U can be member of group G either if U and G are in the same realm, or G is in one
of super-realms of the realm 
-of U
-* Any object A~1~ can be in relationship with any object A~2~ either if A~1~ and A~2~ are
in the same realm, or A~2~ is
-in one of super-realms of the realm of A~1~
-
-The rationale behind such conditions is to allow the definition of common groups and any
objects (to enter in 
-relationship with) at the topmost position in the realm tree, so that they can be shared
by various realm sub-trees.
-
-.Authorization
-====
-Let's suppose that we want to implement the following scenario:
-
-****
-Administrator A can create users under realm R~5~ but not under realm R~7~, administrator
B can update users under 
-realm R~6~ and R~8~, administrator C can update groups under realm R~8~.
-****
-
-As default, Syncope will have defined the following entitlements, among others:
-
-* `USER_CREATE`
-* `USER_UPDATE`
-* `GROUP_UPDATE`
-
-Here it follows how entitlements should be assigned (via roles) to administrators in order
to implement the scenario 
-above:
-
-* A: `USER_CREATE` on R~5~
-* B: `USER_UPDATE` on R~6~ and R~8~
-* C: `GROUP_UPDATE` on R~8~
-====
-
-[NOTE]
-.Group Ownership
-====
-====
-
-=== Domains
+include::roles.adoc[]
 
 include::provisioning/provisioning.adoc[]
 
@@ -126,3 +72,5 @@ include::provisioning/provisioning.adoc[]
 === Reports
 
 === Audit
+
+=== Domains

http://git-wip-us.apache.org/repos/asf/syncope/blob/96048866/src/main/asciidoc/reference-guide/concepts/roles.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/roles.adoc b/src/main/asciidoc/reference-guide/concepts/roles.adoc
new file mode 100644
index 0000000..68aaa12
--- /dev/null
+++ b/src/main/asciidoc/reference-guide/concepts/roles.adoc
@@ -0,0 +1,69 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+=== Roles
+
+Roles map set of <<entitlements,entitlements>> to set of <<realms,realms>>.
+
+[TIP]
+.Static and Dynamic Memberships
+====
+Users are _statically_ assigned to roles when assignments are explicitely set.
+
+With role definition, however, a condition can be expressed so that all matching users are
_dynamic_ members of the
+role.
+====
+
+==== Delegated Administration
+
+The idea is that any user U assigned to a role R, which provides entitlements E~1~...E~n~
for realms Re~1~...Re~k~ can 
+exercise E~i~ on entities (users, groups, any objects of given types, depending on E~i~)
under any Re~j~ or related
+sub-realms.
+
+.Authorization
+====
+Let's suppose that we want to implement the following scenario:
+
+****
+Administrator A can create users under realm R~5~ but not under realm R~7~, administrator
B can update users under 
+realm R~6~ and R~8~, administrator C can update groups under realm R~8~.
+****
+
+As by default, Apache Syncope will have defined the following entitlements, among others:
+
+* `USER_CREATE`
+* `USER_UPDATE`
+* `GROUP_UPDATE`
+
+Hence, here is how entitlements should be assigned (via roles) to administrators in order
to implement the scenario 
+above:
+
+* Administrator A: `USER_CREATE` on R~5~
+* Administrator B: `USER_UPDATE` on R~6~ and R~8~
+* Administrator C: `GROUP_UPDATE` on R~8~
+====
+
+[NOTE]
+.Group Ownership
+====
+Groups can designate user or another group as _owner_.
+
+The practical consequence of this setting is that users owning a group (either because they
are directly set as owners
+or members of the owning group) is that they are entitled to perform all operations (create,
update, delete, ...) on the
+owned group, regardless of the realm.
+====


Mime
View raw message