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/11 10:50:14 UTC
syncope git commit: Capitalising some of the concepts
Repository: syncope
Updated Branches:
refs/heads/master a81d6121d -> 7af5e995d
Capitalising some of the concepts
Project: http://git-wip-us.apache.org/repos/asf/syncope/repo
Commit: http://git-wip-us.apache.org/repos/asf/syncope/commit/7af5e995
Tree: http://git-wip-us.apache.org/repos/asf/syncope/tree/7af5e995
Diff: http://git-wip-us.apache.org/repos/asf/syncope/diff/7af5e995
Branch: refs/heads/master
Commit: 7af5e995d60f30b500f4496ea3672c67d2a51d01
Parents: a81d612
Author: Colm O hEigeartaigh <co...@apache.org>
Authored: Thu Aug 11 11:49:58 2016 +0100
Committer: Colm O hEigeartaigh <co...@apache.org>
Committed: Thu Aug 11 11:49:58 2016 +0100
----------------------------------------------------------------------
.../asciidoc/getting-started/introduction.adoc | 12 ++++----
.../getting-started/systemRequirements.adoc | 2 +-
.../reference-guide/architecture/core.adoc | 8 +++---
.../reference-guide/concepts/entitlements.adoc | 4 +--
.../concepts/externalresources.adoc | 20 ++++++-------
.../reference-guide/concepts/policies.adoc | 28 +++++++++---------
.../concepts/provisioning/propagation.adoc | 10 +++----
.../concepts/provisioning/provisioning.adoc | 2 +-
.../concepts/provisioning/pull.adoc | 10 +++----
.../concepts/provisioning/push.adoc | 4 +--
.../reference-guide/concepts/realms.adoc | 16 +++++------
.../reference-guide/concepts/roles.adoc | 10 +++----
.../concepts/typemanagement.adoc | 30 ++++++++++----------
.../concepts/usersgroupsandanyobjects.adoc | 20 ++++++-------
.../reference-guide/concepts/workflow.adoc | 6 ++--
.../identitytechnologies/accessmanagers.adoc | 4 +--
.../identitytechnologies/identitystores.adoc | 8 +++---
.../provisioningengines.adoc | 8 +++---
.../thecompletepicture.adoc | 2 +-
.../reference-guide/reference-guide.adoc | 2 +-
.../adminconsole/configuration.adoc | 4 +--
.../adminconsole/dashboard.adoc | 4 +--
.../adminconsole/extensions.adoc | 2 +-
.../adminconsole/realms.adoc | 4 +--
.../workingwithapachesyncope/cli/group.adoc | 6 ++--
.../workingwithapachesyncope/cli/user.adoc | 16 +++++------
26 files changed, 121 insertions(+), 121 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/getting-started/introduction.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/getting-started/introduction.adoc b/src/main/asciidoc/getting-started/introduction.adoc
index bb06b5e..88f27c3 100644
--- a/src/main/asciidoc/getting-started/introduction.adoc
+++ b/src/main/asciidoc/getting-started/introduction.adoc
@@ -50,10 +50,10 @@ In brief, Identity Management takes care of managing identity data throughout wh
[.text-center]
image::identityLifecycle.png[title="Identity Lifecycle",alt="Identity Lifecycle",width="505",height="324"]
-.Users, groups and any objects
+.Users, Groups and Any Objects
****
-With Apache Syncope 2.0.0, the managed identities are not limited anymore to users and groups. New object types can be
-defined so that any objects data can be managed through Syncope: workstations, printers, folders, sensors, services,
+With Apache Syncope 2.0.0, the managed identities are not limited anymore to Users and Groups. New object types can be
+defined so that Any Object's data can be managed through Syncope: workstations, printers, folders, sensors, services,
and so on. This positions Apache Syncope at the forefront for bringing Identity Management in the IoT world.
****
@@ -65,7 +65,7 @@ image::iam-scenario.png[title="IAM Scenario",alt="IAM Scenario"]
The picture above shows the tecnologies involved in a complete IAM solution:
* *_Identity Store_* (as RDBMS, LDAP, Active Directory, meta- and virtual-directories) - the repository for account data
-* *_Provisioning Engine_* - synchronizes account data across identity stores and a broad range of data formats, models,
+* *_Provisioning Engine_* - synchronizes account data across Identity Stores and a broad range of data formats, models,
meanings and purposes
* *_Access Manager_* - access mediator to all applications, focused on application front-end, taking care of
authentication (https://en.wikipedia.org/wiki/Single_sign-on[Single Sign-On^]), authorization
@@ -79,7 +79,7 @@ From a technology point of view, *Apache Syncope* is primarily a *Provisioning E
==== Aren't Identity Stores enough?
-One might suppose that a single identity store can solve all the identity needs inside an organization, but there
+One might suppose that a single Identity Store can solve all the identity needs inside an organization, but there
are a few drawbacks with this approach:
. Heterogeneity of systems
@@ -110,7 +110,7 @@ written in any programming language, to consume IdM services.
* *_Logic_* implements the overall business logic that can be triggered via REST services, and controls some additional
features (notifications, reports and auditing)
* *_Provisioning_* is involved with managing the internal (via workflow) and external (via specific connectors)
-representation of users, groups and any objects. +
+representation of Users, Groups and Any Objects. +
This component often needs to be tailored to meet the requirements of a specific deployment, as it is the crucial decision
point for defining and enforcing the consistency and transformations between internal and external data. The default
all-Java implementation can be extended for this purpose. In addition, an http://camel.apache.org/[Apache Camel^]-based
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/getting-started/systemRequirements.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/getting-started/systemRequirements.adoc b/src/main/asciidoc/getting-started/systemRequirements.adoc
index 51ce41c..09ee9be 100644
--- a/src/main/asciidoc/getting-started/systemRequirements.adoc
+++ b/src/main/asciidoc/getting-started/systemRequirements.adoc
@@ -22,7 +22,7 @@
=== Hardware
The hardware requirements depend greatly on the given deployment, in particular the total number of
-managed entities (users, groups and any objects), their attributes and resources.
+managed entities (Users, Groups and Any Objects), their attributes and resources.
* CPU: dual core, 2 GHz (minimum)
* RAM: 2 GB (minimum)
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/architecture/core.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/architecture/core.adoc b/src/main/asciidoc/reference-guide/architecture/core.adoc
index c1b302a..1087a30 100644
--- a/src/main/asciidoc/reference-guide/architecture/core.adoc
+++ b/src/main/asciidoc/reference-guide/architecture/core.adoc
@@ -51,10 +51,10 @@ reports and auditing).
==== Provisioning
The Provisioning layer is involved with managing the internal (via workflow) and external (via specific connectors)
-representation of users, groups and any objects.
+representation of Users, Groups and Any Objects.
-One of the most important features provided is the <<mapping,mapping>> definition: internal data (users, for example)
-representation is correlated with information available on the available identity stores. +
+One of the most important features provided is the <<mapping,mapping>> definition: internal data (Users, for example)
+representation is correlated with information available on the available Identity Stores. +
Such definitions constitute the pillars of inbound (pull) and outbound (propagation / push)
<<provisioning,provisioning>>.
@@ -71,7 +71,7 @@ In addition, an http://camel.apache.org/[Apache Camel^]-based implementation is
[[workflow-layer]]
==== Workflow
-The Workflow layer is responsible for managing the internal lifecycle of users, groups and any objects.
+The Workflow layer is responsible for managing the internal lifecycle of Users, Groups and Any Objects.
Besides the default engine, another engine is available based on http://www.activiti.org/[Activiti BPM^], the
reference open source http://www.bpmn.org/[BPMN 2.0^] implementation. It enables advanced features such
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/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 832293a..f5c4e7f 100644
--- a/src/main/asciidoc/reference-guide/concepts/entitlements.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/entitlements.adoc
@@ -31,7 +31,7 @@ https://github.com/apache/syncope/blob/master/core/logic/src/main/java/org/apach
endif::[]
, the
http://docs.spring.io/spring-security/site/docs/4.1.x/reference/htmlsingle/#el-common-built-in[`hasRole` expression^]
-is used together with one of the standard entitlements to restrict access only to users owning the `REALM_LIST`
+is used together with one of the standard entitlements to restrict access only to Users owning the `REALM_LIST`
entitlement.
[source,java]
@@ -40,7 +40,7 @@ entitlement.
public List<RealmTO> list(final String fullPath) {
----
-Entitlements are granted via <<roles, roles>> to users, scoped under certain <<realms,realms>>, thus allowing
+Entitlements are granted via <<roles, roles>> to Users, scoped under certain <<realms,realms>>, thus allowing
<<delegated-administration,delegated administration>>.
[NOTE]
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/concepts/externalresources.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/externalresources.adoc b/src/main/asciidoc/reference-guide/concepts/externalresources.adoc
index ef2cdd4..37f6b92 100644
--- a/src/main/asciidoc/reference-guide/concepts/externalresources.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/externalresources.adoc
@@ -19,7 +19,7 @@
=== External Resources
****
-Connector Bundles:: The components able to connect to identity stores; not specifically bound to Apache Syncope,
+Connector Bundles:: The components able to connect to Identity Stores; not specifically bound to Apache Syncope,
as they are part of the http://connid.tirasa.net[ConnId^] project.
Connector Instances:: Instances of connector bundles, obtained by assigning values to the defined configuration
properties. For instance, there is only a single `DatabaseTable` (the bundle) that can be instantiated
@@ -78,9 +78,9 @@ available: with this flag set, a random value will be generated, compliant with
<<propagation,propagation>>, <<provisioning-pull,pull>> and <<provisioning-push,push>>
* configuration - see <<connector-instance-details,above>>
* capabilities - see <<connector-instance-details,above>>
-* account policy - which <<policies-account,account policy>> to enforce on users, groups and any objects assigned to
+* account policy - which <<policies-account,account policy>> to enforce on Users, Groups and Any Objects assigned to
this external resource
-* password policy - which <<policies-password,password policy>> to enforce on users, groups and any objects assigned to
+* password policy - which <<policies-password,password policy>> to enforce on Users, Groups and Any Objects assigned to
this external resource
* pull policy - which <<policies-pull,pull policy>> to apply during <<provisioning-pull,pull>> on this external
resource
@@ -95,10 +95,10 @@ configuring an external resource. Such information, in fact, plays a key role fo
[.text-center]
image::mapping.png[title="Sample mapping",alt="Sample mapping"]
-For each of the <<anytype,any types>> supported by the underlying connector, a different mapping is provided.
+For each of the <<anytype,Any Types>> supported by the underlying connector, a different mapping is provided.
A mapping is essentially a collection of _mapping items_ describing the correspondance between an user / group / any
-object attribute and its counterpart on the identity store represented by the current external resource. Each item
+object attribute and its counterpart on the Identity Store represented by the current external resource. Each item
specifies:
* internal attribute - the <<schema, schema>> acting as the source or destination of provisioning operations; it must be
@@ -110,7 +110,7 @@ specified by an expression matching one of the following models:
name `anyObjectName`, if a relationship with the mapped entity exists
** `memberships[groupName].schema` - resolves to the attribute for the given `schema`, owned by the membership for group
`groupName` of the mapped entity (user, any object), if such a membership exists
-* external attribute - the name of the attribute on the identity store
+* external attribute - the name of the attribute on the Identity Store
* transformers - http://commons.apache.org/proper/commons-jexl/[JEXL^] expression or Java class implementing
ifeval::["{snapshotOrRelease}" == "release"]
https://github.com/apache/syncope/blob/syncope-{docVersion}/core/provisioning-api/src/main/java/org/apache/syncope/core/provisioning/api/data/MappingItemTransformer.java[MappingItemTransformer^]
@@ -122,8 +122,8 @@ endif::[]
* mandatory condition - http://commons.apache.org/proper/commons-jexl/[JEXL^] expression indicating whether values for
this mapping item must be necessarily available or not; compared to a simple boolean value, such condition allows
complex statements to be expressed such as 'be mandatory only if this other attribute value is above 14', and so on
-* remote key flag - should this item be considered as the key value on the identity store?
-* password flag (users only) - should this item be treated as the password value?
+* remote key flag - should this item be considered as the key value on the Identity Store?
+* password flag (Users only) - should this item be treated as the password value?
* purpose - should this item be considered for <<propagation,propagation>> / <<provisioning-push,push>>,
<<provisioning-pull,pull>>, both or none?
@@ -131,8 +131,8 @@ Besides the items documented above, some more data needs to be specified for a c
* ConnId `objectClass` - which
http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/common/objects/ObjectClass.html[object class^]
-shall be used during communication with the identity store; predefined are `\\__ACCOUNT__` for users and
-`\\__GROUP__` for groups
+shall be used during communication with the Identity Store; predefined are `\\__ACCOUNT__` for Users and
+`\\__GROUP__` for Groups
* Object link - only required by some connector bundles as
https://connid.atlassian.net/wiki/display/BASE/LDAP[LDAP^] and
https://connid.atlassian.net/wiki/pages/viewpage.action?pageId=360482[Active Directory^], generally specifies the model
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/concepts/policies.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/policies.adoc b/src/main/asciidoc/reference-guide/concepts/policies.adoc
index 89dd666..de4bd01 100644
--- a/src/main/asciidoc/reference-guide/concepts/policies.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/policies.adoc
@@ -40,15 +40,15 @@ Account policies allow to impose constraints on username values, and are involve
[NOTE]
====
-When set for realm R, an account policy is enforced to all users of R and sub-realms.
+When set for realm R, an account policy is enforced to all Users of R and sub-realms.
-When set for resource R, an account policy is enforced to all users that have R assigned.
+When set for resource R, an account policy is enforced to all Users that have R assigned.
====
When defining an account policy, the following information is to be provided:
-* max authentication attempts - how many times users are allowed to fail authentication before getting suspended
-* propagate suspension - when suspended as consequence of too many authentication failures, should users also be
+* max authentication attempts - how many times Users are allowed to fail authentication before getting suspended
+* propagate suspension - when suspended as consequence of too many authentication failures, should Users also be
suspended on associated resources or not?
* pass-through resources - which <<external-resource-details,external resources>> are involved with
<<pass-through-authentication,pass-through authentication>>
@@ -121,7 +121,7 @@ external resource (provided that the underlying <<connector-instance-details,con
capability set): the first check succeeding will successfully authenticate the user.
This feature allows, for example, to avoid storing password values in the internal storage and to reuse credentials
-contained in identity stores (with no need of pulling them out), or to implement authentication chains.
+contained in Identity Stores (with no need of pulling them out), or to implement authentication chains.
[[policies-password]]
==== Password
@@ -130,14 +130,14 @@ Password policies allow to impose constraints on password values.
[NOTE]
====
-When set for realm R, a password policy is enforced to all users of R and sub-realms.
+When set for realm R, a password policy is enforced to all Users of R and sub-realms.
-When set for resource R, a password policy is enforced to all users that have R assigned.
+When set for resource R, a password policy is enforced to all Users that have R assigned.
====
When defining a password policy, the following information is to be provided:
-* allow null password - whether password is mandatory for users or not
+* allow null password - whether password is mandatory for Users or not
* history length - how many values shall be considered in the history
* rules - set of password rules to evaluate with the current policy
@@ -219,14 +219,14 @@ referring to configuration class
Pull policies are evaluated during the execution of <<tasks-pull,pull tasks>> and are meant to:
-. help matching existing users, groups and any objects during <<provisioning-pull,pull>>, thus generating update events
+. help matching existing Users, Groups and Any Objects during <<provisioning-pull,pull>>, thus generating update events
(rathern than create)
. determine which action shall be taken in case such match is not unique (e.g. what to do if the same external account
-can be mapped to two distinct users in Apache Syncope?)
+can be mapped to two distinct Users in Apache Syncope?)
[NOTE]
====
-When set for resource R, a pull policy is enforced to all users, groups and any objects pulled from R.
+When set for resource R, a pull policy is enforced to all Users, Groups and Any Objects pulled from R.
====
When defining a pull policy, the following information is to be provided:
@@ -236,13 +236,13 @@ When defining a pull policy, the following information is to be provided:
** `FIRSTMATCH` - pull first matching object only
** `LASTMATCH` - pull last matching object only
** `ALL` - pull all matching objects
-* rules - set of correlation rules to evaluate with the current policy; for each defined <<anytype,any type>>, a
+* rules - set of correlation rules to evaluate with the current policy; for each defined <<anytype,Any Type>>, a
different rule is required
===== Pull Correlation Rules
Pull correlation rules define how to match objects received from <<connector-instance-details,connector instances>>
-with existing users, groups or any objects.
+with existing Users, Groups or Any Objects.
The
ifeval::["{snapshotOrRelease}" == "release"]
@@ -273,5 +273,5 @@ Push policies are evaluated during the execution of <<tasks-push,push tasks>>.
[NOTE]
====
-When set for resource R, a push policy is enforced to all users, groups and any objects pushed to R.
+When set for resource R, a push policy is enforced to all Users, Groups and Any Objects pushed to R.
====
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/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 773528b..30b14a5 100644
--- a/src/main/asciidoc/reference-guide/concepts/provisioning/propagation.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/provisioning/propagation.adoc
@@ -18,11 +18,11 @@
//
==== Propagation
-Whenever a change is performed via REST on users, groups or any objects:
+Whenever a change is performed via REST on Users, Groups or Any Objects:
. a set of <<tasks-propagation,propagation tasks>> is generated, one for each associated external resource;
. the generated propagation tasks are executed, e.g. the corresponding operations (create, update or delete) are sent
-out, via connectors, to the configured identity stores; the tasks can be saved for later re-execution.
+out, via connectors, to the configured Identity Stores; the tasks can be saved for later re-execution.
[TIP]
.Which external resources?
@@ -31,8 +31,8 @@ Depending on the entity being created / updated / deleted, different external re
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
+* *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
@@ -50,7 +50,7 @@ which implements the following logic:
fails
* status and eventual error message (in case of no resource priority) can be saved for reporting, in case 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
+* 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
Different implementations of the
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/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 358f879..d3afdba 100644
--- a/src/main/asciidoc/reference-guide/concepts/provisioning/provisioning.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/provisioning/provisioning.adoc
@@ -34,7 +34,7 @@ image::provisioningFlow.png[title="Provisioning flow",alt="Provisioning flow"]
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
+* 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
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/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 6444c18..3b7be5f 100644
--- a/src/main/asciidoc/reference-guide/concepts/provisioning/pull.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/provisioning/pull.adoc
@@ -19,7 +19,7 @@
[[provisioning-pull]]
==== Pull
-Pull is the mechanism used to acquire identity data from identity stores; for each external resource, one or more
+Pull is the mechanism used to acquire identity data from Identity Stores; for each external resource, one or more
<<tasks-pull,pull tasks>> can be defined, run and scheduled for period execution.
Pull task execution involves querying the external resource and then processing each entity in an isolated transaction;
@@ -54,7 +54,7 @@ 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_ specified:
****
FULL RECONCILIATION:: The complete list of entities available is processed.
@@ -70,13 +70,13 @@ this condition. +
[TIP]
.Pull Templates
====
-With every <<tasks-pull,pull task>> it is possible to add a template for each defined <<anytype,any type>>.
+With every <<tasks-pull,pull task>> it is possible to add a template for each defined <<anytype,Any Type>>.
As the values specified in the template are applied to pulled entities, this can be used as mechanism for setting
default values for attributes or external resources on entities.
-A typical use case is, when pulling users from the external resource `R`, to automatically assign `R` so that every
-further modification in Apache Syncope to such users will be <<propagation,propagated>> back to `R`.
+A typical use case is, when pulling Users from the external resource `R`, to automatically assign `R` so that every
+further modification in Apache Syncope to such Users will be <<propagation,propagated>> back to `R`.
====
===== PullActions
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/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 bba13d0..3c418b0 100644
--- a/src/main/asciidoc/reference-guide/concepts/provisioning/push.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/provisioning/push.adoc
@@ -19,7 +19,7 @@
[[provisioning-push]]
==== Push
-With push, the matching set of internal entities can be sent to identity stores - mainly for
+With push, the matching set of internal entities can be sent to Identity Stores - mainly for
(re)initialization purposes; for each external resource, one or more <<tasks-push,push tasks>> can be defined, run and
scheduled for period execution.
@@ -31,7 +31,7 @@ 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.
+by default, unmatching entities are pushed to Identity Stores, and matching updated.
.Matching Rules
****
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/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 bd1ef66..e47dfb1 100644
--- a/src/main/asciidoc/reference-guide/concepts/realms.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/realms.adoc
@@ -18,8 +18,8 @@
//
=== Realms
-Realms define a hierarchical security domain tree, primarily meant for containing users, groups and
-any objects.
+Realms define a hierarchical security domain tree, primarily meant for containing Users, Groups and
+Any Objects.
Each realm:
@@ -28,16 +28,16 @@ Each realm:
. 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;
. 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 to all Users, Groups and Any Objects in the given realm and sub-realms, unless some sub-realms define their own.
-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 member of a realm then they are also member of 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>>:
-* 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.
+* 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.
Moreover, this partition allows fine-grained control over policy enforcement and, alongside with
<<entitlements,entitlements>> and <<roles,roles>>, contribute to implement
@@ -56,12 +56,12 @@ a mechanism for setting default values for attributes or external resources on e
<<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>>.
-Typical use cases for realm provisioning apply to modelization of organization-like structure on identity stores, as
+Typical use cases for realm provisioning apply to modelization of 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 into 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/7af5e995/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 68aaa12..3985c67 100644
--- a/src/main/asciidoc/reference-guide/concepts/roles.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/roles.adoc
@@ -25,14 +25,14 @@ Roles map set of <<entitlements,entitlements>> to set of <<realms,realms>>.
====
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
+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
+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
@@ -40,8 +40,8 @@ sub-realms.
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~.
+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:
@@ -63,7 +63,7 @@ above:
====
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
+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.
====
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/concepts/typemanagement.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/typemanagement.adoc b/src/main/asciidoc/reference-guide/concepts/typemanagement.adoc
index e0878db..b78374b 100644
--- a/src/main/asciidoc/reference-guide/concepts/typemanagement.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/typemanagement.adoc
@@ -18,7 +18,7 @@
//
=== Type Management
-In order to manage which attributes can be owned by users, groups and any object, and which values can be provided,
+In order to manage which attributes can be owned by Users, Groups and any object, and which values can be provided,
Apache Syncope defines a simple yet powerful type management system, vaguely inspired by the LDAP/X.500 information
model.
@@ -82,13 +82,13 @@ evaluating the related JEXL expression
===== Virtual
-Virtual attributes are somehow linked from identity stores rather than stored internally.
+Virtual attributes are somehow linked from Identity Stores rather than stored internally.
-The typical use case is when attribute values can change in the identity store without notice, and it is required to
+The typical use case is when attribute values can change in the Identity Store without notice, and it is required to
always have access to the most recent values that are available.
-It can also be said that virtual schemas are for attributes whose ownership is not that of Syncope but of an identity store;
-the external resources for such identity stores are said to be the _linking resources_.
+It can also be said that virtual schemas are for attributes whose ownership is not that of Syncope but of an Identity Store;
+the external resources for such Identity Stores are said to be the _linking resources_.
[TIP]
As best practice, only attributes for which Apache Syncope retains ownership should be modeled as plain attributes;
@@ -105,7 +105,7 @@ When defining a virtual schema, the following information must be provided:
.Virtual Attribute Cache
****
For performance optimization, virtual attributes are managed by an internal cache to control the actual access to
-the linked identity stores.
+the linked Identity Stores.
The internal cache implements the
ifeval::["{snapshotOrRelease}" == "release"]
@@ -137,7 +137,7 @@ endif::[]
ifeval::["{snapshotOrRelease}" == "snapshot"]
https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/cache/DisabledVirAttrCache.java[DisabledVirAttrCache^]
endif::[]
-| Pass-through cache which actually does not provide any caching: use when direct access to the identity store is required.
+| Pass-through cache which actually does not provide any caching: use when direct access to the Identity Store is required.
|===
****
@@ -146,7 +146,7 @@ endif::[]
Any type classes are aggregations of plain, derived and virtual schemas, provided with unique identifiers.
-Classes can be assigned to <<anytype, any types>> and are also available as auxiliary (hence to be specified on a
+Classes can be assigned to <<anytype, Any Types>> and are also available as auxiliary (hence to be specified on a
given user / group / any object instance) and for <<type-extensions,type extensions>>.
==== AnyType
@@ -154,10 +154,10 @@ given user / group / any object instance) and for <<type-extensions,type extensi
Any types represent the type of identities that Apache Syncope is able to manage; besides the predefined `USER` and
`GROUP`, more types can be created to model workstations, printers, folders, sensors, services, ...
-For all any types that are defined, a set of <<anytypeclass, classes>> can be selected so that instances af a given any type will
+For all Any Types that are defined, a set of <<anytypeclass, classes>> can be selected so that instances af a given any type will
be enabled to populate attributes for schemas in those classes.
-.Any types and attributes allowed for users, groups and any objects
+.Any types and attributes allowed for Users, Groups and Any Objects
====
Assuming that the following schemas are available:
@@ -165,12 +165,12 @@ Assuming that the following schemas are available:
. derived: `fullname`
. virtual: `enrollment`
-and that the following any type classes are defined:
+and that the following Any Type classes are defined:
. `minimal` - containing `firstname`, `surname` and `fullname`
. `member` - containing `email` and `enrollment`
-and that the `USER` any type has only `minimal` assigned, then the following users are valid (details are simplified to
+and that the `USER` Any Type has only `minimal` assigned, then the following Users are valid (details are simplified to
increase readability):
[source,json]
@@ -252,10 +252,10 @@ increase readability):
==== RelationshipType
-Relationships allow the creation of a link between a user and an any object, or between two any objects; relationship types
+Relationships allow the creation of a link between a user and an any object, or between two Any Objects; relationship types
define the available link types.
-.Relationship between any objects (printers)
+.Relationship between Any Objects (printers)
====
The following any object of type `PRINTER` contains a relationship of type `neighborhood` with another `PRINTER`
(details are simplified to increase readability):
@@ -298,7 +298,7 @@ The following any object of type `PRINTER` contains a relationship of type `neig
When a user (or an any object) is part of a group, a _membership_ is defined.
It is sometimes useful to define attributes which are bound to a particular membership: if, for example, the
-`University A` and `University B` groups are available, a student might have different e-mail addresses for each
+`University A` and `University B` Groups are available, a student might have different e-mail addresses for each
university. How can this be modeled?
Type extensions define a set of <<anytypeclass,classes>> associated to a group, that can be automatically
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/concepts/usersgroupsandanyobjects.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/usersgroupsandanyobjects.adoc b/src/main/asciidoc/reference-guide/concepts/usersgroupsandanyobjects.adoc
index 05e6f80..5b7db98 100644
--- a/src/main/asciidoc/reference-guide/concepts/usersgroupsandanyobjects.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/usersgroupsandanyobjects.adoc
@@ -18,7 +18,7 @@
//
=== Users, Groups and Any Objects
-Users, groups and any objects are definitely the key entities to manage: as explained <<introduction,above>>
+Users, Groups and Any Objects are definitely the key entities to manage: as explained <<introduction,above>>
in fact, the whole identity management concept is literally about managing identity data.
Starting with Apache Syncope 2.0, the following identities are supported:
@@ -26,14 +26,14 @@ Starting with Apache Syncope 2.0, the following identities are supported:
* *Users* represent the virtual identities build up of account information fragmented across the associated external
resources
* *Groups* have the dual purpose of representing entities on external resources supporting this concept (say LDAP or
-Active Directory) and putting together users or any objects for implementing group-based provisioning, e.g. to
-dynamically associate users or any objects to external resources
+Active Directory) and putting together Users or Any Objects for implementing group-based provisioning, e.g. to
+dynamically associate Users or Any Objects to external resources
* *Any Objects* actually cover very different entities that can be modeled: printers, services, sensors, ...
For each of the identities above, Apache Syncope is capable of maintaining:
-. `name` (`username`, for users) - string value uniquely identifying a specific user, group or any object instance;
-. `password` (users only) - hashed or encrypted value, depending on the selected `password.cipher.algorithm` - see
+. `name` (`username`, for Users) - string value uniquely identifying a specific user, group or any object instance;
+. `password` (Users only) - hashed or encrypted value, depending on the selected `password.cipher.algorithm` - see
<<configuration-parameters, below>> for details - which can be used for authentication;
. set of attributes, with each attribute being a `(key,values)` pair where
@@ -49,11 +49,11 @@ value (i.e. _plain_, _derived_ and _virtual_);
====
Each user / group / any object will be able to hold values for all schemas:
-. defined in the <<AnyTypeClass,any type classes>> associated to their <<AnyType, any type>>;
-. defined in the <<AnyTypeClass,any type classes>> configured as *_auxiliary_* for the specific instance.
+. defined in the <<AnyTypeClass,Any Type classes>> associated to their <<AnyType, any type>>;
+. defined in the <<AnyTypeClass,Any Type classes>> configured as *_auxiliary_* for the specific instance.
====
-Moreover, users and any objects can be part of groups, or associated to other any objects.
+Moreover, Users and Any Objects can be part of Groups, or associated to other any objects.
[[memberships-relationships]]
[NOTE]
@@ -69,9 +69,9 @@ When an user or an any object is associated to another any object, a *_relations
[TIP]
.Static and Dynamic Memberships
====
-Users and any objects are _statically_ assigned to groups when memberships are explicitly set.
+Users and Any Objects are _statically_ assigned to Groups when memberships are explicitly set.
-With group definition, however, a condition can be expressed so that all matching users and any objects are
+With group definition, however, a condition can be expressed so that all matching Users and Any Objects are
_dynamic_ members of the group. +
Dynamic memberships have some limitations: for example, <<type-extensions,type extensions>> do not apply;
group-based provisioning is still effective.
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/concepts/workflow.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/concepts/workflow.adoc b/src/main/asciidoc/reference-guide/concepts/workflow.adoc
index 5863816..c7394fb 100644
--- a/src/main/asciidoc/reference-guide/concepts/workflow.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/workflow.adoc
@@ -76,7 +76,7 @@ https://camunda.org/[Camunda^] or http://jbpm.jboss.org/[jBPM^].
==== Activiti User Workflow Adapter
-An advanced adapter is provided for users, based on http://www.activiti.org/[Activiti BPM^], the reference open source
+An advanced adapter is provided for Users, based on http://www.activiti.org/[Activiti BPM^], the reference open source
http://www.bpmn.org/[BPMN 2.0^] implementation.
The
@@ -112,7 +112,7 @@ image::userWorkflow.png[title="Default Activiti user workflow",alt="Default Acti
Every transition in the Activiti user workflow definition can be subjected to approval.
The underlying idea is that some kind of self-modifications (group memberships, external resource assignments, ...)
-might not be allowed to 'plain' users, as there could be conditions which require management approval.
+might not be allowed to 'plain' Users, as there could be conditions which require management approval.
Managers could also be asked for completing the information provided before the requested operation is completed.
In order to define an approval form, a dedicated BPMN `userTask` needs to be defined, following the rules established
@@ -139,7 +139,7 @@ http://www.activiti.org/userguide/index.html#activitiModeler[Activiti Modeler^].
</userTask>
----
<1> `formKey` and `id` must be unique across the workflow definition, `name` is displayed by the admin console;
-`candidateGroups` and `candidateUsers` might be defined, even both, to indicate which groups or users should be
+`candidateGroups` and `candidateUsers` might be defined, even both, to indicate which Groups or Users should be
managing these approvals
<2> `expression` will be evaluated against the current requesting `user` (as workflow variable) and related properties;
read-only form input can be defined by setting `writable="false"`
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/identitytechnologies/accessmanagers.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/identitytechnologies/accessmanagers.adoc b/src/main/asciidoc/reference-guide/identitytechnologies/accessmanagers.adoc
index dd134a0..c0727fb 100644
--- a/src/main/asciidoc/reference-guide/identitytechnologies/accessmanagers.adoc
+++ b/src/main/asciidoc/reference-guide/identitytechnologies/accessmanagers.adoc
@@ -19,9 +19,9 @@
==== Access Managers
_Access Managers_ focus on the application front-end, enforcing application access via authentication
-(how users are let access a given system) and authorization (which capabilities each user owns on a given system).
+(how Users are let access a given system) and authorization (which capabilities each user owns on a given system).
-Several practices and standards can be implemented by access managers:
+Several practices and standards can be implemented by Access Managers:
* https://en.wikipedia.org/wiki/Single_sign-on[Single Sign-On^]
* http://oauth.net/[OAuth^]
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/identitytechnologies/identitystores.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/identitytechnologies/identitystores.adoc b/src/main/asciidoc/reference-guide/identitytechnologies/identitystores.adoc
index ad5c471..6f0fac4 100644
--- a/src/main/asciidoc/reference-guide/identitytechnologies/identitystores.adoc
+++ b/src/main/asciidoc/reference-guide/identitytechnologies/identitystores.adoc
@@ -20,10 +20,10 @@
_Identity Stores_ are the places where identity-related information is stored.
-An identity store can be shared among several systems: as a result, there is a single place where account data is
+An Identity Store can be shared among several systems: as a result, there is a single place where account data is
managed by administrators, and the same password can be used for the same user for accessing different applications.
-Various identity store types are available:
+Various Identity Store types are available:
* Flat files (XML, CSV, ...)
* LDAP
@@ -38,7 +38,7 @@ image::theExternalWorld.jpg[title="Apache Syncope and the external world",alt="A
.ConnId
****
-Apache Syncope relies on http://connid.tirasa.net[ConnId^] for communication with identity stores; ConnId is designed to
+Apache Syncope relies on http://connid.tirasa.net[ConnId^] for communication with Identity Stores; ConnId is designed to
separate the implementation of an application from the dependencies of the system that the application is attempting to
connect to.
@@ -54,7 +54,7 @@ such as for SOAP, CSV, PowerShell and Active Directory \u2013 are also provided.
[CAUTION]
.Aren't Identity Stores enough?
====
-One might suppose that a single identity store can solve all the identity needs inside an organization, but there
+One might suppose that a single Identity Store can solve all the identity needs inside an organization, but there
are a few drawbacks with this approach:
. Heterogeneity of systems
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/identitytechnologies/provisioningengines.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/identitytechnologies/provisioningengines.adoc b/src/main/asciidoc/reference-guide/identitytechnologies/provisioningengines.adoc
index 86320d3..2cb7709 100644
--- a/src/main/asciidoc/reference-guide/identitytechnologies/provisioningengines.adoc
+++ b/src/main/asciidoc/reference-guide/identitytechnologies/provisioningengines.adoc
@@ -22,14 +22,14 @@ The main role of _Provisioning Engines_ is to keep Identity Stores synchronized
Some other characteristics and features provided:
-* Adapt to identity store data and application models
-* Do not require changes in identity stores or applications
-* Build virtual unified view of identity data distributed across several identity stores
+* Adapt to Identity Store data and application models
+* Do not require changes in Identity Stores or applications
+* Build virtual unified view of identity data distributed across several Identity Stores
* Allow to define and enforce security policies
* Permit workflow definition, with transitions subject to approval
* Focused on application back-end
-In brief, provisioning engines take heterogeneous identity stores (and business requirements) as input and build up
+In brief, provisioning engines take heterogeneous Identity Stores (and business requirements) as input and build up
high-level identity data management throughout what is called the *Identity Lifecycle*.
[.text-center]
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/identitytechnologies/thecompletepicture.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/identitytechnologies/thecompletepicture.adoc b/src/main/asciidoc/reference-guide/identitytechnologies/thecompletepicture.adoc
index 1be1aa4..2e8397b 100644
--- a/src/main/asciidoc/reference-guide/identitytechnologies/thecompletepicture.adoc
+++ b/src/main/asciidoc/reference-guide/identitytechnologies/thecompletepicture.adoc
@@ -19,7 +19,7 @@
==== The Complete Picture
The picture below shows a typical scenario where an organization's infrastructure is helped by identity technologies in
-providing secure and trusted application access to end-users, while keeping different levels of data and processes under
+providing secure and trusted application access to end-Users, while keeping different levels of data and processes under
control for business owners, help-desk operators and system administrators.
[.text-center]
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/reference-guide.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/reference-guide.adoc b/src/main/asciidoc/reference-guide/reference-guide.adoc
index c280448..e0f4c53 100644
--- a/src/main/asciidoc/reference-guide/reference-guide.adoc
+++ b/src/main/asciidoc/reference-guide/reference-guide.adoc
@@ -64,7 +64,7 @@ both of them.
****
Identity Management:: Tools and practices to keep identity data consistent and synchronized across repositories, data
formats and models.
-Access Management:: Systems, protocols and technologies supporting user authentication (how users are let accessing a
+Access Management:: Systems, protocols and technologies supporting user authentication (how Users are let accessing a
given system) and authorization (which capabilities each user owns on a given system).
****
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/configuration.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/configuration.adoc b/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/configuration.adoc
index 87c4419..ae13817 100644
--- a/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/configuration.adoc
+++ b/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/configuration.adoc
@@ -34,7 +34,7 @@ not be displayed.
Notifications::
This allows the admin to set events and corresponding templates for mail notification to be sent
-to the users. Trace level defines the condition in which an event will trigger the sending of a
+to the Users. Trace level defines the condition in which an event will trigger the sending of a
notification. Templates for such notifications can also be added and edited using this tab.
Parameters::
@@ -56,5 +56,5 @@ with the realms that they are enforced upon.
Security Question::
-The admin can use this to define a set of security questions which the endusers can choose from
+The admin can use this to define a set of security questions which the endUsers can choose from
to allow them to recover their account in case of a forgotten password.
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/dashboard.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/dashboard.adoc b/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/dashboard.adoc
index 51c3663..c05dcc1 100644
--- a/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/dashboard.adoc
+++ b/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/dashboard.adoc
@@ -28,8 +28,8 @@ Overview::
Contains widgets to display
-* Number of users
-* Number of groups
+* Number of Users
+* Number of Groups
* Number of external resource instances available (Printer as a default)
* Number of resources
* Configuration Status: Shows the status of missing or incomplete configurations.
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/extensions.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/extensions.adoc b/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/extensions.adoc
index 63dc080..aadd49e 100644
--- a/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/extensions.adoc
+++ b/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/extensions.adoc
@@ -20,7 +20,7 @@
===== Extensions
The extensions tab shows the extensions installed on the given Apache Syncope deployment.
-Among the available extensions, the one for Apache Camel-based provisioning is often installed: users can inspect the
+Among the available extensions, the one for Apache Camel-based provisioning is often installed: Users can inspect the
performance measures for the various routes defined.
image::consoleCamelExtension.png[console-camel-extension]
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/realms.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/realms.adoc b/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/realms.adoc
index b3d60cd..4732e90 100644
--- a/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/realms.adoc
+++ b/src/main/asciidoc/reference-guide/workingwithapachesyncope/adminconsole/realms.adoc
@@ -18,7 +18,7 @@
//
[[console-realms]]
===== Realms
-The realms tab provides the admin with the power to manage users, groups and any objects, for all any types defined.
+The realms tab provides the admin with the power to manage Users, Groups and Any Objects, for all Any Types defined.
image::realmsUser.png[console-realms-user]
@@ -29,7 +29,7 @@ Allows the admin to
* Create user
* Force password change for user
* Manage resources available to user
-* Enable/Disable users
+* Enable/Disable Users
* Clone a user
* Edit user details
* View and edit propagation tasks of user
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/group.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/group.adoc b/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/group.adoc
index d113eff..802a430 100644
--- a/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/group.adoc
+++ b/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/group.adoc
@@ -18,7 +18,7 @@
//
===== Group command
-The group command retrieves information about the configured groups.
+The group command retrieves information about the configured Groups.
[discrete]
====== Help message
@@ -43,9 +43,9 @@ Usage: group [options]
====== Options
--details::
-This option shows a table with the amount of available groups and some additional information.
+This option shows a table with the amount of available Groups and some additional information.
--list::
-Running the command with this option you will see the list of the groups.
+Running the command with this option you will see the list of the Groups.
--read::
The option to read the group passed as input.
--read-attr-by-schema-type::
http://git-wip-us.apache.org/repos/asf/syncope/blob/7af5e995/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/user.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/user.adoc b/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/user.adoc
index e9dcb36..5e2ce0b 100644
--- a/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/user.adoc
+++ b/src/main/asciidoc/reference-guide/workingwithapachesyncope/cli/user.adoc
@@ -18,7 +18,7 @@
//
===== User command
-The user command retrieves information about the users.
+The user command retrieves information about the Users.
[discrete]
====== Help message
@@ -55,9 +55,9 @@ Usage: user [options]
====== Options
--details::
-This option shows a table with some details about the users.
+This option shows a table with some details about the Users.
-- List option::
-Running the command with this option you will see the list of all users in the environment. However, the system will
+Running the command with this option you will see the list of all Users in the environment. However, the system will
ask you a confirmation before execution, because as you can imagine this operation might produce very large output.
--get-user-key::
The option to get the user key starting from a username.
@@ -68,14 +68,14 @@ The option to read user information by their user id.
--read-by-usernam::
The option to read user information by their username.
--search-by-attribute::
-The option to search a list of users with a common attribute.
+The option to search a list of Users with a common attribute.
--search-by-role::
-The option to search a list of users with a specified role.
+The option to search a list of Users with a specified role.
--search-by-resource::
-The option to search a list of users with a specified resource.
+The option to search a list of Users with a specified resource.
--delete
The option to delete a specified user.
--delete-by-attribute
-The option to delete the users with a common attribute.
+The option to delete the Users with a common attribute.
--delete-all
-The option to delete all users of the realm passed as input.
\ No newline at end of file
+The option to delete all Users of the realm passed as input.
\ No newline at end of file