authentication - 認証/認可スキーマ

Question

認証/承認スキーマのベスト プラクティス データ モデルはありますか?

Answer 1

ロールから特権へのマッピングで構成されるデータモデルはかなり柔軟性があり、ほとんどの目的に適しています。

次に、ユーザーに役割を割り当てます（概念は基本的にグループの役割と同じです）...ユーザーは複数の役割を持つ場合があり、その役割によってユーザーが持つ特権が定義されます。

コードでは、ユーザーが機能を実行するために必要な特権を持っていることを（ロールを介して）チェックします。

認証は別個のものであり、ユーザーが何ができるかではなく、ユーザーが誰であるかを検証するだけです。通常、この分離を維持する必要があります（ただし、ユーザーが誰であるかではなく、ユーザーができることだけを気にするように設計されたスキームがあります）。

設計では、アクセス制御システムをマトリックス（特権に対する役割）として視覚化できます。

また、「パスワードを保存しない」という回答についても詳しく説明します。独自の認証スキームを設計しないでください。あなたはおそらくそれを間違えるでしょう。実績のあるものを再利用してください。

Answer 2

1番大事なのは

パスワードを保存しない

パスワードのダイジェストを保存します。RFC 2069とこのウィキペディアの記事を参照してください。誰かが認証を試みると、入力のダイジェストと必要なダイジェストを比較して、資格情報が一致するかどうかを確認します。

Answer 3

S.Lottの「パスワードを保存しない：パスワードのダイジェストを保存する」という回答に警告を追加します。

本当に攻撃から保護したい場合は、ダイジェストにソルトを使用してください。それがMD5のようなよく知られたアルゴリズムであり、誰かがハッシュ出力を取得できる場合、自分のCPU時間で、可能なパスワードをすばやくチェックし、一致するものが見つかった場合はパスワードを取得します。ソルトを追加すると、この種の攻撃を防ぐことができます（ウィキペディアの記事を参照）。

OpenIDは認証を処理するためのかなり簡単な手段であるため、試してみるとよいでしょう。有名なサイト（OpenIDプロバイダー）が認証を処理し、IDXを持つ人物が適切に認証されたことを暗号で表明します。次に、Xが何を実行できるかについての承認を処理する必要があります。信頼するIDプロバイダーはいつでも制限できます（たとえば、Yahoo、AOL、Bloggerは信頼できますが、技術的には誰でも独自のIDプロバイダーサーバーをホストできるため、ランダムなサイトは信頼できません）。