cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From radh...@apache.org
Subject git commit: updated refs/heads/master to 9dd4caf
Date Thu, 11 Jul 2013 05:36:44 GMT
Updated Branches:
  refs/heads/master 8bd1d2731 -> 9dd4caf80


CLOUDSTACK-1815


Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/9dd4caf8
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/9dd4caf8
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/9dd4caf8

Branch: refs/heads/master
Commit: 9dd4caf806967b8adbcc89ae262ce85425445272
Parents: 8bd1d27
Author: radhikap <radhika.puthiyetath@citrix.com>
Authored: Thu Jul 11 11:05:44 2013 +0530
Committer: radhikap <radhika.puthiyetath@citrix.com>
Committed: Thu Jul 11 11:06:11 2013 +0530

----------------------------------------------------------------------
 docs/en-US/password-storage-engine.xml | 38 ++++++++++++++++++++---------
 1 file changed, 26 insertions(+), 12 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cloudstack/blob/9dd4caf8/docs/en-US/password-storage-engine.xml
----------------------------------------------------------------------
diff --git a/docs/en-US/password-storage-engine.xml b/docs/en-US/password-storage-engine.xml
index b1d5340..0566105 100644
--- a/docs/en-US/password-storage-engine.xml
+++ b/docs/en-US/password-storage-engine.xml
@@ -21,21 +21,27 @@
 -->
 <section id="password-storage-engine">
   <title>Changing the Default Password Encryption</title>
-  <para>&PRODUCT; allows you to determine the default encoding and authentication
mechanism for
-    admin and user logins. Plain text user authenticator has been changed to do a simple
string
-    comparison between retrieved and supplied login passwords instead of comparing the retrieved
md5
-    hash of the stored password against the supplied md5 hash of the password because clients
no
-    longer hash the password. The following method determines what encoding scheme is used
to encode
-    the password supplied during user creation or modification.</para>
+  <para>Passwords are encoded when creating or updating users. &PRODUCT; allows
you to determine the
+    default encoding and authentication mechanism for admin and user logins. A new configurable
list
+    called <code>UserPasswordEncoders</code> to allow you to separately configure
the order of
+    preference for encoding and authentication schemes. </para>
+  <para>Additionally, plain text user authenticator has been changed to use SHA256SALT
as the
+    default encoding algorithm because it is more secure compared to MD5 hashing. It does
a simple
+    string comparison between retrieved and supplied login passwords instead of comparing
the
+    retrieved md5 hash of the stored password against the supplied md5 hash of the password
because
+    clients no longer hash the password. The following method determines what encoding scheme
is
+    used to encode the password supplied during user creation or modification. </para>
   <para>When a new user is created, the user password is encoded by using the first
valid encoder
     loaded as per the sequence specified in the <code>UserPasswordEncoders</code>
property in the
       <filename>ComponentContext.xml</filename> or <filename>nonossComponentContext.xml</filename>
     files. The order of authentication schemes is determined by the <code>UserAuthenticators</code>
-    property in the same files. The administrator can change the ordering of both these properties
-    as preferred. When a new authenticator or encoder is added, you can add them to this
list. While
-    doing so, ensure that the new authenticator or encoder is specified as a bean in both
these
-    files if they are required for both oss and non-oss components. The two properties are
listed
-    below:</para>
+    property in the same files. When a new authenticator or encoder is added, you can add
them to
+    this list. While doing so, ensure that the new authenticator or encoder is specified
as a bean
+    in both these files. The administrator can change the ordering of both these properties
as
+    preferred to change the order of schemes. Modify the following list properties available
in
+      <filename>client/tomcatconf/nonossComponentContext.xml.in</filename> or
+      <filename>client/tomcatconf/componentContext.xml.in</filename> as applicable,
to the desired
+    order:</para>
   <programlisting>&lt;property name="UserAuthenticators"&gt;
          &lt;list&gt;
             &lt;ref bean="SHA256SaltedUserAuthenticator"/&gt;
@@ -50,5 +56,13 @@
              &lt;ref bean="MD5UserAuthenticator"/&gt;
              &lt;ref bean="LDAPUserAuthenticator"/&gt;
             &lt;ref bean="PlainTextUserAuthenticator"/&gt;
-         &lt;/list&gt;</programlisting>
+            &lt;/list&gt;</programlisting>
+  <para>In the above default ordering, SHA256Salt is used first for
+      <code>UserPasswordEncoders</code>. If the module is found and encoding
returns a valid value,
+    the encoded password is stored in the user table's password column. If it fails for any
reason,
+    the MD5UserAuthenticator will be tried next, and the order continues. For
+      <code>UserAuthenticators</code>, SHA256Salt authentication is tried first.
If it succeeds, the
+    user is logged into the Management server. If it fails, MD5 is tried next, and attempts
+    continues until any of them succeeds and the user logs in . If none of them works,  the
user is
+    returned an invalid credential message. </para>
 </section>


Mime
View raw message