feature 추가

인증 및 승인

인증 feature은 Lino 프로젝트에서 사용하는 보안 기반을 추가하여 API를 보호하고, 사용자를 식별하고, 작업에 대한 액세스를 제어하고, 동일한 권한을 Blazor 웹 앱과 통합합니다. 다음 명령으로 설치됩니다.

lino feature auth add --service <ServiceName> --module <ModuleName>

명령은 다음을 사용하여 대화식으로 실행할 수도 있습니다. lino feature auth add. 정식 분기는 다음과 같습니다. feature auth; CLI는 다음과 같은 별칭도 노출합니다. feature security 그리고 feature identity.

현재 Lino 아키텍처에서는 인증 및 권한 부여가 비동기 메시징에 의존합니다. 그 이유는 운영상의 이유입니다. 서비스 및 모듈 권한은 통합 이벤트에 의해 동기화되므로 보안을 추가하기 전에 프로젝트에서 메시징을 활성화해야 합니다.

마법사가 요구하는 것

CLI는 현재 프로젝트의 유효성을 검사하고, feature이 아직 설치되지 않았는지 확인하고, 보안 모듈을 생성해야 하는 위치를 묻고 기본 토큰 설정을 요청합니다.

• 서비스: 보안 리소스를 호스팅할 서비스입니다.
• 기준 치수: 선택한 서비스가 모듈형인 경우 대상 모듈입니다.
• 액세스 토큰 수명: 발급된 액세스 토큰의 수명(분)입니다.
• 토큰 수명 새로 고침: 세션을 갱신하는 데 사용되는 토큰의 수명입니다.
• 사용자 식별자 유형: 사용자 식별자로 사용되는 데이터 유형(예: int, long 또는 Guid.

생성된 보안 모델

확인 후 Lino는 프로젝트 메타데이터를 업데이트하고, 보안 구성 값을 생성하고, 소스 코드 파일을 생성하고, 필요한 명령을 실행합니다. 생성된 모델에는 중앙 보안 엔터티가 포함됩니다.

• User는 신원 및 프로필 데이터를 저장합니다.
• Role 그룹 액세스 규칙에 대한 역할 연결.
• Permission 세분화된 권한 부여를 위한 역할과 권한 간의 관계.
• UserToken 새로 고침 토큰 및 토큰 수명 주기를 제어합니다.

이 feature은 토큰 서명 비밀값과 access token 및 refresh token 수명 등 보안 구성에 필요한 정보도 생성합니다. 민감한 값은 버전이 지정된 파일에 직접 기록되지 않고 AppHost 사용자 비밀에 대한 명령으로 실행됩니다.

런타임 동작

API는 JWT Bearer 인증을 사용합니다. 사용자는 로그인하여 access token과 refresh token을 받고, Authorization: Bearer <token> header와 함께 API에 요청을 보냅니다. 백엔드는 토큰의 유효성을 검사하고, 사용자 컨텍스트를 로드하고, 엔드포인트에 권한 부여 규칙을 적용합니다.

일반적인 흐름은 간단합니다. 엔드포인트 또는 전용 페이지를 통해 로그인하고, ID 클레임, 역할 및 권한이 포함된 JWT를 발급하고, 각 요청에 토큰을 보내고, 인증 미들웨어를 통해 서명 및 만료를 확인합니다.

Lino는 정책과 권한을 사용하여 세분화된 인증을 구현합니다. 각 작업에는 다음과 같은 특정 권한이 필요할 수 있습니다. People.Read 또는 People.Create; 정책은 다음을 통해 구성할 수 있습니다. AddAuthorization; 엔드포인트는 다음을 선언하여 보호할 수 있습니다. .RequireAuthorization.

생성된 엔드포인트와 페이지는 권한을 일관되게 사용합니다. 백엔드 작업에는 권한이 필요할 수 있지만 생성된 Blazor UI는 권한을 로드하고, 페이지를 보호하고, 사용할 수 없는 작업을 숨기고, 프로젝트에 웹 앱이 있는 경우 사용자, 역할, 권한 및 권한 부여에 대한 화면을 노출할 수 있습니다.

Background Job이 이미 활성화된 경우 Lino는 비활성화되거나 만료된 토큰에 대한 유지 관리 루틴과 같은 사용자 토큰과 관련된 작업도 추가합니다.

백그라운드 처리 및 Outbox

백그라운드 처리는 통합 이벤트 게시, 오래된 레코드 정리, 만료된 토큰 제거, 알림 보내기, 보고서 생성, 외부 시스템과 동기화 또는 예약된 작업 실행 등 기본 요청 및 응답 흐름을 차단해서는 안 되는 작업을 처리합니다. Lino는 Background Job feature을 통해 이 feature을 추가합니다.

lino feature background-job add --service <ServiceName>

명령은 다음과 같이 실행될 수도 있습니다. lino feature background-job add 대화식으로 완료되었습니다. CLI는 별칭을 다음과 같이 노출합니다. job-scheduler 그리고 worker.

이 feature을 사용하려면 프로젝트에서 메시징을 활성화해야 합니다. 주요 책임은 Transactional Outbox 표준에 의해 등록된 메시지를 안전하게 게시하는 것이기 때문입니다.

마법사가 요구하는 것

• 서비스: Background Job 인프라가 설치되는 서비스입니다.
• Background Job 라이브러리: 작업 실행 및 예약에 사용되는 구현입니다. 현재 생성된 인프라는 Hangfire를 사용합니다.
• Outbox 처리 중: 서비스가 스케줄러에서 처리할 이벤트를 등록할지 여부를 정의합니다.
• CronOutbox메시지: 새 메시지 Outbox를 확인하는 데 사용되는 범위 또는 일정 표현식입니다.
• 배치 크기: 로드, 병렬성 및 리소스 소비를 제어하면서 주기당 검색 및 처리되는 Outbox 레코드 수입니다.

Hangfire 인프라

Lino는 Hangfire를 등록하고, 지속성을 구성하고, 대시보드를 노출하고, 서비스에서 사용되는 작업을 예약하는 데 필요한 인프라를 생성합니다. 생성된 구성에는 job 예약, Outbox 메시지 처리, 스케줄러 대시보드 접근 보호에 필요한 정보가 포함됩니다.

생성된 솔루션에서 Hangfire 스키마와 테이블은 애플리케이션 데이터베이스 구성의 일부입니다. 대시보드는 개발 및 운영 중에 완료, 실패, 예약 및 반복 작업을 검사하는 데 도움이 됩니다.

실질적인 이점으로는 안정적인 비동기 작업 실행, 내장된 모니터링 대시보드, 반복 작업 또는 예약 작업 지원, 데이터베이스 내 작업 지속성 등이 있습니다.

트랜잭션 Outbox로 처리

비동기 통합의 일관성을 보장하기 위해 Lino는 트랜잭션 Outbox 패턴을 사용합니다. 비즈니스 사용 사례는 도메인 변경 사항을 유지하고 동일한 트랜잭션 내의 Outbox 테이블에 통합 이벤트를 기록합니다. 그런 다음 Background Job은 Outbox 테이블을 읽고 프로젝트에 대해 이러한 옵션이 선택된 경우 MassTransit이 있는 RabbitMQ와 같이 구성된 메시지 버스를 통해 이벤트를 게시합니다.

1. 명령은 도메인의 상태를 변경하고 이 변경 사항을 트랜잭션에 저장합니다.
2. 핸들러는 Outbox에 통합 이벤트(예: 주문 생성과 관련된 이벤트)를 등록합니다.
3. Hangfire 작업은 처리되지 않은 메시지 일괄 처리를 차단하고 이러한 메시지를 처리 ​​중인 것으로 표시합니다.
4. 각 메시지는 이벤트 버스에 의해 역직렬화되고 게시됩니다.
5. 성공한 메시지는 처리된 것으로 표시됩니다. 실패한 메시지는 나중에 분석하거나 재시도 전략을 위해 오류 정보를 보존합니다.

그 결과 데이터베이스와 기록된 이벤트 간의 원자성, 오류 발생 시 이벤트가 손실되지 않도록 하는 안정성, 여러 소비자가 게시된 메시지를 처리할 수 있는 확장성이 구현됩니다.

생성된 작업에는 이미 성공적으로 처리된 오래된 Outbox 메시지를 제거하고 처리에 멈춘 메시지를 해제하는 루틴도 포함되어 있어 애플리케이션 실패 후 영구 잠금 위험을 줄입니다.

인증이 설치되면 Background Job feature이 토큰 유지 관리 작업을 호스팅하여 시간이 지나도 보안 데이터를 깔끔하게 유지할 수 있습니다.

이러한 추가 feature을 통해 Lino는 최신 생산 애플리케이션의 중요한 요구 사항에 맞는 강력한 보안, 세분화된 액세스 제어 및 안정적인 비동기 처리를 제공합니다.

multi-tenancy

멀티 테넌시는 동일한 애플리케이션이 각 tenant에 대해 격리된 데이터, 권한 및 구성을 유지하면서 여러 클라이언트, 조직 또는 환경에 서비스를 제공해야 할 때 사용되는 feature입니다. Lino에서는 다음과 같이 tenant 지원이 추가됩니다.

lino feature tenant add --service <ServiceName> --module <ModuleName>

명령은 다음을 사용하여 대화식으로 실행할 수도 있습니다. lino feature tenant add. CLI 분기는 다음과 같은 별칭도 노출합니다. tenancy.

전제조건

tenant 지원은 두 가지 아키텍처 feature에 따라 달라집니다.

• 인증 및 승인, 사용자 액세스, 역할, 권한 및 토큰은 tenant를 인식해야 하기 때문입니다.
• 메시징, 통합 이벤트를 통해 tenant 및 사용자 정보가 다른 모듈로 전파될 수 있기 때문입니다.

이러한 전제조건이 누락되면 명령이 거부됩니다. 이 feature은 프로젝트당 한 번만 설치할 수도 있습니다.

무엇이 생성되나요?

Lino는 tenant를 일관되게 관리하는 데 필요한 테넌시 모델, 구성, 이벤트, API 통합 및 프런트엔드 리소스를 생성합니다.

• Tenant는 tenant ID, 이름, 슬러그, 상태, 격리 모드 및 연결 문자열 참조를 저장합니다.
• TenantBranding tenant별 특정 시각적 동작에 대한 브랜딩 데이터를 저장합니다.
• TenantDomain 호스트 또는 도메인을 tenant에 매핑합니다.
• TenantStatus 그리고 IsolationMode tenant 수명 주기 및 데이터 격리 옵션을 정의합니다.
• 생성된 구성은 프로젝트의 tenant 확인과 데이터 격리를 지원합니다.

tenant 인식 보안

테넌시는 인증 및 권한 부여가 해석되는 방식을 변경합니다. 유효한 토큰과 권한은 현재 tenant의 컨텍스트 내에서 평가됩니다. 한 tenant에 액세스 권한이 있는 사용자는 자동으로 다른 tenant에 대한 액세스 권한을 받지 않습니다. 따라서 tenant 지원은 인증 흐름, 새로 고침 토큰 동작, UI에 대해 생성된 권한 및 참조를 업데이트합니다.

생성된 Blazor 애플리케이션에서는 tenant 및 인증 흐름을 관리하기 위해 tenant 인식 화면을 추가할 수 있습니다. 백엔드에서 생성된 엔드포인트는 구성된 호스트, 슬러그 또는 경로 동작에서 tenant 컨텍스트를 확인한 다음 데이터 및 권한 부여 결정에 tenant 식별자를 적용할 수 있습니다.

데이터 격리 및 전파

Lino는 엔터티가 tenant별로 소유권을 선언할 수 있도록 하여 tenant 인식 도메인 모델링을 지원합니다. SaaS 시나리오에서는 이를 통해 비즈니스 테이블이 tenant별 데이터를 저장하는 동시에 공유 모듈이 필요한 tenant 및 사용자 정보를 계속 수신할 수 있습니다.

생성된 아키텍처는 이벤트와 Outbox 패턴을 사용하여 모든 모듈을 원래 ID 또는 테넌시 테이블에 직접 연결하지 않고 모듈 간에 선택한 tenant 또는 사용자 데이터를 전파합니다. 이를 통해 모듈 경계를 명확하게 유지하는 동시에 화면, API, 권한 및 쿼리가 tenant 컨텍스트에 따라 계속 작동합니다.

테넌시를 추가한 후 영향을 받는 서비스에 대한 마이그레이션을 생성 및 적용하고 생성된 비밀 및 API 키를 검토하고 AppHost를 실행하고 두 개 이상의 tenant를 사용하여 유효성을 검사하여 데이터, 사용자, 역할, 권한 및 비즈니스 기록이 격리된 상태로 유지되는지 확인하세요.

• 격리 검증: 다른 tenant의 데이터에 액세스하려고 시도하는 테스트를 만듭니다.
• 권한 검토: 사용자는 서로 다른 tenant에서 서로 다른 역할을 가질 수 있습니다.
• 고객을 신뢰하지 마십시오. 경로, 호스트, 슬러그 또는 헤더로 정보를 받는 tenant는 인증된 사용자와 호환되어야 합니다.