[doc] Use name Authentic 2

administration_with_policies.rst

@@ -1,11 +1,11 @@
 .. _administration_with_policies:
 
-=========================================================
+==========================================================
-How global policies are used in Authentic2 administration
+How global policies are used in Authentic 2 administration
-=========================================================
+==========================================================
 
 The policy management with global policies is nearly used for any kind of
-policy in Authentic2.
+policy in Authentic 2.
 
 For each kind of these policies, the system takes in account two special
 global policies named 'Default' and 'All':

attribute_management.rst

@@ -1,25 +1,25 @@
 .. _attribute_management:
 
-==================================
+===================================
-Attribute Management in Authentic2
+Attribute Management in Authentic 2
-==================================
+===================================
 
 Summary
 =======
 
 Attribute management currently allows to configure attribute policies
 associated with SAML2 service providers to define attributes that are
-pushed in SAML2 successful authentication response delivered by Authentic2.
+pushed in SAML2 successful authentication response delivered by Authentic 2.
 
 User attributes can be taken from LDAP directories, the user Django
-profile or taken from the user Django session if Authentic2 is also configured
+profile or taken from the user Django session if Authentic 2 is also configured
 as a SAML2 service provider.
 
-Indeed, when Authentic2 acts also as a SAML2 service provider,
+Indeed, when Authentic 2 acts also as a SAML2 service provider,
 attributes contained in the SAML2 assertion received from third IdP are put in
 the user session.
 
-Attributes can thus be proxyfied during SSO with Authentic2
+Attributes can thus be proxyfied during SSO with Authentic 2
 configured as a SAML2 proxy.
 
 *If there is no attribute policy associate with a service provider, no
@@ -111,11 +111,11 @@ ___________________________________________________
 
 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,
-Authentic2 learn the user DN. Nothing has to be done from this point of view.
+Authentic 2 learn 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
-indicate to Authentic2 what is the user DN in the directory. For this, a
+indicate to Authentic 2 what is the user DN in the directory. For this, a
 user alias in source is created for the user:
 
 1. Go to http[s]://your.domain.com/admin/attribute_aggregator/useraliasinsource/add/
@@ -291,7 +291,7 @@ ________________________________________________________________________________
 
 The system needs to 'recognise the attributes' to perform the mapping.
 For this, you need to indicate the namespace of attributes received per source
-if the namespace is not the one of Authentic2 (X500/LDAP and extensions edu*
+if the namespace is not the one of Authentic 2 (X500/LDAP and extensions edu*
 and supann).
 
 In other words if the source provides attributes in a different namespace, you
@@ -322,7 +322,7 @@ ________________________________________________________________________________
 The system needs to 'recognise the attributes' to filter the attributes
 according to a list of attributes.
 For this, you need to indicate the namespace of attributes received per source
-if the namespace is not the one of Authentic2 (X500/LDAP and extensions edu*
+if the namespace is not the one of Authentic 2 (X500/LDAP and extensions edu*
 and supann).
 
 In other words if the source provides attributes in a different namespace, you

attribute_management_explained.rst

@@ -235,13 +235,13 @@ exists, obsolete data are removed at loading.
 When authentic 2 deals with attributes and needs mapping?
 ---------------------------------------------------------
 
-Authentic2 behaves as an attribute provider:
+Authentic 2 behaves as an attribute provider:
 * At the SSO login
 * When an attribute request is received
 
 Authentic requests (e.g. by soap) are not yet supported.
 
-When Authentic2 behaves as an attribute provider at SSO login
+When Authentic 2 behaves as an attribute provider at SSO login
 _____________________________________________________________
 
 At a SSO request, just before responding to the service provider, the saml2
@@ -433,6 +433,6 @@ This is currently implemented only for the SAML2 service provider module of
 authentic2. Authsaml2, the SP module, parse the assertion and put the
 attributes in the session.
 
-Then, Authentic2 can be used as a SAML2 proxy forwarding attributes in
+Then, Authentic 2 can be used as a SAML2 proxy forwarding attributes in
 assertion, eventually doing a namespace mapping. For this, the option
 forward attributes in sesion must be set (by default False).

auth_pam.rst

@@ -1,8 +1,8 @@
 .. _auth_pam:
 
-=====================================
+======================================
-Authentication on Authentic2 with PAM
+Authentication on Authentic 2 with PAM
-=====================================
+======================================
 
 This module is copied from https://bitbucket.org/wnielson/django-pam/ by Weston
 Nielson and the pam ctype module by Chris Atlee http://atlee.ca/software/pam/.

config_cas_idp.rst

@@ -1,5 +1,5 @@
 .. _config_cas_idp:
 
-====================================
+=====================================
-Configure Authentic2 as a CAS client
+Configure Authentic 2 as a CAS client
-====================================
+=====================================

config_cas_sp.rst

@@ -1,11 +1,11 @@
 .. _config_cas_sp:
 
-====================================
+=====================================
-Configure Authentic2 as a CAS server
+Configure Authentic 2 as a CAS server
-====================================
+=====================================
 
-How to use Authentic2 as a CAS 1.0 or CAS 2.0 identity provider ?
+How to use Authentic 2 as a CAS 1.0 or CAS 2.0 identity provider ?
------------------------------------------------------------------
+------------------------------------------------------------------
 
 1. Activate CAS IdP support in settings.py::
 

config_saml2_idp.rst

@@ -1,29 +1,29 @@
 .. _config_saml2_idp:
 
-=================================================================
+==================================================================
-Configure Authentic2 as a SAML2 service provider or a SAML2 proxy
+Configure Authentic 2 as a SAML2 service provider or a SAML2 proxy
-=================================================================
+==================================================================
 
-**The configuration to make Authentic2 a SAML2 service provider or a SAML2
+**The configuration to make Authentic 2 a SAML2 service provider or a SAML2
-proxy is the same. The difference comes from that Authentic2 is may be
+proxy is the same. The difference comes from that Authentic 2 is may be
 configured or not as a SAML2 identity provider.**
 
 How do I authenticate against a third SAML2 identity provider?
 ==============================================================
 
-1. Declare Authentic2 as a SAML2 service provider on your SAML2 identity provider using the SAML2 service provider metadata of Authentic2.
+1. Declare Authentic 2 as a SAML2 service provider on your SAML2 identity provider using the SAML2 service provider metadata of Authentic 2.
 
 Go to http[s]://your.domain.com/authsaml2/metadata
 
-2. Add and configure a SAML2 identity provider entry in Authentic2 using the metadata of the identity provider.
+2. Add and configure a SAML2 identity provider entry in Authentic 2 using the metadata of the identity provider.
 
-How do I add and configure a SAML2 identity provider in Authentic2?
+How do I add and configure a SAML2 identity provider in Authentic 2?
-===================================================================
+====================================================================
 
 You first need to create a SAML2 identity provider entry with the SAML2
 metadata of the identity provider. Then, you configure it.
 
-If your identity provider is Authentic2, the metadata are available at:
+If your identity provider is Authentic 2, the metadata are available at:
 
     http[s]://your.domain.com/idp/saml2/metadata
 

config_saml2_sp.rst

@@ -4,22 +4,22 @@
 Configure SAML 2.0 service providers
 ====================================
 
-How do I authenticate against Authentic2 with a SAML2 service provider?
+How do I authenticate against Authentic 2 with a SAML2 service provider?
 =======================================================================
 
-1. Declare Authentic2 as a SAML2 identity provider on your SAML2 service provider using the SAML2 identity provider metadata of Authentic2.
+1. Declare Authentic 2 as a SAML2 identity provider on your SAML2 service provider using the SAML2 identity provider metadata of Authentic 2.
 
 Go to http[s]://your.domain.com/idp/saml2/metadata
 
-2. Add and configure a SAML2 service provider in Authentic2 using the metadata of the service provider.
+2. Add and configure a SAML2 service provider in Authentic 2 using the metadata of the service provider.
 
-How do I add and configure a SAML2 service provider in Authentic2?
+How do I add and configure a SAML2 service provider in Authentic 2?
 ==================================================================
 
 You first need to create a new SAML2 service provider entry. This requires the
 SAML2 metadata of the service provider.
 
-If your service provider is Authentic2, the metadata are available at:
+If your service provider is Authentic 2, the metadata are available at:
 
     http[s]://your.domain.com/authsaml2/metadata
 

consent_management.rst

@@ -1,8 +1,8 @@
 .. _consent_management:
 
-================================
+=================================
-Consent Management in Authentic2
+Consent Management in Authentic 2
-================================
+=================================
 
 What is the SAML2 federation consent aka account linking consent?
 =================================================================

index.rst

@@ -1,20 +1,20 @@
-.. Authentic2 documentation master file, created by
+.. Authentic 2 documentation master file, created by
    sphinx-quickstart on Thu Oct 13 09:53:03 2011.
    You can adapt this file completely to your liking, but it should at least
    contain the root `toctree` directive.
 
-==========================
+===========================
-Authentic2's documentation
+Authentic 2's documentation
-==========================
+===========================
 
-Authentic2 is a versatile identity provider addressing a broad
+Authentic 2 is a versatile identity provider addressing a broad
 range of needs, from simple to advanced setups, around web authentication,
 attribute sharing and namespace mapping.
 
-Authentic2 supports many protocols and standards, including SAML2, CAS, OpenID,
+Authentic 2 supports many protocols and standards, including SAML2, CAS, OpenID,
 LDAP, X509, OATH, and can bridge between them.
 
-Authentic2 is under the GNU AGPL version 3 licence.
+Authentic 2 is under the GNU AGPL version 3 licence.
 
 It has support for SAMLv2 thanks to `Lasso <http://lasso.entrouvert.org>`_,
 a free (GNU GPL) implementation of the Liberty Alliance and OASIS
@@ -22,9 +22,9 @@ specifications of SAML2, ID-FF1.2 and ID-WSF2.
 
 The Documentation is under the licence Creative Commons `CC BY-SA 2.0 <http://creativecommons.org/licenses/by-sa/2.0/>`_.
 
-- `Authentic2 project site <http://dev.entrouvert.org/projects/authentic>`_
+- `Authentic 2 project site <http://dev.entrouvert.org/projects/authentic>`_
-- `Authentic2 roadmap <http://dev.entrouvert.org/projects/authentic/roadmap>`_
+- `Authentic 2 roadmap <http://dev.entrouvert.org/projects/authentic/roadmap>`_
-- `Documentation in PDF <https://dev.entrouvert.org/attachments/158/Authentic2.pdf>`_
+- `Documentation in PDF <https://dev.entrouvert.org/attachments/158/Authentic 2.pdf>`_
 
 Documentation content
 =====================
@@ -69,7 +69,7 @@ Documentation content
 Copyright
 =========
 
-Authentic and Authentic2 are copyrighted by Entr'ouvert and are licensed
+Authentic and Authentic 2 are copyrighted by Entr'ouvert and are licensed
 through the GNU AFFERO GENERAL PUBLIC LICENSE, version 3 or later. A copy of
 the whole license text is available in the COPYING file.
 

saml2_slo.rst

@@ -1,23 +1,23 @@
 .. _saml2_slo:
 
-======================================
+=======================================
-Single Logout Management in Authentic2
+Single Logout Management in Authentic 2
-======================================
+=======================================
 
 Explanation
 ===========
 
-Authentic2 implements the single logout profile of SAML2 (SLO). Single Logout is
+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 Authentic2:
+by Authentic 2:
 
 - SLO IdP initiated by SOAP
 - SLO IdP initiated by Redirect
 - SLO SP initiated by SOAP
 - SLO SP initiated by Redirect
 
-Then, Authentic2 acting as an IdP but also as a SP (for proxying), a
+Then, Authentic 2 acting as an IdP but also as a SP (for proxying), a
 logout request can be received from:
 
 - the logout button on the user interface;
@@ -28,16 +28,16 @@ The configuration by policy allows to refuse SLO request 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 Authentic2 will always be closed.**
+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,
-Authentic2 sends it a logout request (SLO proxying). Then, Authentic2
+Authentic 2 sends it a logout request (SLO proxying). Then, Authentic 2
 sends logout resuests to all service providers with an active session but the
 requesting service provider.
 
 During the process of treatment of the logout request, when the logout request
-comes from an IdP, Authentic2 sends logout resuests to all service providers
+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
@@ -117,7 +117,7 @@ How deactivate the SLO?
 =======================
 
 There is no real deactivation process. When it is possible and authorized,
-Authentic2 send logout requests when a logout request is received.
+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.

where_metadata.rst

@@ -1,18 +1,18 @@
 .. _where_metadata:
 
-==============================================
+===============================================
-Where do I find the Authentic2 SAML2 metadata?
+Where do I find the Authentic 2 SAML2 metadata?
-==============================================
+===============================================
 
 The SAML2 metadata are automatically generated.
 
-**Authentic2 will infer from environment variables the host and port to
+**Authentic 2 will infer from environment variables the host and port to
 generate the URLs contained in the medatada.**
 
-The metadata of Authentic2 SAML2 identity provider are available at:
+The metadata of Authentic 2 SAML2 identity provider are available at:
 
     http[s]://your.domain.com/idp/saml2/metadata
 
-The metadata of Authentic2 SAML2 service provider are available at:
+The metadata of Authentic 2 SAML2 service provider are available at:
 
     http[s]://your.domain.com/authsaml2/metadata