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