ログインを超えて: ZITADEL を使用したきめ細かい認証の実装

導入

ゼロトラストの考え方に移行するにつれて、従来の RBAC システムのような粗粒度のセキュリティ対策の限界が明らかになります。議論されないことが多いゼロトラストへの移行の重要な部分は、粗粒度のセキュリティから粒度の細かいセキュリティへの移行です。

詳細な認可は、ユーザーの役割、アクション、さらには時間や場所などのコンテキストなどの属性に基づいてアクセスを行うことで、この問題に対処します。このような詳細なアクセス制御は、最新のアプリケーションにとって不可欠です。この記事ではその方法について説明しますジタデルこのような微妙な承認のニーズに応えます。

ロール、メタデータ、アクションなどの ZITADEL の機能を使用すると、ユーザーはゼロトラスト設定に適した非常に詳細なアクセス制御を取得できます。さらに、ZITADEL は外部の認証サービスと連携できます。

ZITADEL が提供する認可メカニズム

ジタデルは、オープンソース、Go で書かれたクラウドネイティブの ID およびアクセス管理ソリューション (IAM)。 ZITADEL は SaaS ソリューションとして利用でき、セルフホスティング オプションを求めるユーザー向けのオープンソースでもあるため、柔軟性が確保されています。 B2C と B2B の両方のユースケースに対応します。

その主な目的には、ユーザー インターフェイスを介したカスタマイズを可能にしながら、認証、認可、ログイン、シングル サインオン (SSO) のためのターンキー機能を提供することが含まれます。

すべての変更を追跡するための広範な監査証跡が付属しており、開発者がカスタム コード (アクション) で機能を拡張できるようにし、OIDC、OAuth、SAML、LDAP などの広く認知されている標準をサポートし、操作の容易さと拡張性を重視し、包括的な API を提供します。多用途の統合。

役割ベースのアクセス制御 (RBAC) と委任されたアクセス

ZITADEL は RBAC を使用してユーザー権限を管理します。権限はロールに関連付けられており、ユーザーにはこれらのロールが割り当てられます。これにより、組織の役割に基づいたユーザーのアクセス管理が簡素化されます。追加機能により、役割を他の組織に委任できるようになり、外部エンティティとの権限の共有が容易になります。

これは、相互接続された組織や階層的な組織にとって特に有益です。

これらの機能は堅牢なアクセス制御を提供しますが、複雑な認証ニーズには十分ではない可能性があるため、ZITADEL でのきめ細かい認証を検討することが重要です。

アクション機能、カスタム メタデータ、および属性ベースのアクセス制御 (ABAC) のクレーム

ZITADEL は、ダイナミックな機能を導入することで従来の RBAC を強化します。行動属性ベースのアクセス制御 (ABAC) の機能。ユーザーの役割に基づいてアクセスを許可する RBAC とは異なり、ABAC はより汎用性が高く、アクセス要求中にユーザー、アクション、およびリソースにリンクされた属性を評価します。

ZITADEL のアクションを使用すると、特定のユーザー属性を分析し、必要に応じてアクセスをブロックするための認証後スクリプトを作成できます。

アクションは、ABAC システムを強化するカスタム クレームを確立することもでき、場所、時間、または定義可能な要素などの属性に基づいてアクセスを制限する高度な承認モデルを有効にします。

ZITADEL を使用すると、管理者または許可された開発者はカスタム メタデータをユーザーや組織に追加でき、きめ細かいアクセス制御の可能性が高まります。

CRM や HR ツールなどの外部システムから追加データを収集することで、集計された請求をサポートします。 ZITADEL は、出荷注文や IoT デバイスなどの固有のリソースを管理し、User-Sub、ロール、クレーム、IP などの属性に基づいてアクセスを決定することもできます。

ZITADEL の既存機能を拡張してきめ細かいアクセス制御を実現

ZITADEL には包括的な機能が備わっていますが、よりカスタマイズされた、またはきめ細かいアプローチが必要な場合があります。

現在、ZITADEL で詳細な認可を実装する最も効果的な方法は、小規模プロジェクトまたは大規模プロジェクトの場合はカスタム アプリケーション ロジックを使用し、 warrant.dev 、 cerbos.devなどの利用可能なサードパーティ ツールを活用することです。

これらのツールは ZITADEL と統合できるため、微妙で細かい承認の能力がさらに強化されます。

実用的な例

メディア会社に、バックエンド API と通信する仮想のニュースルーム アプリケーションがあるとします。ジャーナリストはこれを使用して執筆し、編集者はこれらの記事を編集して公開します。この例では Python Flask で記述されたこの API には特定のエンドポイントがあり、これらのエンドポイントへのアクセスはユーザーの役割と経験に応じて異なります。エンドポイント:

• write_article : ジャーナリストのみが執筆できます。

• edit_article : 編集者が記事を編集するためだけに使用します。

• review_articles : 上級ジャーナリストおよび中級および上級編集者が記事をレビューするためのもの。

• publish_article : 中級および上級のジャーナリストおよび上級編集者が出版するための。 API は内部的に、誰がリクエストを行っているかを確認するために ZITADEL によって発行された JWT を使用します。ユーザーはリクエストのヘッダーで有効な JWT を送信する必要があります。この JWT は、ユーザーがログインしたときに取得されました。

  
  

  JWT には、ユーザーの役割や経験など、ユーザーに関する情報が含まれています。カスタム クレームに含まれるこの情報が、このユースケースの鍵となります。バックエンドは、この情報に基づいて、ユーザーが要求されたリソースにアクセスできるかどうかを判断します。

アプリケーションロジック

• ユーザー オンボーディング: ユーザー オンボーディング プロセス中に、各ユーザーはjournalistやeditorなどの役割を獲得します。これは、セットアップで誰がどのアクセス権を取得するかを設定するため、重要です。経験/年功の管理: 役割に加えて、ユーザーの経験 (この例ではjunior 、 intermediate 、 seniorなど) も追跡されます。ユーザーのエクスペリエンスが変化すると、ZITADEL はそれをメタデータとして更新します。ユーザーが ZITADEL に参加するときに経験レベルが指定されていない場合、システムはそのユーザーを単に「ジュニア」とみなします。

• ユーザーログイン: API にアクセスするには、ユーザーはまずログインする必要があります。ログインに成功すると、ZITADEL はユーザーの情報を含むトークンを返します。

• トークンの検証:ユーザーからのリクエストが API に到達すると、API は ZITADEL のトークン イントロスペクション エンドポイントを呼び出してトークンを検証します。 JWT は JWKS を使用してローカルで検証できますが、セキュリティを向上させ、即時トークン チェックを行うために ZITADEL の方法を使用してトークンを検査しました。このようにして、トークンを即座に取り消し、1 か所から管理できるため、セキュリティの問題が少なくなります。これにより、API のログインとアクセスの制御が強力になり、サーバーが最新の状態に保たれます。

• きめ細かいアクセス制御:アプリケーションは、ユーザーの役割と経験レベルに基づいてリソースへのアクセスを承認する責任があります。これは、各リソース エンドポイントを、アクセスを許可されたユーザー ロールおよびエクスペリエンス レベルにマップする、事前定義されたアクセス制御リストを使用します。このリストは、リソースへのアクセスを許可または拒否するためのルールブックとして機能します。

• 関心事の分離: この API の設計では、ビジネス ロジックとアクセス コントロール ルールが明確に分離されるように特別な注意が払われました。これは、アプリケーションの保守性と拡張性にとって非常に重要です。ビジネス ロジックとアクセス ルールを分離することで、よりクリーンなモジュール設計が得られます。

  
  

  これにより、ビジネス アクションとアクセス ルールを相互に影響を与えることなく更新できます。これにより、コードの保守性が向上し、アプリケーションのスケールに応じた管理が容易になります。

  
  

  さらに、この設計により、アクセス ルールが主要なビジネス ロジックから抽象化されるため、システムの安全性が高まり、ビジネス ロジックを変更するときに誤ってセキュリティの脆弱性が発生するリスクが軽減されます。

ZITADELをセットアップする

1.メディアハウス組織、ニュースルームプロジェクト、記事APIを作成する

1. Media House 組織を作成し、 [プロジェクト] に移動して、 Newsroom という新しいプロジェクトを作成します。

   
   

   

   
   

2. Newsroom プロジェクトで、 「新規」ボタンをクリックして新しいアプリケーションを作成します。

3. 名前を追加し、タイプAPIを選択します。

4. 認証方法として[基本]を選択し、 [続行]をクリックします。

5. 次に、構成を確認し、 「作成」をクリックします。

6. API のクライアント IDとクライアント シークレットが表示されます。それらをコピーして保存します。 「閉じる」をクリックします。

7. 左側のURLをクリックすると、関連する OIDC URL が表示されます。発行者のURL、 token_endpoint 、およびintrospection_endpointを書き留めます。

2. Newsroom プロジェクトでロールを作成する

1. また、プロジェクトのリソース IDをメモします (プロジェクトに移動し、リソース ID をコピーします)。

2. プロジェクト ダッシュボードの[認証でロールをアサート]チェックボックスを選択し、 [保存]をクリックします。

3. (左側のメニューから) [役割]に移動し、 [新規]をクリックして新しい役割を追加します。

4. 以下に示すように編集者とジャーナリストの役割を入力し、 [保存]をクリックします。

5. 作成されたロールが表示されます。

3. Newsroom プロジェクトでユーザーを作成する

1. 以下に示すように、組織の[ユーザー]タブに移動し、 [サービス ユーザー]タブに移動します。このデモではサービス ユーザーを作成します。サービス ユーザーを追加するには、 [新規]ボタンをクリックします。

   
   

   

   
   

2. 次に、サービス ユーザーの詳細を追加し、アクセス トークン タイプとしてJWTを選択し、 [作成]をクリックします。

   
   

   

   
   

3. 右上隅にある「アクション」ボタンをクリックします。ドロップダウン メニューから[クライアント シークレットの生成]を選択します。

   
   

   

   
   

   
   

4. クライアント ID とクライアント シークレットをコピーします。 「閉じる」をクリックします。

   
   

   

   
   

5. これで、サービス ユーザーとそのクライアントの資格情報が得られました。

4. ユーザーの権限を追加する

1. 「認証」に移動します。 「新規」をクリックします。
   

   

   
   

2. 承認を作成する必要があるユーザーとプロジェクトを選択します。 [続行]をクリックします。

   
   

   

   
   

3. ここで役割を選択できます。現在のユーザーのジャーナリストの役割を選択します。 「保存」をクリックします。

   
   

   

   
   

4. サービス ユーザーのLois Lane がNewsroomプロジェクトでジャーナリストの役割を果たしていることがわかります。

5. ユーザーにメタデータを追加する

次に、年功レベルを示すメタデータをユーザー プロファイルに追加しましょう。キーとして「 experience_level 」を使用し、その値として「ジュニア」、「中級」、または「上級」から選択します。

通常、このメタデータは HR アプリケーションによって行われる API 呼び出しを通じて設定されると想定できますが、簡略化して理解しやすくするために、コンソールでメタデータを直接設定します。

1. 「メタデータ」に移動します。 [編集]をクリックします。
   

   
   

   

   
   

2. experience_levelをキーとして、 seniorを値として指定します。保存アイコンをクリックし、閉じるボタンをクリックします。

   
   

   

   
   

3. これで、ユーザーは自分のアカウントに関連付けられた必要なメタデータを取得しました。
   

   
   

   

   
   

4. さまざまなロールとエクスペリエンス レベルを持つサービス ユーザーをさらに数人追加し (メタデータを使用)、前の手順を使用してデモをテストすることもできます。

   
   

   

6. カスタム要求のロールとメタデータを取得するアクションを作成する

1. [アクション]をクリックします。新しいアクションを作成するには、 「新規」をクリックします。

2. 「アクションの作成」セクションで、アクションに関数名と同じ名前 (assignRoleAndExperienceClaims) を付けます。スクリプト フィールドに次のコードをコピー/貼り付けて、 [追加]をクリックします。

 function assignRoleAndExperienceClaims(ctx, api) { // Check if grants and metadata exist if (!ctx.v1.user.grants || !ctx.v1.claims['urn:zitadel:iam:user:metadata']) { return; } // Decode experience level from Base64 - metadata is Base64 encoded let experience_encoded = ctx.v1.claims['urn:zitadel:iam:user:metadata'].experience_level; let experience = ''; try { experience = decodeURIComponent(escape(String.fromCharCode.apply(null, experience_encoded.split('').map(function(c) { return '0x' + ('0' + c.charCodeAt(0).toString(16)).slice(-2); })))); } catch (e) { return; // If decoding fails, stop executing the function } // Check if the experience level exists if (!experience) { return; } // Iterate through the user's grants ctx.v1.user.grants.grants.forEach(grant => { // Iterate through the roles of each grant grant.roles.forEach(role => { // Check if the user is a journalist if (role === 'journalist') { // Set custom claims with the user's role and experience level api.v1.claims.setClaim('journalist:experience_level', experience); } // Check if the user is an editor else if (role === 'editor') { // Set custom claims with the user's role and experience level api.v1.claims.setClaim('editor:experience_level', experience); } }); }); }

3. assignRoleAndExperienceClaimsがアクションとしてリストされるようになります。

4. 次に、フロータイプを選択する必要があります。以下の「フロー」セクションに移動します。ドロップダウンから「補完トークン」を選択します。

5. 次に、トリガーを選択する必要があります。 [トリガーの追加]をクリックします。トリガーの種類としてプリアクセス トークンの作成を選択し、関連するアクションとしてassignRoleAndExperienceClaimsを選択します。

6. これで、トリガーがリストに表示されます。

ユーザーがアクセス トークンを要求すると、アクションが実行され、ユーザー ロールとメタデータが必要な形式に変換され、カスタム クレームとしてトークンに追加されます。このカスタム クレームは、サードパーティ アプリケーションで使用して、きめ細かいユーザー アクセスを管理できます。

API プロジェクトのセットアップ

GitHub からプロジェクトのクローンを作成します。

以下のコマンドを実行して、この GitHub リポジトリからプロジェクトのクローンを作成します。

• git clone https://github.com/zitadel/example-fine-grained-authorization.git

プロジェクト ディレクトリに移動します。

クローン作成後、次のコマンドを使用してプロジェクト ディレクトリに移動します。

• cd example-fine-grained-authorization 。

Python 環境をセットアップします。

Python 3 と pip がインストールされていることを確認してください。これを実行すると確認できます

• python3 --versionと
• pip3 --version

あなたの端末で。 Python または pip がインストールされていない場合は、インストールする必要があります。

次に、次のコマンドを実行して、このプロジェクトの新しい仮想環境を作成します。

• python3 -m venv env 。

以下を実行して環境をアクティブ化します。

• Windows の場合: .\env\Scripts\activate
• Unix または MacOS の場合: source env/bin/activate

このコマンドを実行すると、env 仮想環境内で作業していることがターミナルに表示されるはずです。

依存関係をインストールします。

ターミナルのプロジェクト ディレクトリ (requirements.txt を含むディレクトリ) で、次を実行します。

• pip3 install -r requirements.txt

必要な依存関係をインストールします。

環境変数を構成します。

プロジェクトには特定の環境変数が必要です。 ZITADEL から取得した値を.envファイルに入力します。

 PROJECT_ID="<YOUR PROJECT ID>" ZITADEL_DOMAIN="<YOUR INSTANCE DOMAIN eg https://instance-as23uy.zitadel.cloud>" ZITADEL_TOKEN_URL="<YOUR TOKEN URL eg https://instance-as23uy.zitadel.cloud/oauth/v2/token" CLIENT_ID="<YOUR SERVICE USER'S CLIENT ID FROM THE GENERATED CLIENT CREDENTIALS eg sj_Alice>" CLIENT_SECRET="<YOUR SERVICE USER'S SECRET FROM THE GENERATED CLIENT CREDENTIALS"> ZITADEL_INTROSPECTION_URL="<YOUR INTROSPECTION URL eg https://instance-as23uy.zitadel.cloud/oauth/v2/introspect>" API_CLIENT_ID="<THE CLIENT ID OF YOUR API APPLICATION FOR BASIC AUTH eg 324545668690006737@api>" API_CLIENT_SECRET="<THE CLIENT SECRET OF YOUR API APPLICATION FOR BASIC AUTH>"

アプリケーションを実行します。

Flask API ( app.py内) は、JWT トークンとカスタム クレームを使用して、きめ細かいアクセス制御を実現します。すべてのリクエストでjournalistとeditorロールのカスタム クレーム experience_level をチェックし、この情報を使用して、認証されたユーザーがリクエストされたエンドポイントにアクセスできるかどうかを判断します。

app.py

 from flask import Flask, jsonify from auth import token_required from access_control import authorize_access app = Flask(__name__) # Define the /write_article route. @app.route('/write_article', methods=['POST']) @token_required def write_article(): authorization = authorize_access('write_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article written successfully!"}), 200 # Define the /edit_article route. @app.route('/edit_article', methods=['PUT']) @token_required def edit_article(): authorization = authorize_access('edit_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article edited successfully!"}), 200 # Define the /review_article route. @app.route('/review_articles', methods=['GET']) @token_required def review_article(): authorization = authorize_access('review_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article review accessed successfully!"}), 200 # Define the /publish_article route. @app.route('/publish_article', methods=['POST']) @token_required def publish_article(): authorization = authorize_access('publish_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article published successfully!"}), 200 # Add more endpoints as needed... if __name__ == '__main__': app.run(debug=True)

auth.py

 import os import jwt import requests from functools import wraps from flask import request, jsonify, g ZITADEL_INTROSPECTION_URL = os.getenv('ZITADEL_INTROSPECTION_URL') API_CLIENT_ID = os.getenv('API_CLIENT_ID') API_CLIENT_SECRET = os.getenv('API_CLIENT_SECRET') # This function checks the token introspection and populates the flask.g variable with the user's token def token_required(f): @wraps(f) def decorated(*args, **kwargs): token = request.headers.get('Authorization') if not token: abort(401) # Return status code 401 for Unauthorized if there's no token else: token = token.split(' ')[1] # The token is in the format "Bearer <token>", we want to extract the actual token # Call the introspection endpoint introspection_response = requests.post( ZITADEL_INTROSPECTION_URL, auth=(API_CLIENT_ID, API_CLIENT_SECRET), data={'token': token} ) if not introspection_response.json().get('active', False): return jsonify({"message": "Invalid token"}), 403 # Decode the token and print it for inspection decoded_token = jwt.decode(token, options={"verify_signature": False}) print(f"\n\n***** Decoded Token: {decoded_token} \n\n******") # Add the decoded token to Flask's global context g.token = decoded_token return f(*args, **kwargs) return decorated

access_control.py (ルール エンジンをシミュレートするサンプル コード)

 import base64 import jwt from flask import g, jsonify # The access_requirements dictionary represents your access control rules. access_requirements = { 'write_article': [{'role': 'journalist', 'experience_level': 'junior'}, {'role': 'journalist', 'experience_level': 'intermediate'}, {'role': 'journalist', 'experience_level': 'senior'}], 'edit_article': [{'role': 'editor', 'experience_level': 'junior'}, {'role': 'editor', 'experience_level': 'intermediate'}, {'role': 'editor', 'experience_level': 'senior'}], 'review_articles': [{'role': 'journalist', 'experience_level': 'senior'}, {'role': 'editor', 'experience_level': 'intermediate'}, {'role': 'editor', 'experience_level': 'senior'}], 'publish_article': [{'role': 'journalist', 'experience_level': 'intermediate'}, {'role': 'journalist', 'experience_level': 'senior'}, {'role': 'editor', 'experience_level': 'senior'}] # Add more endpoints as needed... } # This function checks if the user is authorized to access the given endpoint. def authorize_access(endpoint): # We assume that the token has already been decoded in auth.py decoded_token = g.token # Initialize role and experience_level variables role = None experience_level = None for claim, value in decoded_token.items(): if ':experience_level' in claim: role, _ = claim.split(':') experience_level = base64.b64decode(value).decode('utf-8') break # If there's no role in the token, return an error if not role: return jsonify({"message": "Missing role"}), 403 # If there's a role in the token but no experience level, default the experience level to 'junior' if role and not experience_level: experience_level = 'junior' # If there's no role or experience level in the token, return an error if not role or not experience_level: return jsonify({"message": "Missing role or experience level"}), 403 # Get the requirements for the requested endpoint endpoint_requirements = access_requirements.get(endpoint) # If the endpoint is not in the access control list, return an error if not endpoint_requirements: return jsonify({"message": "Endpoint not found in access control list"}), 403 # Check if the user's role and experience level meet the requirements for the requested endpoint for requirement in endpoint_requirements: required_role = requirement['role'] required_experience_level = requirement['experience_level'] # Experience level hierarchy experience_levels = ['junior', 'intermediate', 'senior'] if role == required_role and experience_levels.index(experience_level) >= experience_levels.index(required_experience_level): return True #return jsonify({"message": "Access denied"}), 403 return jsonify({"message": f"Access denied! You are a {experience_level} {role} and therefore cannot access {endpoint}"}), 403

以下を実行して Flask アプリケーションを実行します。

python3 app.py

すべてが正しく設定されていれば、Flask アプリケーションが実行されるはずです。

このプロジェクトは Python 3 で開発およびテストされているため、Python 3 インタープリターを使用していることを確認してください。

API の実行とテスト

APIを実行する

1. 前に説明したように、リポジトリのクローンを作成し、必要な依存関係をインストールしていることを確認してください。

   
   

2. client_credentials_token_generator.pyスクリプトを実行してアクセス トークンを生成します。

   
   

   client_credentials_token_generator.py

    import os import requests import base64 from dotenv import load_dotenv load_dotenv() ZITADEL_DOMAIN = os.getenv("ZITADEL_DOMAIN") CLIENT_ID = os.getenv("CLIENT_ID") CLIENT_SECRET = os.getenv("CLIENT_SECRET") ZITADEL_TOKEN_URL = os.getenv("ZITADEL_TOKEN_URL") PROJECT_ID = os.getenv("PROJECT_ID") # Encode the client ID and client secret in Base64 client_credentials = f"{CLIENT_ID}:{CLIENT_SECRET}".encode("utf-8") base64_client_credentials = base64.b64encode(client_credentials).decode("utf-8") # Request an OAuth token from ZITADEL headers = { "Content-Type": "application/x-www-form-urlencoded", "Authorization": f"Basic {base64_client_credentials}" } data = { "grant_type": "client_credentials", "scope": f"openid profile email urn:zitadel:iam:org:project:id:{PROJECT_ID}:aud urn:zitadel:iam:org:projects:roles urn:zitadel:iam:user:metadata" } response = requests.post(ZITADEL_TOKEN_URL, headers=headers, data=data) if response.status_code == 200: access_token = response.json()["access_token"] print(f"Response: {response.json()}") print(f"Access token: {access_token}") else: print(f"Error: {response.status_code} - {response.text}")

   
   

   ターミナルを開いてプロジェクト ディレクトリに移動し、python3 を使用してスクリプトを実行します。

   python3 client_credentials_token_generator.py

   
   

3. 成功すると、アクセス トークンが端末に出力されます。これは、API へのリクエストを認証するために使用するトークンです。

   
   

4. まだ Flask API を開始していない場合は、プロジェクト ディレクトリで別のターミナルを開いて次のコマンドを実行して、API を実行します。

   python3 app.py

   
   

5. API サーバーが実行され、リクエストを受け入れる準備ができているはずです。

これで、cURL またはその他の HTTP クライアント (Postman など) を使用して API にリクエストを送信できるようになります。忘れずに、curl コマンドのyour_access_token 、手順 2 で取得したアクセス トークンに置き換えてください。

APIをテストする

シナリオ 1: ジュニア編集者が記事を編集しようとしました (成功)

editorロールとjunior experience_level を持つユーザーがedit_articleエンドポイントを呼び出そうとします。

• curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/edit_article

• 予期される出力: {"message": "Article edited successfully"}

  
  

シナリオ 2: ジュニア編集者が記事を公開しようとしました (失敗)

editorロールとjunior experience_level を持つユーザーが、 publish_articleエンドポイントを呼び出そうとします。

• curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/publish_article

• 予期される出力: {"message": "Access denied! You are a junior editor and therefore cannot access publish_article"}

  
  

シナリオ 3: 上級ジャーナリストが記事を書こうとする (成功)

journalist役割とsenior experience_level を持つユーザーが、 write_articleエンドポイントの呼び出しを試みます。

• curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/write_article

• 予期される出力: {"message": "Article written successfully"}

  
  

シナリオ 4: 若手ジャーナリストが記事をレビューしようとする (失敗)

journalist役割と「ジュニア」の experience_level を持つユーザーがreview_articlesエンドポイントを呼び出そうとします。

• curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/review_articles

• 予期される出力: {"message": "Access denied! You are a junior journalist and therefore cannot access review_articles"}

  
  

シナリオ 5: 上級編集者が記事をレビューしようとしている (成功)

editorの役割とsenior experience_level を持つユーザーがreview_articlesエンドポイントにアクセスしようとします。

• curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/review_articles

• 予期される出力: {"message": "Article reviewed successfully"}

  
  

シナリオ 6: 中級ジャーナリストが記事を掲載しようとする (成功)

journalist役割とintermediate experience_level を持つユーザーが、 publish_articleエンドポイントにアクセスしようとします。

• curl -H "Authorization: Bearer <your_access_token>" -X POST http://localhost:5000/publish_article

• 予期される出力: {"message": "Article published successfully"}

結論

この記事では、従来の RBAC から、ZITADEL を使用したより詳細で粒度の細かい承認アプローチに移行することの重要性について説明しました。

私たちは、ABAC の動的アクション、サードパーティ ツールとの統合機能などの機能を詳しく調べ、これらの機能が現実のシナリオにどのように実際に適用できるかを確認しました。

サイバーセキュリティの需要が高まるにつれ、ZITADEL のようなプラットフォームは、複雑な認証の課題に必要なソリューションを提供します。