paint-brush
로그인 그 이상: ZITADEL로 세분화된 인증 구현~에 의해@zitadel
3,963 판독값
3,963 판독값

로그인 그 이상: ZITADEL로 세분화된 인증 구현

~에 의해 ZITADEL20m2023/11/10
Read on Terminal Reader

너무 오래; 읽다

이 문서에서는 기존 역할 기반 액세스 제어에서 세분화된 보안으로의 전환에 대해 자세히 설명합니다. ZITADEL은 동적 기능으로 인증을 강화하고 맞춤형 요구에 맞는 외부 통합을 지원합니다. 실제 사례에서는 이러한 원칙이 실제로 적용되는 모습을 보여줍니다. 실무 개발자를 위해 이 기사에서는 Python의 전체 코드 구현을 다룹니다.
featured image - 로그인 그 이상: ZITADEL로 세분화된 인증 구현
ZITADEL HackerNoon profile picture
0-item
1-item


소개

제로 트러스트 사고방식으로 전환함에 따라 기존 RBAC 시스템과 같이 세분화된 보안 조치의 한계가 분명해집니다. 종종 논의되지 않는 제로 트러스트로의 전환에서 필수적인 부분은 대략적인 보안에서 세분화된 보안으로의 이동입니다.


세분화된 권한 부여는 사용자 역할, 작업, 심지어 시간이나 위치와 같은 컨텍스트에 대한 액세스를 기반으로 이 문제를 해결하며, 이러한 세부적인 액세스 제어는 최신 애플리케이션에 필수적입니다. 이 기사에서는 방법을 설명합니다. 지타델 이러한 미묘한 승인의 필요성을 충족시킵니다.


역할, 메타데이터, 작업과 같은 ZITADEL의 기능을 통해 사용자는 제로 트러스트 설정에 적합한 매우 상세한 액세스 제어를 얻을 수 있습니다. 또한 ZITADEL은 외부 인증 서비스와 협력할 수 있습니다.

ZITADEL이 제공하는 인증 메커니즘

ZITADEL은 오픈 소스 , Go로 작성된 클라우드 기반 ID 및 액세스 관리 솔루션(IAM)입니다. ZITADEL은 SaaS 솔루션으로 제공되며 셀프 호스팅 옵션을 원하는 사람들을 위한 오픈 소스이기도 하여 유연성을 보장합니다. B2C 및 B2B 사용 사례를 모두 충족합니다.


주요 목표는 인증, 권한 부여, 로그인 및 SSO(Single Sign-On)를 위한 턴키 기능을 제공하는 동시에 사용자 인터페이스를 통해 사용자 정의를 허용하는 것입니다.


모든 변경 사항을 추적하기 위한 광범위한 감사 추적 기능이 제공되고, 개발자가 사용자 지정 코드(작업)로 기능을 확장할 수 있으며, OIDC, OAuth, SAML, LDAP 등 널리 인정받는 표준을 지원하고, 운영 용이성과 확장성을 강조하며, 포괄적인 API를 제공합니다. 다양한 통합.

역할 기반 액세스 제어(RBAC) 및 위임된 액세스

ZITADEL은 RBAC를 사용하여 사용자 권한을 관리합니다. 여기서 권한은 역할에 연결되고 사용자에게는 이러한 역할이 할당됩니다. 이는 조직의 역할에 따라 사용자 액세스 관리를 단순화합니다. 추가 기능을 사용하면 역할을 다른 조직에 위임하여 외부 엔터티와의 권한 공유를 용이하게 할 수 있습니다.


이는 상호 연결된 조직이나 계층적 조직에 특히 유용합니다.


이러한 기능은 강력한 액세스 제어를 제공하지만 복잡한 인증 요구 사항에는 충분하지 않을 수 있으므로 ZITADEL에서 세분화된 인증을 탐색하는 것이 중요합니다.

작업 기능, 사용자 정의 메타데이터 및 속성 기반 액세스 제어(ABAC)에 대한 클레임

ZITADEL은 역동적인 기능을 도입하여 전통적인 RBAC를 향상시킵니다. 행위 ABAC(속성 기반 액세스 제어) 기능입니다. 사용자 역할을 기반으로 액세스 권한을 부여하는 RBAC와 달리 ABAC는 액세스 요청 중에 사용자, 작업 및 리소스에 연결된 속성을 평가하여 더욱 다재다능합니다.


ZITADEL의 작업을 통해 사후 인증 스크립트를 생성하여 특정 사용자 속성을 분석하고 필요한 경우 액세스를 차단할 수 있습니다.


또한 작업은 ABAC 시스템을 강화하기 위한 사용자 지정 클레임을 설정하여 위치, 시간 또는 정의 가능한 요소와 같은 속성을 기반으로 액세스를 제한하는 고급 인증 모델을 활성화할 수 있습니다.


ZITADEL을 사용하면 관리자 또는 허용된 개발자가 사용자 및 조직에 사용자 정의 메타데이터를 추가하여 세분화된 액세스 제어 가능성을 확대할 수 있습니다.


CRM 또는 HR 도구와 같은 외부 시스템에서 추가 데이터를 수집하여 집계된 청구를 지원합니다. ZITADEL은 또한 배송 주문이나 IoT 장치와 같은 고유한 리소스를 관리하고 사용자 하위, 역할, 클레임, 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에는 역할, 경험 등 사용자에 대한 정보가 포함되어 있습니다. 맞춤 클레임에 포함된 이 정보는 이 사용 사례의 핵심입니다. 백엔드는 이 정보를 기반으로 사용자가 요청된 리소스에 액세스할 수 있는지 여부를 결정합니다.

애플리케이션 로직

다이어그램 1: 로그인 이후 세분화된 인증의 상호 작용



  • 사용자 온보딩 : 사용자 온보딩 프로세스 중에 각 사용자는 journalist 또는 editor 와 같은 역할을 받습니다. 이는 설정에서 누가 어떤 액세스 권한을 얻을 수 있는지 설정하기 때문에 중요합니다. 경험/경력 관리: 역할 외에도 사용자의 경험(예: junior , intermediate , senior )이 추적됩니다. 사용자 경험이 변경되면 ZITADEL은 이를 메타데이터로 업데이트합니다. 사용자가 ZITADEL에 탑승할 때 경험 수준이 언급되지 않으면 시스템은 단순히 '주니어'로 간주합니다.


  • 사용자 로그인 : 사용자가 API에 접근하려면 먼저 로그인해야 합니다. 로그인에 성공하면 ZITADEL은 사용자 정보가 포함된 토큰을 반환합니다.


  • 토큰 검증: 사용자의 요청이 API에 도달하면 API는 ZITADEL의 토큰 검사 엔드포인트를 호출하여 토큰의 유효성을 검사합니다. JWKS를 사용하여 JWT를 로컬에서 검증할 수 있지만 우리는 더 나은 보안과 즉각적인 토큰 확인을 위해 ZITADEL의 방법을 사용하여 토큰을 검사했습니다. 이렇게 하면 토큰을 즉시 취소하고 한 곳에서 관리할 수 있으며 보안 문제가 줄어듭니다. 이는 API의 로그인 및 액세스 제어를 강력하고 서버에 대한 최신 상태로 유지합니다.


  • 세분화된 액세스 제어: 애플리케이션은 사용자의 역할과 경험 수준에 따라 리소스에 대한 액세스 권한을 부여하는 역할을 합니다. 이는 각 리소스 끝점을 액세스 권한이 있는 사용자 역할 및 경험 수준에 매핑하는 미리 정의된 액세스 제어 목록을 사용합니다. 이 목록은 리소스에 대한 액세스를 허용하거나 거부하기 위한 규칙집 역할을 합니다.


  • 우려 사항의 분리 : 이 API를 설계할 때 비즈니스 로직과 액세스 제어 규칙을 명확하게 분리하는 데 특별한 주의를 기울였습니다. 이는 애플리케이션의 유지 관리성과 확장성에 매우 중요합니다. 비즈니스 로직과 액세스 규칙을 별도로 유지함으로써 더욱 깔끔한 모듈식 디자인을 얻을 수 있습니다.


    이를 통해 서로 영향을 주지 않고 비즈니스 활동과 액세스 규칙을 업데이트할 수 있습니다. 이렇게 하면 코드의 유지 관리성이 향상되고 애플리케이션 확장에 따라 관리가 더 쉬워집니다.


    또한 이 설계는 액세스 규칙이 기본 비즈니스 로직에서 추상화되므로 시스템을 더욱 안전하게 만들어 비즈니스 로직을 수정할 때 실수로 보안 취약점이 발생할 위험을 줄입니다.

ZITADEL 설정

1. 미디어 하우스 조직, 뉴스룸 프로젝트 및 기사 API 만들기

  1. Media House 조직을 만들고 프로젝트 로 이동하여 뉴스룸이라는 새 프로젝트를 만듭니다.



  2. 뉴스룸 프로젝트에서 새로 만들기 버튼을 클릭하여 새 애플리케이션을 만듭니다.



  1. 이름을 추가하고 API 유형을 선택합니다.



  1. 인증 방법으로 기본을 선택하고 계속 을 클릭합니다.



  1. 이제 구성을 검토하고 만들기를 클릭합니다.



  1. 이제 API의 클라이언트 ID클라이언트 비밀번호가 표시됩니다. 복사하여 저장하세요. 닫기 를 클릭합니다.



  1. 왼쪽의 URL을 클릭하시면 해당 OIDC URL을 보실 수 있습니다. 발급자 URL, token_endpointintrospection_endpoint 를 기록해 두세요.



2. 뉴스룸 프로젝트에서 역할 생성

  1. 또한 프로젝트의 리소스 ID를 적어두세요(프로젝트로 이동하여 리소스 ID를 복사하세요).



  1. 프로젝트 대시보드의 인증에서 역할 지정 확인란을 선택하고 저장을 클릭합니다.



  1. 왼쪽 메뉴에서 역할 로 이동하고 새로 만들기를 클릭하여 새 역할을 추가합니다.



  1. 아래와 같이 편집자저널리스트 의 역할을 입력하고 저장을 클릭합니다.



  1. 이제 생성된 역할이 표시됩니다.



3. 뉴스룸 프로젝트에서 사용자 생성

  1. 아래와 같이 조직의 사용자 탭으로 이동한 후 서비스 사용자 탭으로 이동합니다. 이 데모에서는 서비스 사용자를 생성할 것입니다. 서비스 사용자를 추가하려면 새로 만들기 버튼을 클릭하세요.


    서비스 사용자 생성


  2. 그런 다음 서비스 사용자의 세부 정보를 추가하고 액세스 토큰 유형 에서 JWT를 선택한 후 생성을 클릭합니다.


    서비스 사용자 생성


  3. 오른쪽 상단에 있는 작업 버튼을 클릭하세요. 드롭다운 메뉴에서 클라이언트 비밀번호 생성을 선택합니다.




  4. 클라이언트 ID와 클라이언트 비밀번호를 복사하세요. 닫기 를 클릭합니다.



  5. 이제 클라이언트 자격 증명과 함께 서비스 사용자가 생겼습니다.

4. 사용자에 대한 권한 추가

  1. 승인 으로 이동합니다. 새로 만들기 를 클릭합니다.


  2. 권한을 생성해야 하는 사용자와 프로젝트를 선택합니다. 계속 을 클릭합니다.



  3. 여기서 역할을 선택할 수 있습니다. 현재 사용자의 저널리스트 역할을 선택합니다. 저장 을 클릭합니다.


    승인 추가


  4. 이제 서비스 사용자 Lois Lane이 Newsroom 프로젝트에서 기자 역할을 맡은 것을 볼 수 있습니다.



5. 사용자에게 메타데이터 추가

이제 사용자 프로필에 메타데이터를 추가하여 연공서열 수준을 표시해 보겠습니다. 'experience_level'을 키로 사용하고, 값은 'junior', 'intermediate', 'senior' 중에서 선택하세요.


일반적으로 이 메타데이터는 HR 애플리케이션의 API 호출을 통해 설정된다고 가정할 수 있지만 단순성과 이해의 용이성을 위해 메타데이터를 콘솔에서 직접 설정하겠습니다.


  1. 메타데이터 로 이동합니다. 편집 을 클릭합니다.



  2. experience_level을 키로, Senior를 값으로 제공하세요. 저장 아이콘을 클릭한 후 닫기 버튼을 클릭하세요.



  3. 이제 사용자는 자신의 계정과 연결된 필수 메타데이터를 갖게 되었습니다.



  4. 또한 다양한 역할과 experience_levels(메타데이터 사용)을 가진 몇 명의 서비스 사용자를 추가하여 이전 단계를 사용하여 데모를 테스트할 수도 있습니다.


6. 사용자 지정 클레임에서 역할 및 메타데이터를 캡처하는 작업 만들기

1. 작업 을 클릭합니다. 새 작업을 만들려면 새로 만들기를 클릭하세요.



2. 작업 만들기 섹션에서 작업에 함수 이름과 동일한 이름을 지정합니다(예: 할당RoleAndExperienceClaims). 스크립트 필드에 다음 코드를 복사하여 붙여넣은 후 추가를 클릭합니다.



 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); } }); }); }


  1. 이제 AssignRoleAndExperienceClaims가 작업으로 나열됩니다.



  1. 다음으로 Flow Type을 선택해야 합니다. 아래 흐름 섹션으로 이동하세요. 드롭다운에서 보완 토큰을 선택합니다.



  1. 이제 트리거를 선택해야 합니다. 트리거 추가 를 클릭합니다. 트리거 유형으로 사전 액세스 토큰 생성을 선택하고 연결된 작업으로 할당RoleAndExperienceClaims를 선택합니다.



  1. 이제 트리거가 나열된 것을 볼 수 있습니다.



이제 사용자가 액세스 토큰을 요청하면 작업이 실행되어 사용자 역할과 메타데이터를 필요한 형식으로 변환하고 이를 토큰에 사용자 지정 클레임으로 추가합니다. 그런 다음 이 사용자 지정 클레임을 타사 애플리케이션에서 사용하여 세분화된 사용자 액세스를 관리할 수 있습니다.

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 토큰과 사용자 정의 클레임을 사용합니다. 모든 요청에서 journalisteditor 역할에 대한 사용자 정의 클레임 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에 요청할 수 있습니다. 컬 명령의 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 역할과 'junior' 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"}

결론

이 기사에서는 ZITADEL을 사용하여 전통적인 RBAC에서 보다 상세하고 세분화된 인증 접근 방식으로 전환하는 것의 중요성을 살펴보았습니다.


우리는 ABAC의 동적 작업, 타사 도구와의 통합 기능과 같은 기능을 조사하고 이러한 기능이 실제 시나리오에서 어떻게 실제로 적용될 수 있는지 확인했습니다.


사이버 보안에 대한 요구가 증가함에 따라 ZITADEL과 같은 플랫폼은 복잡한 인증 문제에 필요한 솔루션을 제공합니다.