You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@syncope.apache.org by co...@apache.org on 2016/08/12 10:04:02 UTC
syncope git commit: Docs updates for entitlements, roles,
realms + provisioning
Repository: syncope
Updated Branches:
refs/heads/master 85945187a -> 7ce6dbce3
Docs updates for entitlements, roles, realms + provisioning
Project: http://git-wip-us.apache.org/repos/asf/syncope/repo
Commit: http://git-wip-us.apache.org/repos/asf/syncope/commit/7ce6dbce
Tree: http://git-wip-us.apache.org/repos/asf/syncope/tree/7ce6dbce
Diff: http://git-wip-us.apache.org/repos/asf/syncope/diff/7ce6dbce
Branch: refs/heads/master
Commit: 7ce6dbce398d8be5f177e487e77f283ba64966bc
Parents: 8594518
Author: Colm O hEigeartaigh <co...@apache.org>
Authored: Fri Aug 12 11:03:31 2016 +0100
Committer: Colm O hEigeartaigh <co...@apache.org>
Committed: Fri Aug 12 11:03:58 2016 +0100
----------------------------------------------------------------------
.../reference-guide/concepts/entitlements.adoc | 2 +-
.../concepts/provisioning/propagation.adoc | 10 ++++----
.../concepts/provisioning/provisioning.adoc | 7 +++---
.../concepts/provisioning/pull.adoc | 14 ++++++------
.../concepts/provisioning/push.adoc | 4 ++--
.../reference-guide/concepts/realms.adoc | 24 ++++++++++----------
.../reference-guide/concepts/roles.adoc | 10 ++++----
7 files changed, 35 insertions(+), 36 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/syncope/blob/7ce6dbce/src/main/asciidoc/reference-guide/concepts/entitlements.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/entitlements.adoc b/src/main/asciidoc/reference-guide/concepts/entitlements.adoc
index f5c4e7f..4e61616 100644
--- a/src/main/asciidoc/reference-guide/concepts/entitlements.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/entitlements.adoc
@@ -59,5 +59,5 @@ endif::[]
ifeval::["{snapshotOrRelease}" == "snapshot"]
https://github.com/apache/syncope/blob/master/ext/camel/common-lib/src/main/java/org/apache/syncope/common/lib/types/CamelEntitlement.java[enlarge the initial list^]
endif::[]
-: this because entitlements are the pillars of internal security model and not meant for external usage.
+: this is because entitlements are the pillars of the internal security model and are not meant for external usage.
====
http://git-wip-us.apache.org/repos/asf/syncope/blob/7ce6dbce/src/main/asciidoc/reference-guide/concepts/provisioning/propagation.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/provisioning/propagation.adoc b/src/main/asciidoc/reference-guide/concepts/provisioning/propagation.adoc
index 30b14a5..928fa67 100644
--- a/src/main/asciidoc/reference-guide/concepts/provisioning/propagation.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/provisioning/propagation.adoc
@@ -30,9 +30,9 @@ out, via connectors, to the configured Identity Stores; the tasks can be saved f
Depending on the entity being created / updated / deleted, different external resources are taken into account by the
propagation process:
-* *group*: only the external resources directly assigned
-* *user*: the external resources directly assigned plus the ones assigned to Groups configured for the user
-* *any object*: the external resources directly assigned plus the ones assigned to Groups configured for the Any Object
+* *Group*: only the external resources directly assigned
+* *User*: the external resources directly assigned plus the ones assigned to Groups configured for the User
+* *Any Object*: the external resources directly assigned plus the ones assigned to Groups configured for the Any Object
====
By default, the propagation process is controlled by the
@@ -48,7 +48,7 @@ which implements the following logic:
* tasks for resources with no priority are executed afterwards, concurrently
* the execution of a given set of tasks is halted (and global failure is reported) whenever the first sequential task
fails
-* status and eventual error message (in case of no resource priority) can be saved for reporting, in case the related
+* status and eventual error message (in case of no resource priority) can be saved for reporting, in the case where the related
external resource was configured with adequate tracing
* minimize the set of operations to be actually performed onto the Identity Store by attempting to read the external
object corresponding to the internal entity and comparing with the modifications provided
@@ -86,7 +86,7 @@ endif::[]
ifeval::["{snapshotOrRelease}" == "snapshot"]
https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/propagation/LDAPMembershipPropagationActions.java[LDAPMembershipPropagationActions^]
endif::[]
-| If user is associated to group in Syncope, keeps the corresponding user as member of the corresponding group on LDAP.
+| If a User is associated with a Group in Syncope, keep the corresponding User as a amember of the corresponding Group in LDAP.
|
ifeval::["{snapshotOrRelease}" == "release"]
http://git-wip-us.apache.org/repos/asf/syncope/blob/7ce6dbce/src/main/asciidoc/reference-guide/concepts/provisioning/provisioning.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/provisioning/provisioning.adoc b/src/main/asciidoc/reference-guide/concepts/provisioning/provisioning.adoc
index d3afdba..51a1911 100644
--- a/src/main/asciidoc/reference-guide/concepts/provisioning/provisioning.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/provisioning/provisioning.adoc
@@ -18,10 +18,9 @@
//
=== Provisioning
-As introduced <<provisioning-engines,above>>, provisioning is actually _the_ core feature provided by Apache Syncope.
+As described <<provisioning-engines,above>>, provisioning is actually _the_ core feature provided by Apache Syncope.
-Essentially, it can be seen as the process of keeping the identity data, on Syncope and related external resources,
-synchronized according to the specifications provided by the <<mapping,mapping>> by performing create, update and
+Essentially, it can be seen as the process of keeping the identity data synchronized between Syncope and related external resources, according to the specifications provided by the <<mapping,mapping>>. It does this by performing create, update and
delete operations onto the <<persistence,internal storage>> or external resources via connectors.
==== Overview
@@ -37,7 +36,7 @@ The provisioning operations can be initiated in several different ways:
* by creating, updating or deleting Users, Groups or Any Objects via REST (thus involving the underlying
<<logic,logic>> layer)
* by requesting execution of pull or push tasks via REST
-* by triggering periodic pull or push task execution
+* by triggering periodic pull or push task executions
include::propagation.adoc[]
http://git-wip-us.apache.org/repos/asf/syncope/blob/7ce6dbce/src/main/asciidoc/reference-guide/concepts/provisioning/pull.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/provisioning/pull.adoc b/src/main/asciidoc/reference-guide/concepts/provisioning/pull.adoc
index 3b7be5f..75f2912 100644
--- a/src/main/asciidoc/reference-guide/concepts/provisioning/pull.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/provisioning/pull.adoc
@@ -29,8 +29,8 @@ a retrieved entity can be:
enclosing external resource;
. _unmatching_ otherwise.
-Once assessed this, entities are processed according to the matching / unmatching rules specified for the pull task:
-by default, unmatching entities gets internally created, and matching updated.
+Once this has been assessed, entities are processed according to the matching / unmatching rules specified for the pull task:
+by default, unmatching entities get created internally, and matching entities are updated.
.Matching Rules
****
@@ -54,15 +54,15 @@ by default, unmatching entities gets internally created, and matching updated.
[TIP]
.Pull Mode
====
-The Identity Store can be queried in different ways, depending on the _pull mode_ specified:
+The Identity Store can be queried in different ways, depending on the _pull mode_ that is specified:
****
FULL RECONCILIATION:: The complete list of entities available is processed.
FILTERED RECONCILIATION:: The subset matching the provided filter of all available entities is processed.
-INCREMENTAL:: Only the actual modifications performed since last pull task execution are considered. This mode requires
+INCREMENTAL:: Only the actual modifications performed since the last pull task execution are considered. This mode requires
the underlying connector bundle to implement the ConnId `SYNC` operation - only some of the available bundles match
this condition. +
-*This is the only mode allowing to pull delete events*, which may end up in causing internal entities removal.
+*This is the only mode which allows pulling delete events*, which may end up causing the removal of internal entities.
****
====
@@ -91,7 +91,7 @@ https://github.com/apache/syncope/blob/master/core/provisioning-api/src/main/jav
endif::[]
interface.
-Some examples are included by default, see table below.
+Some examples are included by default, see the table below.
[cols="1,2"]
|===
@@ -103,7 +103,7 @@ endif::[]
ifeval::["{snapshotOrRelease}" == "snapshot"]
https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/LDAPMembershipPullActions.java[LDAPMembershipPullActions^]
endif::[]
-| If user is associated to group on LDAP, keeps the corresponding user as member of the corresponding group on Syncope.
+| If a User is associated with a Group in LDAP, keep the corresponding User as a member of the corresponding Group in Syncope.
|
ifeval::["{snapshotOrRelease}" == "release"]
http://git-wip-us.apache.org/repos/asf/syncope/blob/7ce6dbce/src/main/asciidoc/reference-guide/concepts/provisioning/push.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/provisioning/push.adoc b/src/main/asciidoc/reference-guide/concepts/provisioning/push.adoc
index 3c418b0..d029d60 100644
--- a/src/main/asciidoc/reference-guide/concepts/provisioning/push.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/provisioning/push.adoc
@@ -30,8 +30,8 @@ an internal entity can be:
enclosing external resource;
. _unmatching_ otherwise.
-Once assessed this, entities are processed according to the matching / unmatching rules specified for the push task:
-by default, unmatching entities are pushed to Identity Stores, and matching updated.
+Once this has been assessed, entities are processed according to the matching / unmatching rules specified for the push task:
+by default, unmatching entities are pushed to Identity Stores, and matching entities are updated.
.Matching Rules
****
http://git-wip-us.apache.org/repos/asf/syncope/blob/7ce6dbce/src/main/asciidoc/reference-guide/concepts/realms.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/realms.adoc b/src/main/asciidoc/reference-guide/concepts/realms.adoc
index e47dfb1..5b5ecac 100644
--- a/src/main/asciidoc/reference-guide/concepts/realms.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/realms.adoc
@@ -24,23 +24,23 @@ Any Objects.
Each realm:
. has a unique name and a parent realm - except for the pre-defined _root realm_, which is named `/`;
-. is either leaf or root of a sub-tree of realms;
-. is uniquely identified by the path from root realm, e.g. `/a/b/c` identifies the sub-realm `c` in the sub-tree rooted
-at `b`, having in turn `a` as parent realm, directly under root realm;
+. is either a leaf or root of a sub-tree of realms;
+. is uniquely identified by the path from the root realm, e.g. `/a/b/c` identifies the sub-realm `c` in the sub-tree rooted
+at `b`, having in turn `a` as parent realm, directly under the root realm;
. optionally refers to <<policies-account,account>> and <<policies-password,password>> policies: such policies are
-enforced to all Users, Groups and Any Objects in the given realm and sub-realms, unless some sub-realms define their own.
+enforced on all Users, Groups and Any Objects in the given realm and sub-realms, unless some sub-realms define their own policies.
-If Users, Groups and Any Objects are member of a realm then they are also member of parent realm: as a result, the root
+If Users, Groups and Any Objects are members of a realm then they are also members of the parent realm: as a result, the root
realm contains everything, and other realms can be seen as containers that split up the total number of entities into
smaller pools.
-This has consequences on <<memberships-relationships,memberhips and relationships>>:
+This has consequences on <<memberships-relationships,memberships and relationships>>:
-* An user or an any object can be member of Groups in the same realm or in one of sub-realms.
-* An user or an any object can be in relation with Any Objects in the same realm or in one of sub-realms.
+* A User or an Any Object can be members of Groups in the same realm or in one of the sub-realms.
+* A User or an Any object can be in a relation with Any Objects in the same realm or in one of the sub-realms.
Moreover, this partition allows fine-grained control over policy enforcement and, alongside with
-<<entitlements,entitlements>> and <<roles,roles>>, contribute to implement
+<<entitlements,entitlements>> and <<roles,roles>>, helps to implement
<<delegated-administration,delegated administration>>.
[TIP]
@@ -54,14 +54,14 @@ a mechanism for setting default values for attributes or external resources on e
==== Realm Provisioning
<<provisioning>> can be enabled for realms: <<mapping,mapping>> information can be provided so that realms
-are considered during <<propagation,propagation>>, <<provisioning-pull,pull>> and <<provisioning-push,push>>.
+are considered during <<propagation,propagation>>, <<provisioning-pull,pull>> and <<provisioning-push,push>> tasks.
-Typical use cases for realm provisioning apply to modelization of organization-like structure on Identity Stores, as
+A typical use case for realm provisioning is to model an organization-like structure on Identity Stores, as
with LDAP and Active Directory.
==== LogicActions
-When Users, Groups or Any Objects get created, updated or deleted into a realm, custom logic can be invoked by
+When Users, Groups or Any Objects get created, updated or deleted in a realm, custom logic can be invoked by
associating the given realm with one or more implementations of the
ifeval::["{snapshotOrRelease}" == "release"]
https://github.com/apache/syncope/blob/syncope-{docVersion}/core/provisioning-api/src/main/java/org/apache/syncope/core/provisioning/api/LogicActions.java[LogicActions^]
http://git-wip-us.apache.org/repos/asf/syncope/blob/7ce6dbce/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
index 3985c67..8edb838 100644
--- a/src/main/asciidoc/reference-guide/concepts/roles.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/roles.adoc
@@ -18,20 +18,20 @@
//
=== Roles
-Roles map set of <<entitlements,entitlements>> to set of <<realms,realms>>.
+Roles map a set of <<entitlements,entitlements>> to a set of <<realms,realms>>.
[TIP]
.Static and Dynamic Memberships
====
-Users are _statically_ assigned to roles when assignments are explicitely set.
+Users are _statically_ assigned to roles when assignments are explicitly set.
-With role definition, however, a condition can be expressed so that all matching Users are _dynamic_ members of the
+However, a condition can be expressed in the role definition 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
+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.
@@ -61,7 +61,7 @@ above:
[NOTE]
.Group Ownership
====
-Groups can designate user or another group as _owner_.
+Groups can designate a 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