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/10 16:07:03 UTC
syncope git commit: Some grammatical fixes for the reference guide.
More to follow.
Repository: syncope
Updated Branches:
refs/heads/master 0910230d0 -> 15c34e764
Some grammatical fixes for the reference guide. More to follow.
Project: http://git-wip-us.apache.org/repos/asf/syncope/repo
Commit: http://git-wip-us.apache.org/repos/asf/syncope/commit/15c34e76
Tree: http://git-wip-us.apache.org/repos/asf/syncope/tree/15c34e76
Diff: http://git-wip-us.apache.org/repos/asf/syncope/diff/15c34e76
Branch: refs/heads/master
Commit: 15c34e7644fb797dff42ab7e9e153d2264da9cd2
Parents: 0910230
Author: Colm O hEigeartaigh <co...@apache.org>
Authored: Wed Aug 10 17:05:33 2016 +0100
Committer: Colm O hEigeartaigh <co...@apache.org>
Committed: Wed Aug 10 17:05:33 2016 +0100
----------------------------------------------------------------------
.../architecture/architecture.adoc | 4 ++--
.../reference-guide/architecture/core.adoc | 20 +++++++++---------
.../concepts/typemanagement.adoc | 22 ++++++++++----------
.../concepts/usersgroupsandanyobjects.adoc | 12 +++++------
.../identitytechnologies/accessmanagers.adoc | 5 ++---
.../identitytechnologies/identitystores.adoc | 6 +++---
.../identitytechnologies.adoc | 2 +-
.../provisioningengines.adoc | 4 ++--
8 files changed, 37 insertions(+), 38 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/syncope/blob/15c34e76/src/main/asciidoc/reference-guide/architecture/architecture.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/architecture/architecture.adoc b/src/main/asciidoc/reference-guide/architecture/architecture.adoc
index 9fc1c6c..c4a1373 100644
--- a/src/main/asciidoc/reference-guide/architecture/architecture.adoc
+++ b/src/main/asciidoc/reference-guide/architecture/architecture.adoc
@@ -60,5 +60,5 @@ Java <<client-library,Client Library>> (the basis of Admin UI, End-user UI and C
==== Eclipse IDE Plugin
-The Eclipse IDE plugin allows remote management of notification e-mail and report templates and constitutes an example
-of Java application relying on the Client Library for interacting with Core via REST.
+The Eclipse IDE plugin allows remote management of notification e-mail and report templates, and constitutes an example
+of a Java application relying on the Client Library for interacting with the Core via REST.
http://git-wip-us.apache.org/repos/asf/syncope/blob/15c34e76/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 cc2ec2e..c1b302a 100644
--- a/src/main/asciidoc/reference-guide/architecture/core.adoc
+++ b/src/main/asciidoc/reference-guide/architecture/core.adoc
@@ -35,7 +35,7 @@ Syncope deployment to complement the native features with domain-specific operat
An <<swagger-ui,extension>> is available, providing full http://swagger.io/[Swagger^] features,
which enables in-browser access to all the REST endpoints defined.
-At technical level, the RESTful interface is a fully-compliant
+At a technical level, the RESTful interface is a fully-compliant
https://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services[JAX-RS 2.0^] implementation based on
http://cxf.apache.org[Apache CXF^], natively dealing both with JSON and XML payloads.
@@ -43,9 +43,9 @@ More details are available in the dedicated <<restful-services,usage>> section.
==== Logic
-Right below the external interface level, the overall business logic, orchestrating the other layers for implementing
-the operations that can be triggered via REST services, and controling some additional features (notifications,
-reports and audit over all).
+Right below the external interface level, the overall business logic is responsible for orchestrating the other layers, by implementing
+the operations that can be triggered via REST services. It is also responsible for controling some additional features (notifications,
+reports and auditing).
[[provisioning-layer]]
==== Provisioning
@@ -65,7 +65,7 @@ The default implementation can be sometimes tailored to meet the requirements of
it is the crucial decision point for defining and enforcing the consistency and transformations between internal and
external data.
-In addition, an http://camel.apache.org/[Apache Camel^]-based implementation is also available as
+In addition, an http://camel.apache.org/[Apache Camel^]-based implementation is also available as an
<<apache-camel-provisioning-engine,extension>>, which brings all the power of runtime changes and adaptation.
[[workflow-layer]]
@@ -73,9 +73,9 @@ In addition, an http://camel.apache.org/[Apache Camel^]-based implementation is
The Workflow layer is responsible for managing the internal lifecycle of users, groups and any objects.
-Besides the default engine, another based on http://www.activiti.org/[Activiti BPM^], the
-reference open source http://www.bpmn.org/[BPMN 2.0^] implementation, is available for users, enabling advanced features
-as approval management and new statuses definition. An optional web-based GUI editor is also available.
+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
+as approval management and new statuses definitions. An optional web-based GUI editor is also available.
[.text-center]
image::userWorkflow.png[title="Default Activiti user workflow",alt="Default Activiti user workflow"]
@@ -85,7 +85,7 @@ https://camunda.org/[Camunda^] or http://jbpm.jboss.org/[jBPM^], can be written
==== Persistence
-All data (users, groups, attributes, resources, ...) is internally managed at high level using a standard
+All data (users, groups, attributes, resources, ...) is internally managed at a high level using a standard
https://en.wikipedia.org/wiki/Java_Persistence_API[JPA 2.0^] approach. The data is persisted into an underlying
database, referred to as *_Internal Storage_*. Consistency is ensured via the comprehensive
http://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html[transaction management^]
@@ -96,7 +96,7 @@ with no code changes: MySQL, MariaDB, PostgreSQL, Oracle and MS SQL Server are f
==== Security
-Rather than being a separated layer, Security features are triggered throughout incoming request processing.
+Rather than being a separate layer, Security features are triggered throughout incoming request processing.
A fine-grained set of entitlements is defined which can be granted to administrators, thus enabling the
implementation of <<delegated-administration,delegated administration>> scenarios.
http://git-wip-us.apache.org/repos/asf/syncope/blob/15c34e76/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 af8b783..63713c1 100644
--- a/src/main/asciidoc/reference-guide/concepts/typemanagement.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/typemanagement.adoc
@@ -19,19 +19,19 @@
=== Type Management
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
+Apache Syncope defines a simple yet powerful type management system, vaguely inspired by the LDAP/X.500 information
model.
==== Schema
-A schema instance describes the values that attributes with that schema will held; it can be defined plain, derived or
+A schema instance describes the values that attributes with that schema will hold; it can be defined plain, derived or
virtual.
===== Plain
-Values for attributes with such schema kind are provided during user, group or any object create / update.
+Values for attributes with such schema types are provided during user, group or any object create / update.
-When defining a plain schema, the following information is to be provided:
+When defining a plain schema, the following information must be provided:
* Type
** `String`
@@ -42,13 +42,13 @@ http://docs.oracle.com/javase/7/docs/api/java/text/DecimalFormat.html[DecimalFor
** `Boolean`
** `Date` - allows to specify a _conversion pattern_ to / from string, according to
http://docs.oracle.com/javase/7/docs/api/java/text/DateFormat.html[DateFormat^]
-** `Enum` - requires to provide
+** `Enum`
*** enumeration values (mandatory)
*** enumeration labels (optional, values will be used alternatively)
-** `Encrypted` - requires to provide
+** `Encrypted`
*** secret key
*** cipher algorithm
-** `Binary` - requires to provide the declared mime type
+** `Binary` - it is required to provide the declared mime type
* Validator class - (optional) Java class validating the value(s) provided for attributes, see
ifeval::["{snapshotOrRelease}" == "release"]
https://github.com/apache/syncope/blob/syncope-{docVersion}/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/attrvalue/validation/EmailAddressValidator.java[EmailAddressValidator^]
@@ -59,7 +59,7 @@ endif::[]
for reference
* Mandatory condition - http://commons.apache.org/proper/commons-jexl/[JEXL^] expression indicating whether values for
this schema must be necessarily provided or not; compared to simple boolean value, such condition allows to express
-complex statements like as 'be mandatory only if this other attribute value is above 14', and so on
+complex statements like 'be mandatory only if this other attribute value is above 14', and so on
* Unique constraint - make sure that no duplicate value(s) for this schema are found
* Multivalue flag - whether single or multiple values are supported
* Read-only flag - whether value(s) for this schema are modifiable only via internal code (say workflow tasks) or
@@ -67,12 +67,12 @@ can be instead provided during ordinary <<provisioning,provisioning>>
===== Derived
-Sometimes it is handful to obtain values as arbitrary combination of other attributes' values: for example, with
+Sometimes it is useful to obtain values as arbitrary combinations of other attributes' values: for example, with
`firstname` and `surname` plain schemas, it is natural to think that `fullname` could be somehow defined as the
concatenation of `firstname` 's and `surname` 's values, separated by a blank space.
-Derived schemas are always read-only and require to specify a http://commons.apache.org/proper/commons-jexl/[JEXL^]
-expression referencing plain schema(s). +
+Derived schemas are always read-only and require a http://commons.apache.org/proper/commons-jexl/[JEXL^]
+expression to be specified that reference plain schema types. +
For the sample above, it would be
firstname + ' ' + surname
http://git-wip-us.apache.org/repos/asf/syncope/blob/15c34e76/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 dcf9b42..05e6f80 100644
--- a/src/main/asciidoc/reference-guide/concepts/usersgroupsandanyobjects.adoc
+++ b/src/main/asciidoc/reference-guide/concepts/usersgroupsandanyobjects.adoc
@@ -25,7 +25,7 @@ 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 double purpose of representing entities on external resources supporting this concept (say LDAP or
+* *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
* *Any Objects* actually cover very different entities that can be modeled: printers, services, sensors, ...
@@ -37,11 +37,11 @@ For each of the identities above, Apache Syncope is capable of maintaining:
<<configuration-parameters, below>> for details - which can be used for authentication;
. set of attributes, with each attribute being a `(key,values)` pair where
- ** `key` is a string label (i.e. `surname`);
- ** `values` is a (possibly singleton) collection of data (i.e. `[Doe]` but also
+ ** `key` is a string label (e.g. `surname`);
+ ** `values` is a (possibly singleton) collection of data (e.g. `[Doe]` but also
`[\john.doe@syncope.apache.org, \jdoe@gmail.com]`)
; the type of values that can be assigned to each attribute is defined via the <<schema,schema>> matching the `key`
-value: being schema defined as _plain_, _derived_ and _virtual_, so can be attributes;
+value (i.e. _plain_, _derived_ and _virtual_);
. associations with <<external-resources,external resources>>, for <<provisioning,provisioning>>.
[IMPORTANT]
@@ -60,7 +60,7 @@ Moreover, users and any objects can be part of groups, or associated to other an
.Memberships and Relationships
====
When an user or an any object is assigned to a group, a *_membership_* is defined; the (static) members of a group
-benefit of <<type-extensions,type extensions>>.
+benefit from <<type-extensions,type extensions>>.
When an user or an any object is associated to another any object, a *_relationship_* is defined, of one of available
<<relationshiptype,relationship types>>.
@@ -69,7 +69,7 @@ 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 explicitely 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
_dynamic_ members of the group. +
http://git-wip-us.apache.org/repos/asf/syncope/blob/15c34e76/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 dfbcf5a..dd134a0 100644
--- a/src/main/asciidoc/reference-guide/identitytechnologies/accessmanagers.adoc
+++ b/src/main/asciidoc/reference-guide/identitytechnologies/accessmanagers.adoc
@@ -18,9 +18,8 @@
//
==== Access Managers
-_Access Managers_ focus on application front-end, sitting as mediators to application access and taking authentication
-(how users are let accessing a given system) and authorization (which capabilities each user owns on a given system)
-in charge.
+_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).
Several practices and standards can be implemented by access managers:
http://git-wip-us.apache.org/repos/asf/syncope/blob/15c34e76/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 8a7f504..ad5c471 100644
--- a/src/main/asciidoc/reference-guide/identitytechnologies/identitystores.adoc
+++ b/src/main/asciidoc/reference-guide/identitytechnologies/identitystores.adoc
@@ -54,13 +54,13 @@ 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 few
-drawbacks are just around the corner:
+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
. Lack of a single source of information (HR for corporate id, Groupware for mail address, ...)
. Often applications require a local user database
. Inconsistent policies across the infrastructure
. Lack of workflow management
-. Hidden infrastructure management cost, growing with organization
+. Hidden infrastructure management cost, growing with the size of the organization
====
http://git-wip-us.apache.org/repos/asf/syncope/blob/15c34e76/src/main/asciidoc/reference-guide/identitytechnologies/identitytechnologies.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/reference-guide/identitytechnologies/identitytechnologies.adoc b/src/main/asciidoc/reference-guide/identitytechnologies/identitytechnologies.adoc
index 43faf5b..3129ab1 100644
--- a/src/main/asciidoc/reference-guide/identitytechnologies/identitytechnologies.adoc
+++ b/src/main/asciidoc/reference-guide/identitytechnologies/identitytechnologies.adoc
@@ -23,7 +23,7 @@ Identity and Access Management (IAM) is not implemented by a single technology;
heterogeneous technologies - differing by maturity, scope, applicability and feature coverage - which require some
'glue' to fit together.
-As with other application domains, it can be observed that tools appeared earlier tend to partially overlap with more
+As with other application domains, it can be observed that tools that appeared earlier tend to partially overlap with more
recent, targeted products.
include::identitystores.adoc[]
http://git-wip-us.apache.org/repos/asf/syncope/blob/15c34e76/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 601344d..86320d3 100644
--- a/src/main/asciidoc/reference-guide/identitytechnologies/provisioningengines.adoc
+++ b/src/main/asciidoc/reference-guide/identitytechnologies/provisioningengines.adoc
@@ -18,7 +18,7 @@
//
==== Provisioning Engines
-The main role of _Provisioning Engines_ is to keep Identity Stores as much synchronized as possible.
+The main role of _Provisioning Engines_ is to keep Identity Stores synchronized as much as possible.
Some other characteristics and features provided:
@@ -37,5 +37,5 @@ image::identityLifecycle.png[title="Identity Lifecycle",alt="Identity Lifecycle"
[NOTE]
====
-Technologically, *Apache Syncope* is primarily a *Provisioning Engine*.
+From a technology point of view, *Apache Syncope* is primarily a *Provisioning Engine*.
====