directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From smckin...@apache.org
Subject svn commit: r1780072 - in /directory/site/trunk/content/api/user-guide: 5-ldap-security.mdtext 5.1-ldaps.mdtext
Date Tue, 24 Jan 2017 13:03:26 GMT
Author: smckinney
Date: Tue Jan 24 13:03:26 2017
New Revision: 1780072

URL: http://svn.apache.org/viewvc?rev=1780072&view=rev
Log:
ldaps

Modified:
    directory/site/trunk/content/api/user-guide/5-ldap-security.mdtext
    directory/site/trunk/content/api/user-guide/5.1-ldaps.mdtext

Modified: directory/site/trunk/content/api/user-guide/5-ldap-security.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/api/user-guide/5-ldap-security.mdtext?rev=1780072&r1=1780071&r2=1780072&view=diff
==============================================================================
--- directory/site/trunk/content/api/user-guide/5-ldap-security.mdtext (original)
+++ directory/site/trunk/content/api/user-guide/5-ldap-security.mdtext Tue Jan 24 13:03:26
2017
@@ -26,10 +26,7 @@ Notice: Licensed to the Apache Software
 
 **LDAP** databases store critical information that must be kept secure.  The **Apache LDAP
API** can access the data securely while in flight but can't protect it while at rest -- that's
for the database system itself to do.
 
-Generally speaking when it comes to securing a system, we are addressing the three **A**s:
-* Authentication
-* Authorization
-* Auditing
+Generally speaking when it comes to securing a system, we are addressing the three **A**s:
Authentication, Authorization and Auditing.
 
 The only aspect we will focus on is the **Authentication** part, because the **LDAP** protocol
does not address the other two, when it comes to an **API**. We will talk about authorization
a little bit in the last chapter.
 

Modified: directory/site/trunk/content/api/user-guide/5.1-ldaps.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/api/user-guide/5.1-ldaps.mdtext?rev=1780072&r1=1780071&r2=1780072&view=diff
==============================================================================
--- directory/site/trunk/content/api/user-guide/5.1-ldaps.mdtext (original)
+++ directory/site/trunk/content/api/user-guide/5.1-ldaps.mdtext Tue Jan 24 13:03:26 2017
@@ -31,13 +31,13 @@ That being said, many servers accept **L
 
 ## How does it work ?
 
-The **SSL** protocol ensures that data are transmitted encrypted, and guarantees that the
data being received are valid. Nobody can capture those data and read them, assuming the ciphers
being used are strong enough.
+The **SSL** protocol ensures that data is transmitted encrypted, and guarantees that the
data received is valid. Noone can capture this data and read it, assuming the ciphers used
are of sufficient strength.
 
-With **SSL**, a dialog between the client and the server occurs, and when both part agree
on the cipher to use, then all subsequent data is encrypted. This dialog may include a mutual
validation. 
+With **SSL**, a dialog between the client and the server occurs, and when both agree on the
particular cipher to use, then all subsequent data is encrypted. This dialog may include a
mutual validation of their X.509 certificates. 
 
 ## Protocols
 
-There are many version that can be used, but the idea is to use tha most recent one, if the
server supports it. In any case, as we depend on **Java**, we are also limited by the supported
version on the client side. Here are all the existing version, and their status :
+There are many version that can be used, but the idea is to use the most recent one, if the
server supports it. In any case, as we depend on **Java**, we are also limited by the supported
version on the client side. Here are all of the existing versions, and their statuses:
 
 | SSLversion | Java 7 Client | Java 7 Server | Java 8 Client | Java 8 Server |
 |---|---|---|---|---|
@@ -47,15 +47,15 @@ There are many version that can be used,
 | 3.2 (aka TLSv1.1 | Disabled | **Enabled** | **Enabled** | **Enabled** |
 | 3.3 (aka TLSv1.2) | Disabled | **Enabled** | **Enabled** | **Enabled** |
 
-(_Disabled_ mean it's not active by default, and must be activated explicitely).
+(_Disabled_ means it's not active by default, and so must be activated explicitly).
 
-The default is for Java to pick the one that fits, assuming that it will always start with
the newest version (**TLSv1.2**).
+The default is Java will choose the best fit, assuming that it always starts with the newest
version (**TLSv1.2**).
 
-Still, you can enforce the version if needed.
+Still, you can enforce the version used -- if needed.
 
 ## A quick primer
 
-Here is all what you need to get a **LDAPS** connection established with a server :
+Here is all that is needed to get **LDAPS** connections established with a server :
 
         try ( LdapConnection connection = new LdapNetworkConnection( "server-name", 636,
true ) )
         {
@@ -64,9 +64,9 @@ Here is all what you need to get a **LDA
             assertTrue( connection.isAuthenticated() );
         }
 
-This is as simple as that ! The **636* port is the default **LDAPS** port for standard **LDAP**
servers, when running as **root**, and for **ApacheDS** you will have to pick **10636**. The
**true** flag is set to secure the connection. You don't need to close the connection, it
will be done automatically when exiting the try{...} block.
+It's as simple as that! The **636** port is the default **LDAPS** port for standard **LDAP**
servers, when running as **root**, and for **ApacheDS** you must pick **10636**. The **true**
flag is set to secure the connection. You don't need to close the connection, it will be done
automatically upon exiting the try{...} block.
 
-By default, the selected protocol is **TLS**, and we wont verify the server's certificate.
+By default, the selected protocol is **TLS**, and the server's certificate is not verified.
 
 ## A more sophisticated sample
 
@@ -81,20 +81,20 @@ It's possible to have more control on th
             assertTrue( connection.isAuthenticated() );
         }
 
-Here, we use the _NoVerificationTrustManager_ class, but you can define your own implementation.
The **Fortress** project is using [this class](https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/ldap/LdapClientTrustStoreManager.java).
+Here, we use the _NoVerificationTrustManager_ class, but you may define your own implementation
of it. The **Fortress** project uses [this class](https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/ldap/LdapClientTrustStoreManager.java).
 
 ## Using a configuration
 
-One step further : you can define a dediated configuration that is passed to the constructor.
Many parameters can be defined :
+One step further : you can define a dedicated configuration that is passed to the constructor.
Many parameters can be defined:
 
-* the enabled cipher suites : a list of ciphers that may be used (like "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
etc)
-* the enabled protocols : a list of protocals that may be used ( "SSLv3", "TLS", "TLSv1",
"TLSv1.1", "TLSv1.2")
+* the enabled cipher suites: a list of ciphers that may be used (like "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
etc)
+* the enabled protocols: a list of protocals that may be used ( "SSLv3", "TLS", "TLSv1",
"TLSv1.1", "TLSv1.2")
 * the KeyManager instances
 * the SecureRandom instance
-* the SSL protocol to use : one of the enabled protocols
+* the SSL protocol to use: one of the enabled protocols
 * the TrustManager instances
 
-All those parameters are configured using the _LdapConnectionConfig_ class :
+All these parameters are configured using the _LdapConnectionConfig_ class :
 
         LdapConnectionConfig sslConfig = new LdapConnectionConfig();
         sslConfig.setLdapHost( Network.LOOPBACK_HOSTNAME );
@@ -112,14 +112,11 @@ All those parameters are configured usin
 
 ## LDAPS or startTLS ?
 
-The important point to understand with **LDAPS** is that every request being exchanged between
the client and the server will be encrypted, because the underlying transport is encrypted.
That means you can't start communicating with the LDAP server before the connection is secured.
+The important point to understand with **LDAPS** is that every request being exchanged between
the client and the server is encrypted, because its underlying transport is encrypted. That
means you can't start communicating with the LDAP server before the connection is secured.
 
-It has a few drawbacks :
+It has a few drawbacks:
 - first of all, it has an added CPU cost, as everything has to be encrypted and decrypted.
 - second, it requires a dedicated port, thus some specific routing rules (firewall, load
balancers, etc)
-- third, it's a all of nothing choice. If you want to come back to a non-encrypted communication,
you need to use another connection.
-
-This is the reason why the **startTLS** extended operation should be used.
-
-
+- third, it's a all of nothing choice. If you want to return to a non-encrypted communication,
you must use another connection.
 
+This is the why the **startTLS** extended operation should be used instead.



Mime
View raw message