327 lines
15 KiB
Diff
327 lines
15 KiB
Diff
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
|