entrouvert
/
paul-synchro
Archived
17
0
Fork 0
Code Issues Pull Requests Releases Activity

Remarques d'installation + ajout du patch

This commit is contained in:
Marillonnet Paul 2017-02-07 16:39:12 +01:00
parent 23337f6811
commit 24b125bc2c
2 changed files with 334 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc.md
View File

@ -376,12 +376,19 @@ Dans Authentic 2, cette politique de gestion consiste en un choix parmi trois po
Outil d'administration en ligne de commande
#### Installation
* AttributeError: 'module' object has no attribute 'PassThroughManager'
quand : utilisation de authentic2-ctl
pourquoi : incompatibilité sur les versions récentes du module django-model-utils
solution : rétrograder le module django-model-utils à une version <= 2.3
##### virtualenv Python
Le mécanisme de création d'environnements virtuels sous Python permet de faire cohabiter sur un même système des installations disparates. Par exemple, un même module Python peut être présent en différentes versions tant que ces versions se situent dans des environnements virtuels différents.
Les répertoires d'installation des modules Python dans le cadre d'un virtualenv sont seulement locaux à l'environnement créé.
##### Troubleshooting
-
##### Utilisation des *tenants* du SGBDR
@ -464,6 +471,7 @@ http://www.commentcamarche.net/contents/88-kerberos
https://www.ietf.org/rfc/rfc1510.txt
https://openclassrooms.com/courses/presentation-du-concept-d-annuaire-ldap
https://confluence.atlassian.com/kb/how-to-write-ldap-search-filters-792496933.html
https://virtualenv.pypa.io/en/stable/
## A lire
http://www.journaldunet.com/developpeur/xml/analyse/la-federation-d-identite-au-travers-de-saml.shtml
https://www.ietf.org/rfc/rfc4512.txt

326
doc_typos.patch Normal file
View File

@ -0,0 +1,326 @@
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