1.基本的な概念
1.1認定とは
モバイルインターネットの時代では、誰もが毎日スマートフォンを磨いています。よく使用されるソフトウェアは、WeChat、Alipay、Toutiaoなどです。以下では、WeChatを例にして、認証に関連する基本的な概念を説明します。WeChatを初めて使用する前に、WeChatユーザーとして登録してから、次のように入力します。アカウントとパスワードはWeChatへのログインに使用でき、ログインするためのアカウントとパスワードを入力するプロセスは認証です。
なぜシステムを認定する必要があるのですか？
認証はシステムのプライバシーデータとリソースを保護するためのものであり、ユーザーのIDはシステムのリソースにのみアクセスできます。
認証：ユーザー認証は、ユーザーのIDが正当であるかどうかを判断するプロセスです。ユーザーがシステムリソースにアクセスすると、システムはユーザーのID情報の検証を必要とします。正当なIDへのアクセスは継続でき、不正なアクセスは拒否されます。一般的なユーザーID認証方法は、ユーザーパスワードです。 、QRコードログイン、携帯電話SMSログイン、指紋認証、その他の方法。
1.2セッションとは
ユーザーが認証された後、ユーザーがすべての認証を実行できないようにするために、ユーザーの情報はセッションで保証されます。セッションは、現在のユーザーログインステータスを維持するためにシステムによって提供されるメカニズムです。一般的な方法には、セッションベースとトークンベースがあります。
セッションベースの認証方法は次のとおりです。
そのインタラクティブなプロセスは、ユーザー認証が成功した後、サーバー側で生成されたユーザー関連データがセッション（現在のセッション）に保存され、セッションIDがcookieに格納されてクライアントに送信されるため、ユーザークライアントはsession_idで確認できますサーバー上にユーザーの正当な検証を完了するためのセッションデータがあるかどうか。ユーザーがシステムを終了するか、セッションが期限切れになり破棄されると、クライアントのsession_idは無効になります
次に示すように、トークンメソッドに基づいています。
そのインタラクティブなプロセスでは、ユーザー認証が成功した後、サーバーがトークンを生成してクライアントに送信します。クライアントはそれをCookieやlocalstorge（現在はブラウザー内）などのストレージに配置し、各リクエストでトークンを取得できます。トークンを受け取った後、ユーザーのIDを確認できます。トークンベースの認証はサーバーに記録されない場合があります。
1.2認可とは
WeChatを例にとると、WeChatログインが成功すると、ユーザーは赤い封筒の送信、友達の輪の送信、友達の追加などのWeChat機能を使用できます。銀行カードを持たないユーザーは赤い封筒を送信できません。銀行カードを持っているユーザーは赤い封筒、赤い封筒を送信する機能、友達の輪を送信する機能は、WeChat、つまり機能的なリソースです。ユーザーは、赤い封筒を送信する権限を持っている場合にのみ、赤い封筒の機能を使用でき、友達のサークルのみを使用できます。機能は、ユーザーの権限に従ってユーザーのリソースの使用を制御するプロセスが許可です。
なぜ承認が必要なのですか？
認証はユーザーの正当性を保証することであり、承認はプライバシーデータをより細かく分割することです。承認は認証が通過した後に行われ、さまざまなユーザーがさまざまなリソースにアクセスできます。
承認：承認は、ユーザーの権限に従ってリソースへのユーザーのアクセスを制御するユーザー認証のプロセスです。リソースアクセスのあるリソースへの通常のアクセスは拒否され、権限なしでアクセスは拒否されます。
1.3承認済みデータモデル
承認を実行する方法、つまりリソースへのユーザーアクセスを制御するには、まず承認に関連するデータモデルを学習する必要があります
承認は、以下を含め、どのように（どの）を操作するかとして簡単に理解できます。
who：サブジェクト（subject）、サブジェクトは一般にユーザーを指し、プログラムの場合もあり、システム内のリソースにアクセスする必要があります。
内容：システムメニュー、ページ、ボタン、コードメソッド、システム製品情報、システム注文情報などのリソース（リソース）、システムメニュー、ページ、ボタン、コードメソッドはすべてシステム関数リソースです。通常、Webページの各機能について、 URLに対応して、システム製品情報、システム注文情報は物理リソース（データリソース）に属します。物理リソースはリソースタイプとリソースインスタンスで構成されます。例えば、製品情報はリソースタイプで、製品番号が0001の製品はリソースインスタンスです。
方法：権限、権限（premission）、リソースを操作するユーザーの権限を規定します。権限は、ユーザークエリ権限、ユーザー追加権限、特定のコードメソッドの呼び出し権限、ユーザー番号001の変更権限など、リソースを離れる意味がありません。ちょっと待って、権限を通じて、ユーザーがどのリソースに対してどの操作許可を持っているかを知ることができます。
サブジェクト、リソース、権限の関係は次のとおりです。
サブジェクト、リソース、および権限に関連するデータモデルは次のとおりです。
件名（ユーザーID、アカウント番号、パスワードなど）
リソース（リソースID、リソース名、アクセスアドレスなど）
権限（権限ID、権限ID、権限名、リソースIDなど）
ロール（ロールID、ロール名、...）
役割と権限の関係（役割ID、権限IDなど）
サブジェクト（ユーザー）とロール（ユーザーID、ロールID）の関係
サブジェクト（ユーザー）、リソース、権限の関係は以下のとおりです
通常、エンタープライズ開発では、リソーステーブルと権限テーブルは、次のように1つの権限テーブルに結合されます。
リソース。（リソースID、リソース名、アクセスアドレス...）
権限（権限ID、権限ID、権限名、リソースID ^）
にマージ：
権限（権限ID、権限ID、権限名、リソース名、リソースアクセスアドレス...）
変更されたデータモデル間の関係を以下に示します。
1.4RBAC
認可を達成する方法、業界は通常rbacに基づいて認可を実装します
1.4.1ロールベースのアクセス制御
RBACロールベースのアクセス制御（ロールベースのアクセス制御）は、ロールによって承認されます。たとえば、プリンシパルのロールはゼネラルマネージャーであり、ビジネスオペレーションレポートのクエリ、従業員の給与情報のクエリなどを実行できます。アクセスコントロールプロセスは次のとおりです。
上の図の判定ロジックによれば、認証コードは次のように表すことができます。
if(“主体”.hasRole("总经理角色id"))
{
查询工资
}上の図で給与を照会するために必要な役割が部長と部長である場合、判断ロジックを「ユーザーの役割が部長であるか部長であるかを決定する」に変更する必要があり、変更後のコードは次のとおりです。
if(“主体”.hasRole("总经理角色id") || "主体".hasrole("部门经理"))
{
查询工资
}上記の例によれば、ロールのアクセス許可を変更する必要がある場合、関連する承認のコードを変更する必要があり、システムのスケーラビリティが低いことがわかります。
1.4.2リソースベースのアクセス制御
RBACリソースベースのアクセス制御（リソースベースのアクセス制御）は、リソース（または権限）に従って承認するためのものです。たとえば、ユーザーは、従業員の給与情報をクエリするための給与クエリ権限を持っている必要があります。アクセス制御は次のとおりです。
上図の判断によると、認証コードは次のように表すことができます。
if(主体.hasrole(“总经理角色id”)){
查询工资
}利点は、システムが給与を照会するための承認フラグを定義することです。つまり、ゼネラルマネージャーや部門マネージャーが給与の変更を照会するために必要な角度のパラジウムは、承認コードを変更する必要がないため、システムに強力なスケーラビリティがあります。
