[best practice] security.rst の序文を修正

Author: kseta

best_practices/security.rst

@@ -2,29 +2,27 @@
 Security
 ========
 
-認証とファイアウォール (i.e. Getting thw User's Credentials)
+認証とファイアウォール (i.e. ユーザの権限情報を取得する)
 Authentication and Firewalls (i.e. Getting the User's Credentials)
 ------------------------------------------------------------------
 
-
-思いのままの手段と様々なデータソースからユーザ情報をロードしユーザの認証を Symfony に
-設定することができます。
-とても難解なテーマですが、`Security Cookbook Section`_ には
-これについてのたくさんの情報が記載されています。
-
-``security.yml`` の初期設定の ``firewalls`` キーの下に認証を設定します。
-
+ユーザが期待する様々なメソッドを使い様々なデータソースからユーザ情報をロードするように
+Symfony に認証を設定することができます。
+セキュリティはとても難解なテーマですが、`Security Cookbook Section`_ に
+多くの情報が記載されています。
 
 You can configure Symfony to authenticate your users using any method you
 want and to load user information from any source. This is a complex topic,
 but the `Security Cookbook Section`_ has a lot of information about this.
 
+まずは要件にこだわらず ``security.yml`` の初期設定の ``firewalls`` キーの下に認証を設定してみます。
+
 Regardless of your needs, authentication is configured in ``security.yml``,
 primarily under the ``firewalls`` key.
 
 .. best-practice::
 
-    正規に許可された２つのことなる認証システムとユーザが無い限り
+    正規に許可された２つの異なる認証システムとユーザが無い限り
     (e.g. メインとなるサイトと API のためだけのトークンシステムのためのログイン)、
     ``anonymous`` のキーを有効にしたたったひとつのファイヤーウォールを設けることを推奨します。
 
@@ -36,7 +34,7 @@ primarily under the ``firewalls`` key.
 
 ほとんどのアプリケーションで認証システムとユーザのセットはひとつしかありません。
 このため、ひとつのファイヤーウォールの設定だけで事足ります。
-もちろん サイトの API と WEB を分けたいときなどの例外もありますが、
+もちろん、サイトの API と WEB を分けたい場合などの例外もありますが、
 シンプルに考えていくことが重要です。
 
 Most applications only have one authentication system and one set of users.