entrouvert
/
paul-synchro
Archived
17
0
Fork 0
Code Issues Pull Requests Releases Activity
This repository has been archived on 2023-02-21. You can view files and clone it, but cannot push or open issues or pull requests.
paul-synchro/doc_typos.patch

327 lines
15 KiB
Diff
Raw Permalink Blame History

diff --git a/doc/attribute_management.rst b/doc/attribute_management.rst
index ffef950..f20c5f9 100644
--- a/doc/attribute_management.rst
+++ b/doc/attribute_management.rst
@@ -111,7 +111,7 @@ ___________________________________________________
To find the user in a LDAP directory, authentic2 must know its distinguished
name (DN). If this LDAP has been used when the user has authenticated,
-Authentic 2 learn the user DN. Nothing has to be done from this point of view.
+Authentic 2 learns the user DN. Nothing has to be done from this point of view.
However, if it is expected that user attributes be taken in a directory that
is not used by the user for authentication, it is necessary to manually
diff --git a/doc/config_cas_sp.rst b/doc/config_cas_sp.rst
index 1e22f85..3712c9b 100644
--- a/doc/config_cas_sp.rst
+++ b/doc/config_cas_sp.rst
@@ -24,5 +24,5 @@ How to use Authentic 2 as a CAS 1.0 or CAS 2.0 identity provider ?
http[s]://your.domain.com/idp/cas/
-5. If needed configure your service to resolve authenticated user with your
+5. If needed configure your service to resolve authenticated users with your
LDAP directory (if user attributes are needed for your service)
diff --git a/doc/config_saml2_idp.rst b/doc/config_saml2_idp.rst
index 0d8a6d6..b04ab5f 100644
--- a/doc/config_saml2_idp.rst
+++ b/doc/config_saml2_idp.rst
@@ -123,10 +123,10 @@ the nameID is not recognized as an existing federation.
Two values are possible: "Create new account" and "Account linking by authentication".
The value "Create new account" makes Authentic 2 create a user account associated
-to the nameID received.
+with the nameID received.
The value "Account linking by authentication" makes Authentic 2 ask the user to
-authenticate with an existing account to associate the nameID to this account.
+authenticate with an existing account to associate the nameID with this account.
Behavior with transient nameID
_______________________________
@@ -140,7 +140,7 @@ The value "Open a session" makes Authentic 2 open a session.
The value "Ask authentication" makes Authentic 2 ask for a user authentication,
even when a valid assertion is received. That may have sense for instance if
-the SSO login is used only to receive signed attributes for users with existing
+the SSO login is only used to receive signed attributes for users with existing
accounts.
@@ -161,7 +161,7 @@ the menu 'Update metadata', then click on 'Go'.
:width: 800 px
:align: center
-How to create in bulk identity providers with the sync-metadata script?
+How to create in-bulk identity providers with the sync-metadata script?
=======================================================================
See the page explaining the use of the script sync-metadata :ref:`sync-metadata_script`.
diff --git a/doc/config_saml2_sp.rst b/doc/config_saml2_sp.rst
index ee8729d..72861a3 100644
--- a/doc/config_saml2_sp.rst
+++ b/doc/config_saml2_sp.rst
@@ -136,7 +136,7 @@ the menu 'Update metadata', then click on 'Go'.
:width: 800 px
:align: center
-How to create in bulk service providers with the sync-metadata script?
+How to create in-bulk service providers with the sync-metadata script?
======================================================================
See the page explaining the use of the script sync-metadata :ref:`sync-metadata_script`.
diff --git a/doc/consent_management.rst b/doc/consent_management.rst
index b468ffd..2e714cf 100644
--- a/doc/consent_management.rst
+++ b/doc/consent_management.rst
@@ -8,11 +8,11 @@ What is the SAML2 federation consent aka account linking consent?
=================================================================
At the first single sign on process on the identity provider side, the user
-may be asked if she agrees to federation its local account with the remote
+may be asked if she agrees to federate her local account with the remote
account on the service provider side.
The account linking also called a federation means that the nameID is
-persistent and will link the two accounts. This signed identifier allows to
+persistent and will link the two accounts. This signed identifier allows
the service provider to login the user without reauthentication during the
following single sign on process.
@@ -34,7 +34,7 @@ if the user consent must be asked to the user.
:width: 800 px
:align: center
-*Take care that is the identity provider provides the service provider with
+*Take care that if the identity provider provides the service provider with
a transient nameID, there is no account linking, so there is no need for a
consent.*
diff --git a/doc/overview.rst b/doc/overview.rst
index e95e894..2553ec5 100644
--- a/doc/overview.rst
+++ b/doc/overview.rst
@@ -53,6 +53,6 @@ Support
Authentic's developpers and users hangs on the mailing list authentic@listes.entrouvert.com.
See archives or register at http://listes.entrouvert.com/info/authentic.
-You can open reports or feature request on http://authentic.entrouvert.org.
+You can open reports or feature requests on http://authentic.entrouvert.org.
-Entr'ouvert also provides a commercial support. For information, visit http://www.entrouvert.com.
+Entr'ouvert also provides commercial support. For information, visit http://www.entrouvert.com.
diff --git a/doc/quick_ldap_backend.rst b/doc/quick_ldap_backend.rst
index 1185608..b87bfe8 100644
--- a/doc/quick_ldap_backend.rst
+++ b/doc/quick_ldap_backend.rst
@@ -4,8 +4,8 @@
Quickstart to connect a LDAP Directory
======================================
-Authentic use the module django_auth_ldap to synchronize the Django user tables
-with an LDAP. For complex use case, we will refer you to the django_auth_ldap
+Authentic uses the module django_auth_ldap to synchronize the Django user tables
+with an LDAP. For complex use cases, we will refer you to the django_auth_ldap
documentation, see http://packages.python.org/django-auth-ldap/.
How to authenticate users against an LDAP server with anonymous binding ?
diff --git a/doc/saml2_slo.rst b/doc/saml2_slo.rst
index d7bb107..0b45f01 100644
--- a/doc/saml2_slo.rst
+++ b/doc/saml2_slo.rst
@@ -8,9 +8,8 @@ Explanation
===========
Authentic 2 implements the single logout profile of SAML2 (SLO). Single Logout is
-used to realise to close user session on distributed applications. The Single
-Logout is managed by the IdP. However, its exists many profiles all supported
-by Authentic 2:
+used to close user session on distributed applications. The Single Logout is
+managed by the IdP. However, Authentic 2 supports many profiles :
- SLO IdP initiated by SOAP
- SLO IdP initiated by Redirect
@@ -24,15 +23,15 @@ logout request can be received from:
- a service provider;
- a third identity provider.
-The configuration by policy allows to refuse SLO request coming from a SP or
-an IdP.
+The configuration by policy allows Authentic 2 to refuse SLO requests coming
+from a SP or an IdP.
**The the SLO request is accepted or comes from the user interface, at the end
of the process the local session on Authentic 2 will always be closed.**
During the process of treatment of the logout request, when the logout request
comes from a SP, if the local session was established through a third SAML2 IdP,
-Authentic 2 sends it a logout request (SLO proxying). Then, Authentic 2
+Authentic 2 sends it a logout request (SLO proxying) *au SP ? à l'IdP ?*. Then, Authentic 2
sends logout resuests to all service providers with an active session but the
requesting service provider.
@@ -40,8 +39,8 @@ During the process of treatment of the logout request, when the logout request
comes from an IdP, Authentic 2 sends logout resuests to all service providers
with an active session.
-The configuration by policy allows to select which IdP and SP to logout
-forwarding is done.
+The configuration by policy allows Authentic 2 to select IdPs and SPs to which
+logout forwarding is done.
**Note:** When a logout request comes from an IdP, the logout request is always
forwarded by soap to the service providers.
@@ -95,14 +94,15 @@ How activate the SLO?
=====================
No activation is required. However it is required a policy be found for the
-source or the desitnation of the logout request.
+source or the destination of the logout request.
The sp options policy or idp options policy that applies has parameters to
-indicate if the sp or idp which the policy applies is allowed to send and
+indicate if the sp or idp to which the policy applies is allowed to send and
receive logout requests.
-Then, create the 'default' options policy and check the both options
-*Accept to receive Single Logout requests* and *Forward Single Logout requests* as follows:
+Then, create the 'default' options policy and check both
+*Accept to receive Single Logout requests* and *Forward Single Logout requests*
+options as follows:
.. image:: pictures/slo_sp_options_activated.png
:width: 800 px
@@ -122,8 +122,9 @@ Authentic 2 send logout requests when a logout request is received.
If an options policy is not found for the source or the destination of the
logout request, the logout requests are not accepted nor forwarded.
-However it is not the right way. The best is to create the 'all' options
-policies with the options *Accept to receive Single Logout requests* and *Forward Single Logout requests* unchecked as follows:
+However it is not the right way to proceed. The best way is to create the 'all'
+options policies with the options *Accept to receive Single Logout requests* and
+*Forward Single Logout requests* unchecked as follows:
.. image:: pictures/slo_sp_options_deactivated.png
:width: 800 px
@@ -133,9 +134,9 @@ policies with the options *Accept to receive Single Logout requests* and *Forwar
:width: 800 px
:align: center
-Take care that the 'all' policies are authoritative. To desactivate the SLO
-but for particular providers, the best is to unchecked these options on the
-'default' options policies and apply regular policies to those particular
+Ensure that the 'all' policies are authoritative. To deactivate the SLO
+but for particular providers, the best is to uncheck these options on the
+'default' options policies and to apply regular policies to those particular
providers.
How refuse SLO from an identity provider?
@@ -150,19 +151,19 @@ How refuse SLO from a service provider?
Uncheck the option *Accept to receive Single Logout requests* of the policy that applies to that service
provider.
-How indicate identity providers to not forward logout request?
+How indicate identity providers not to forward logout request?
==============================================================
Uncheck the option *Forward Single Logout requests* of the policies that applies to the identity
-providers logout requests must not be forwarded.
+providers logout requests which must not be forwarded.
-How indicate service providers to not forward logout request?
+How indicate service providers not to forward logout request?
=============================================================
Uncheck the option *Forward Single Logout requests* of the policies that applies to the service
-providers logout requests must not be forwarded.
+providers logout requests which must not be forwarded.
-How do manage the SLO without closing the local session?
+How to manage the SLO without closing the local session?
========================================================
Not implemented.
diff --git a/doc/sync-metadata_script.rst b/doc/sync-metadata_script.rst
index 4a11887..6e7f302 100644
--- a/doc/sync-metadata_script.rst
+++ b/doc/sync-metadata_script.rst
@@ -1,7 +1,7 @@
.. _sync-metadata_script:
===========================================================================================================
-How to create/import and delete in bulk SAML2 identity and service providers with the sync-metadata script?
+How to create/import and delete in-bulk SAML2 identity and service providers with the sync-metadata script?
===========================================================================================================
This section explains hot to use the script sync-metadata.
@@ -9,8 +9,8 @@ This section explains hot to use the script sync-metadata.
Presentation
============
-This script allows to create/import and deleted in bulk SAML2 identity and
-service providers using standard SAML2 metadata files containing entity
+This script allows Authentic to create/import and delete in-bulk SAML2 identity
+and service providers using standard SAML2 metadata files containing entity
descriptors.
An example of such a file used in production is the global metadata file of
@@ -30,8 +30,8 @@ disabled.
Currently it only supports the LDAP and the LDAP attribute profile of SAML,
i.e. SAML attribute names must be LDAP attributes oid, the NameFormat must be
-URI, and an LDAP server must declared so that LDAP attributes can be resolved.
-Authentic2 contains a databases of the more common LDAP schemas to help the
+URI, and an LDAP server must be declared so that LDAP attributes can be resolved.
+Authentic2 contains a database of the more common LDAP schemas to help the
resolution of attributes OIDs.
Example of an AttributeConsumingService node::
@@ -101,11 +101,11 @@ Options
* idp
- Load only identity providers of the metadata file.
+ Load identity providers of the metadata file only.
* sp
- Load only service providers of the metadata file.
+ Load service providers of the metadata file only.
* source
@@ -155,7 +155,7 @@ Options
With no options, all providers are deleted.
- With the source option, only providers with the source name given are deleted.
+ With the source option, only providers with the given source name are deleted.
**This option can not be combined with options idp and sp.**
diff --git a/doc/translation.rst b/doc/translation.rst
index eae8657..3c33bc7 100644
--- a/doc/translation.rst
+++ b/doc/translation.rst
@@ -4,6 +4,6 @@
Compiling translations
======================
-Translations must compiled to be useful, to do that run the following command::
+Translations must be compiled to be useful, to do that run the following command::
./setup.py compile_translations
diff --git a/doc/upgrading.rst b/doc/upgrading.rst
index 3015537..2ae848e 100644
--- a/doc/upgrading.rst
+++ b/doc/upgrading.rst
@@ -11,7 +11,7 @@ Update using pip::
Authentic store all its data in a relational database as specified in its
settings.py or local_settings.py file. So in order to upgrade to a new version
of authentic you have to update your database schema using the
-migration command — you will need to have installed the dependency django-south,
+migration command — you will need to have the dependency django-south installed,
see the beginning of this README file.::
authentic2-ctl syncdb --migrate
View Git Blame Copy Permalink