SDF Identifier-based License Common Model
| Author | Date | Change log |
|---|---|---|
| Joseonwoo | 2026-02-02 | First Draft |
1. Purpose
SDF (Sensitive Docs Flow) is an integrated document security processing service that is called to encrypt and decrypt documents in business systems.
In the existing operational structure, the following issues existed.
- Due to server (App) unit operation, it is difficult to trace the caller in a container environment.
- The policy/log/billing criteria are inconsistent and server-centric.
- The scope of the license and the API call authentication elements are mixed, causing operational confusion.
Therefore, this document outlines the SDF operational standards.IdentifierDefines a structure that transitions to a center.
It is the common operational standard of the SDF license and the overarching standard for the Container/App/Hybrid documents.
2. Transition of Operational Standards
SDF shifts the operational standard unit from a server-centric model to a business unit identifier-centric model.
| division | Existing (Server-Centric) | After Change (Identifier-Centric) |
|---|---|---|
| Operating Standards | Server/App Unit | Work Unit Identifier |
| Policy Application | Document Property Center | Identifier-based policies |
| Log Tracking | Result-Oriented | Identifier-based Tracking |
| Billing Criteria | Server Unit Estimation | Clarification of Work Units |
In other words, the identifier becomes the central axis of SDF operations.
3. Definition of Key Concepts
The SDF operating model clearly separates the following three elements.
3.1 License Key
The license key is a key that activates the scope of customer use.
- Activates the tenant's permissions.
- Determines the number of allowed identifiers.
- In the app environment, it determines the number of allowed servers.
3.2 Identifier
Identifiers are the criteria for the actual operation of business units.
- It is divided by business purpose. (e.g., electronic approval, approval withdrawal)
- It will serve as the criteria for policy application.
- It serves as a log tracking criterion.
- It will serve as the basis for gratitude and billing.
※ An identifier is a value used to distinguish business units and is not used to differentiate Container/App execution environments.
3.3 Access Key (Access Key, AK)
The access key (AK) is the authentication key (Secret) for SDF API calls.
- Prove who called.
- It is used as an authentication method for external business systems.
- Managed separately from the license.
The access key is an element of "caller subject authentication."
[Appendix 1] Comparison of Key Concepts: Identifier / Document ID / Document Grade
In SDF operations, in addition to the "identifier," there are concepts such as document ID for document-level tracking and document classification for security control.
The three concepts have different purposes and application criteria, so they should not be confused.
| division | Identifier | Document ID | Document Grade |
|---|---|---|---|
| Management Purpose | Classification of Business System Purposes | Individual Document Tracking | Grade-Based Document Control |
| Usage Criteria | License, Policy, Conditional Policy, Log Management | Document History and Security Tracking | Document History and Security Tracking |
| Creation Time | When requesting SDF conversion | When creating a document | When creating a document |
| Maintenance Scope | Entire Document Lifecycle (Metadata-Based) | Entire Document Lifecycle | Entire Document Lifecycle |
| Document Inclusion 여부 | X (Operational Metadata) | O | O |
| Role Summary | Operational Management Standards | Tracking Criteria | Security Level Criteria |
In other words, SDF isDistinguish work units based on identifiers and, license, conditional policies, and log management are applied consistently.
4. API Request Structure Standards
When calling the SDF API, the following two values must be passed together. Calls without an Identifier are not allowed as they do not establish policies/logs/billing criteria.
Access Key (AK) : 호출 주체 인증
Identifier : 업무 구분
※ The API header field names follow system standards, so they are kept in English.
5. SDF Internal Processing Flow (Identifier-Based)
SDF processes requests in the following order.
- It verifies the access key (AK) to determine whether the call is allowed.
- Validates the identifier to check if it is within the license scope.
- Apply identifier-based conditional policies.
- Performs document encryption and decryption processing.
- Records identifiers in logs and document headers.
As a result,
- Policy Operation
- Audit Trail
- Billing Criteria
Everything is integrated around identifiers.
6. Identifier Operation Policy
6.1 Creation Criteria
It is recommended to generate identifiers based on business unit criteria.
Example:
- Electronic Approval
- Approval Export
- External Collaboration Document
We provide guidance to prevent the excessive generation of identifiers.
6.2 Creation Permission
Identifier creation and management is restricted to Org Admin and higher permissions.
6.3 Identifier Structure
Identifiers have the following structure for user-friendliness and system stability.
- Display Name: This is the task name entered by the user.
- Identifier Code: A unique code (GUID) automatically generated by the system.
Users only need to recognize the Display Name, while the Identifier Code is managed by the system.
7. Access Control System (RBAC)
Each administrator's operational authority is classified as follows according to their area of responsibility.
| role | Permission Scope |
|---|---|
| Master Administrator | License key registration/change, user/permission management, access key (AK) original text inquiry/reissuance |
| Operations Manager | Identifier creation/management, business system registration, access key (AK) status management |
| Query Manager | Policy Management, Log Viewing |
[Appendix 2] Detailed Table of Operational Structure by Permission Type
| division | Master Administrator | Operations Manager | Query Manager | Maintenance Manager |
|---|---|---|---|---|
| Role Scope | Overall Operation of SDF Service | Responsibilities for System Operation | View Operating Status (Read-Only) | Performing Maintenance |
| Management Target | Overall Work System | Responsibilities System | None | All |
| Identifier Management | O (Full Create/Delete) | X | X | △ (Query) |
| Policy Settings | O (Overall Policy) | O (Responsibilities System) | X | △ (Query) |
| Log Inquiry | O (All) | O (Responsibilities System) | O (Scope of Responsibility) | O (All) |
| Dashboard | O (All) | O (Responsibilities System) | O (Scope of Responsibility) | O (All) |
| Log/Dashboard Export | O | O | X | O |
| Integration System Management | O | O (Responsibilities System) | X | X |
| License Management | O | X | X | X |
| Server Management (App Environment) | O (All) | O (Scope of Responsibility) | X | △ (Query) |
| Admin Permission Management | O | X | X | X |
※ Only in the app environment “Server Management"Features will be added. In a container environment, the concept of a server does not exist."
8. Basic Direction of Migration
The following policy applies when upgrading existing customers.
- Automatically generates 1 basic identifier.
For example:
Legacy-Default - Existing logs and operational data are attributed to the primary identifier.
- Customers can create additional identifiers by task to gradually separate them.
Examples of transition guidance phrases are as follows.
"Transitioned to identifier-based operation. The primary identifier has been automatically generated. Please add additional identifiers for each task."
9. Summary
The identifier-based operational model is a key transformation to integrate the policy/log/tracking/billing system of SDF by business unit.
This document defines the operational standards, and the subsequent document implements them in the UI.
This document is the top-level document defining the SDF operational standards, and subsequent documents will be expanded as follows according to the operational methods by environment.
[Appendix 3] Differences in License Application by Environment
SDF's licensing criteria vary depending on the execution environment.
| division | Container Environment | App(On-Prem) Environment |
|---|---|---|
| Server Concept | None | exists |
| Limit Criteria | Limit only the number of identifiers | Identifier count + server count limit |
| Server Registration | unnecessary | Required (Key-based verification method recommended) |
| Operating Standards | Identifier-Centric Operations | Identifier-centric + Server reference |
| Reason for Application | Pod Autoscaling | Installation Scale and Cost Control |