KR102535012B1 - Method Authorizing Access to Service Based on Microservice - Google Patents
Method Authorizing Access to Service Based on Microservice Download PDFInfo
- Publication number
- KR102535012B1 KR102535012B1 KR1020220132107A KR20220132107A KR102535012B1 KR 102535012 B1 KR102535012 B1 KR 102535012B1 KR 1020220132107 A KR1020220132107 A KR 1020220132107A KR 20220132107 A KR20220132107 A KR 20220132107A KR 102535012 B1 KR102535012 B1 KR 102535012B1
- Authority
- KR
- South Korea
- Prior art keywords
- role
- user
- access
- function
- service
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 57
- 238000012217 deletion Methods 0.000 claims description 33
- 230000037430 deletion Effects 0.000 claims description 33
- 238000013507 mapping Methods 0.000 claims description 29
- 230000008569 process Effects 0.000 claims description 27
- 238000013475 authorization Methods 0.000 claims description 18
- 238000012790 confirmation Methods 0.000 claims description 11
- 239000000284 extract Substances 0.000 claims description 11
- 238000010586 diagram Methods 0.000 description 30
- 238000012546 transfer Methods 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012958 reprocessing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/105—Multiple levels of security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
Abstract
Description
본 발명의 일 실시예는 마이크로서비스 기반의 서비스 접근 권한 부여 방법에 관한 것이다. An embodiment of the present invention relates to a microservice-based service access authorization method.
이하에 기술되는 내용은 단순히 본 실시예와 관련되는 배경 정보만을 제공할 뿐 종래기술을 구성하는 것이 아니다.The contents described below merely provide background information related to the present embodiment and do not constitute prior art.
마이크로서비스는 소프트웨어가 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식이다. 마이크로서비스 아키텍처는 애플리케이션의 확장을 용이하게 하고 개발 속도를 앞당겨 혁신을 실현하고 새로운 기능의 출시 시간을 단축할 수 있다.Microservices are an architectural and organizational approach for software development where the software consists of small, independent services that communicate through defined APIs. A microservices architecture can facilitate application scalability and accelerate development to enable innovation and reduce time-to-market for new features.
모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 따라서, 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해진다. 복잡성으로 인해 실험에 제한을 받고 새로운 아이디어를 구현하기가 어려워지는 문제가 있다. 종속 관계를 이루며 긴밀하게 결합된 많은 프로세스로 인해 단일 프로세스의 실패로 인한 영향이 증가함에 따라 모놀리식 아키텍처는 애플리케이션 가용성에 대한 위험을 가중시킨다.In a monolithic architecture, all processes are tightly coupled and run as a single service. Therefore, when the demand for one process in an application spikes, the entire architecture must be scaled. Adding or improving functionality to a monolithic application becomes more complex as the code base grows. Complexity limits experimentation and makes it difficult to implement new ideas. Monolithic architectures increase the risk to application availability, as the impact of a single process failure increases due to many closely coupled processes with dependencies.
종래의 네트워크 디바이스는 대부분 사용자별로 서비스 접근 권한을 제공하지 않고 단지 CLI에 모드를 분리하여 모드별로 실행할 수 있는 명령어 셋(Set)만 다르게 제공하였다. 예컨대, CLI를 Standard 모드, Enable 모드, Configure 모드 3가지로 나누고, 각 모드별로 실행할 수 있는 명령어를 다르게 제공하여 사용자별로 서비스 접근 권한 제어가 불가능하였다.Most of the conventional network devices do not provide service access rights for each user, but only separate modes in CLI and provide different sets of commands that can be executed for each mode. For example, the CLI is divided into three modes: Standard mode, Enable mode, and Configure mode, and different commands that can be executed for each mode are provided, making it impossible to control service access rights for each user.
종래의 서비스 접근 권한을 제공 방식은 GUI 환경에서는 적용할 수 없는 방법이므로 GUI에서는 사용자별로 접근할 수 있는 페이지를 설정하거나 하여 서비스에 대한 접근 권한을 CLI와 다르게 일관성 없이 제공하는 문제가 있다.Since the conventional method of providing service access rights is not applicable in a GUI environment, there is a problem in that the GUI provides access rights to services inconsistently, unlike the CLI, by setting a page accessible to each user in the GUI.
본 실시예는 공통된 서비스를 그룹화하여 함수 그룹으로 생성하고, 함수 그룹별 접근 권한 셋의 리스트를 갖고 있는 롤(Role)을 생성하고, 롤을 사용자에게 부여하여 함수 그룹별로 사용자가 편리하게 접근권한을 갖도록 하며, 롤을 복수의 사용자에게 중복 할당하여 복수의 사용자가 손쉽게 동일한 접근 권한을 부여받도록 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법을 제공하는 데 목적이 있다.In this embodiment, a function group is created by grouping common services, a role having a list of sets of access rights for each function group is created, and the role is granted to a user so that the user can conveniently grant access rights for each function group. Its purpose is to provide a microservice-based service access authorization method that allows multiple users to easily receive the same access privileges by assigning roles to multiple users repeatedly.
본 실시예는 서브 식별자(Sub-identifier) 기반 접근 권한 할당을 이용하여 함수 그룹 내부에 일부 서브 식별자에 대해서만 접근 허용을 설정할 수 있어서 함수 그룹 전체가 아닌 함수 그룹 내 일부 서브 식별자에 대해서만 접근을 허용할 수 있도록 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법을 제공하는 데 또다른 목적이 있다.In this embodiment, access can be set for only some sub-identifiers within a function group using sub-identifier-based access rights assignment, so that access is allowed only for some sub-identifiers within the function group rather than the entire function group. Another purpose is to provide a microservice-based service access authorization method that enables
본 실시예의 일 측면에 의하면, 사용자 매니저에서 사용자 인증을 수행한 클라이언트로 액세스 토큰(Access token)을 발행하는 과정; 상기 클라이언트에서 상기 액세스 토큰을 첨부하여 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트로 서비스 호출 메시지를 전송하는 과정; 상기 서비스를 담당하는 컴포넌트에서 상기 사용자 매니저로부터 상기 액세스 토큰에 매칭된 롤(role)을 확인하는 과정; 상기 서비스를 담당하는 컴포넌트에서 상기 롤에 매칭된 접근권한(Access Right)을 확인하는 과정; 상기 서비스를 담당하는 컴포넌트에서 상기 롤에 매칭된 접근권한이 기 설정된 요구 접근권한(Required Access Right) 이상인 지의 여부를 확인하여 확인 결과를 생성하는 과정; 상기 확인 결과에 따라 상기 서비스를 담당하는 컴포넌트에서 상기 클라이언트가 접근하도록 접근 권한을 부여하는 과정;을 포함하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법을 제공한다.According to one aspect of this embodiment, the process of issuing an access token (Access token) from the user manager to the client that performed the user authentication; attaching the access token to the client and transmitting a service call message to a component in charge of a service among a plurality of components subdivided according to an internal function of a micro-service architecture; checking a role matched to the access token from the user manager in a component in charge of the service; checking an access right matched to the role in a component in charge of the service; generating a confirmation result by checking whether or not the access right matched to the role in the component in charge of the service is greater than or equal to a preset required access right; Provides a microservice-based service access authorization method comprising the step of granting access authorization for the client to access in a component in charge of the service according to the confirmation result.
이상에서 설명한 바와 같이 본 실시예에 의하면, 공통된 서비스를 그룹화하여 함수 그룹으로 생성하고, 함수 그룹별 접근 권한 셋의 리스트를 갖고 있는 롤(Role)을 생성하고, 롤을 사용자에게 부여함으로써 사용자에게 함수 그룹별로 접근권한을 편리하게 부여할 수 있도록 하며, 롤을 생성한 후 복수의 사용자에게 중복 할당하여 복수의 사용자가 손쉽게 동일한 접근 권한을 부여받도록 하는 효과가 있다.As described above, according to the present embodiment, a function group is created by grouping common services, a role having a list of access authority sets for each function group is created, and a role is granted to a user, thereby providing a function to the user. It is possible to conveniently grant access rights by group, and after creating a role, there is an effect of repeatedly assigning the same access rights to a plurality of users.
본 실시예에 의하면, 서브 식별자(Sub-identifier) 기반 접근 권한 할당을 이용하면 함수 그룹 내부에 일부 서브 식별자에 대해서만 접근 허용을 설정할 수도 있어서 함수 그룹 전체가 아닌 함수 그룹 내 일부 서브 식별자에 대해서만 접근을 허용할 수 있도록 하는 효과가 있다.According to the present embodiment, if sub-identifier-based access authority assignment is used, access can be set only for some sub-identifiers inside the function group, so that access is granted only to some sub-identifiers within the function group rather than the entire function group. It has the effect of making it acceptable.
본 실시예에 의하면, 관리 인터페이스와 무관하게 일관성 있게 사용자별로 동일한 서비스 접근을 제어할 수 있는 효과가 있다.According to the present embodiment, it is possible to control access to the same service for each user consistently regardless of the management interface.
도 1은 본 실시예에 따른 마이크로서비스 기반의 네트워크 디바이스 아키텍쳐를 나타낸 도면이다.
도 2는 본 실시예에 따른 사용자 매니저와 SCS에서 제공하는 RPC 함수를 나타낸 도면이다.
도 3은 본 실시예에 따른 컴포넌트들에서 제공하는 RPC 함수와 각 함수가 소속된 함수 그룹, 요구 접근권한, 외부 공개여부를 나타낸 도면이다.
도 4는 본 실시예에 따른 사용자 매니저에서 정의한 롤에 대한 함수 그룹과 접근권한 셋을 나타낸 도면이다.
도 5는 본 실시예에 따른 사용자 매니저에서 생성한 사용자별 롤 할당을 나타낸 도면이다.
도 6a,6b,6c,6d는 본 실시예에 따른 서비스 호출시 접근 권한이 없어서 거부되는 경우의 함수 호출 과정을 나타낸 도면이다.
도 7a,7b,7c,7d는 본 실시예에 따른 서비스 호출시 접근 권한이 허용되는 경우의 함수 호출 과정을 나타낸 도면이다.
도 8은 본 실시예에 따른 SCS의 함수 그룹, 서브 식별자, 접근가능 롤을 나타낸 도면이다.
도 9a,9b,9c,9d는 본 실시예에 따른 서브 식별자 기반의 접근 권한 확인 후 거부되는 경우의 함수 호출 과정을 나타낸 도면이다.
도 10은 본 실시예에 따른 SCS의 함수 그룹, 서브 식별자, 접근가능 롤을 나타낸 도면이다.
도 11a,11b,11c,11d는 본 실시예에 따른 서브 식별자 기반의 접근 권한 확인 후 허용되는 경우의 함수 호출 과정을 나타낸 도면이다.
도 12는 본 실시예에 따른 접근 권한 부여 방법을 설명하기 위한 순서도이다.
도 13a,13b,13c,13d,13e는 본 실시예에 따른 사용자 정보의 업데이트, 삭제 또는 롤 정보를 업데이트시 함수 호출 과정을 나타낸 도면이다.
도 14a,14b,14c,14d는 본 실시예에 따른 롤 정보 삭제 거부 시나리오 1에 대한 함수 호출 과정을 나타낸 도면이다.
도 15a,15b,15c,15d,15e는 본 실시예에 따른 롤 정보 삭제 거부 시나리오 2에 대한 함수 호출 과정을 나타낸 도면이다.
도 16a,16b,16c,16d,16e,16f는 본 실시예에 따른 롤 정보 삭제 허용 시나리오 3에 대한 함수 호출 과정을 나타낸 도면이다.1 is a diagram showing a microservice-based network device architecture according to this embodiment.
2 is a diagram illustrating an RPC function provided by a user manager and an SCS according to the present embodiment.
3 is a diagram showing RPC functions provided by components according to the present embodiment, function groups to which each function belongs, requested access rights, and whether or not they are open to the outside world.
4 is a diagram showing function groups and access right sets for roles defined in the user manager according to the present embodiment.
5 is a diagram illustrating role assignment for each user created by the user manager according to the present embodiment.
6a, 6b, 6c, and 6d are diagrams illustrating a process of calling a function when a service call is denied due to lack of access authority according to the present embodiment.
7a, 7b, 7c, and 7d are diagrams illustrating a function call process when access authority is allowed when calling a service according to the present embodiment.
8 is a diagram illustrating function groups, sub identifiers, and accessible roles of the SCS according to the present embodiment.
9a, 9b, 9c, and 9d are diagrams illustrating a function call process in the case of rejection after checking access rights based on sub-identifiers according to the present embodiment.
10 is a diagram showing function groups, sub identifiers, and accessible roles of SCS according to this embodiment.
11a, 11b, 11c, and 11d are diagrams illustrating a function call process when permission is granted after checking access rights based on sub-identifiers according to the present embodiment.
12 is a flowchart for explaining a method for granting access authority according to this embodiment.
13a, 13b, 13c, 13d, and 13e are diagrams illustrating a process of calling a function when updating or deleting user information or updating role information according to the present embodiment.
14a, 14b, 14c, and 14d are diagrams illustrating a process of calling a function for role information
15a, 15b, 15c, 15d, and 15e are diagrams illustrating a process of calling a function for role information
16a, 16b, 16c, 16d, 16e, and 16f are diagrams illustrating a process of calling a function for role information
이하, 본 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.Hereinafter, this embodiment will be described in detail with reference to the accompanying drawings.
도 1은 본 실시예에 따른 마이크로서비스 기반의 네트워크 디바이스 아키텍쳐를 나타낸 도면이다.1 is a diagram showing a microservice-based network device architecture according to this embodiment.
마이크로서비스 아키텍처의 경우, 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 전술한 서비스는 경량 API를 사용하여 기 정의된 인터페이스를 이용하여 통신한다. 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행한다. 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.In a microservices architecture, applications are built as independent components, with each application process running as a service. The aforementioned service communicates using a predefined interface using a lightweight API. Services are built for business functions, and each service performs one function. Because services run independently, each service can be updated, deployed, and scaled to meet the demands of a specific function in an application.
본 실시예에 따른 네트워크 패킷 브로커라는 네트워크 장비에서 마이크로 서비스라는 아키텍처로 구성된다.A network equipment called a network packet broker according to the present embodiment is composed of an architecture called a microservice.
본 실시예에 따른 마이크로 서비스 아키텍처는 내부 기능에 따라 세분화한 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126))를 포함한다.The microservice architecture according to this embodiment includes a plurality of components subdivided according to internal functions (
복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 각각은 API(Application Programming Interface)를 이용하여 특정 서비스를 제공한다. 여기서, API는 애플리케이션이나 디바이스가 서로 간에 연결하여 통신할 수 있는 방법을 정의하는 규칙 세트를 의미한다. REST API 또는 RESTful API는 REST(REpresentational State Transfer) 아키텍처 스타일의 디자인 원칙을 준수하는 API를 의미한다.Each of the plurality of components (
복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 각각은 호출할 수 있는 기능을 외부에 API 형태로 노출 시킨다. 결과적으로 추가되는 기능들을 외부에서 API를 이용하여 호출만 하면은 해당 기능을 사용할 수 있다.Each of a plurality of components (
본 실시예에 따른 마이크로서비스 기반의 네트워크 디바이스 아키텍쳐는 클라이언트(110), 시스템(120)을 포함한다. 마이크로서비스 기반의 네트워크 디바이스 아키텍쳐에 포함된 구성요소는 반드시 이에 한정되는 것은 아니다.The microservice-based network device architecture according to this embodiment includes a
네트워크 디바이스는 네트워크 패킷 브로커, 네트워크 스위치 등을 포함하는 네트워크 장치를 의미한다. A network device refers to a network device including a network packet broker, network switch, and the like.
클라이언트(110)가 프록시로 서비스를 호출하면 프록시는 호출된 메시지를 분석하여 해당 서비스를 담당하고 있는 컴포넌트를 찾고 해당 컴포넌트가 처리할 수 있는 형태로 가공하여 메시지를 전달한다. 메시지를 전달받은 컴포넌트는 요청 메시지를 처리한 후 프록시로 결과를 응답한다.When the
클라이언트(110)는 REST(Representational State Transfer) API(Application Programming Interface) 또는 RPC 프로토콜을 직접 호출하는 애플리케이션 형태일 수도 있다. 클라이언트(110)는 관리 웹사이트에 접속하는 웹 브라우저 형태일 수도 있다. 클라이언트(110)는 SSH(Secure Shell) 또는 Telnet에 접속하는 터미널 형태일 수도 있다.The
클라이언트(110)는 네트워크 디바이스를 설정하는 고객을 의미한다. 본 실시예에 따른 클라이언트(110)는 애플리케이션(112), 브라우저(114), 터미널(116)을 포함한다. 클라이언트(110)에 포함된 구성요소는 반드시 이에 한정되는 것은 아니다.The
애플리케이션(112)은 실질적으로 RPC(Remote Procedure Call) 인터페이스를 직접 호출을 하는 주체이다. 애플리케이션(112)은 REST 또는 RPC 인터페이스를 다이렉트하게 호출한다. The
애플리케이션(112)이 RPC 인터페이스를 이용하여 특정 함수를 호출하면, 시스템(120) 내의 복수의 모듈로 호출이 들어온다. 프록시가 호출을 받아가지고 시스템(120) 내의 복수의 모듈로 라우팅한다.When
브라우저(114)는 관리 웹을 이용하는 웹브라우저를 의미한다.The
터미널(116)은 SSH(Secure Shell) 또는 Telnet을 이용하여 터미널 서비스를 제공할 때, 커맨드를 이용해서 설정할 수 있는 장비를 의미한다.The terminal 116 means a device that can be set using a command when providing a terminal service using Secure Shell (SSH) or Telnet.
클라이언트(110)는 액세스 토큰을 이용하여 서비스 담당 컴포넌트로 함수 그룹(Function Group)에 대한 서비스 호출 메시지를 전송한다.The
본 실시예에 따른 시스템(120)은 복수의 컴포넌트를 포함한다.
복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 각각은 설정을 저장하거나 적용하기 위해 수행해야 하는 별도의 작업이 없다.Each of a plurality of components (
복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 각각에서 제공하는 RPC를 이용하여 네트워크 디바이스에 설정을 추가, 삭제, 업데이트할 수 있다.A plurality of components (
본 실시예에 따른 시스템(120)은 컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126), 프록시, 웹, SSH를 포함한다. 시스템(120)에 포함된 구성요소는 반드시 이에 한정되는 것은 아니다.The
본 실시예에 따른 시스템(120) 내의 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 각각은 독립적으로 원하는 형태의 DB를 소유할 수 있다. A plurality of components (
시스템(120) 내의 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 각각은 설정을 조회하거나 적용하기 위한 공통된 이름의 RPC(Remote Procedure Call)를 제공한다. 여기서, RPC는 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간(Remote)의 함수나 프로시저를 호출할 수 있게 하는 프로세스 간 통신 기술을 의미한다.Each of a plurality of components (
시스템(120) 내의 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 각각은 서버 역할을 수행한다.Each of a plurality of components (
시스템(120) 내의 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 각각은 RPC 인터페이스를 제공한다.Each of a plurality of components (
외부 장비 입장에서는 시스템(120) 내의 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126))가 갖고 있는 서버 어드레스나 포트를 파악하기에 어려움이 존재하므로 프록시를 이용한다. From the point of view of external equipment, a plurality of components (
시스템(120) 내 컴포넌트 사이에도 서로 RPC 호출이 발생할 수 있다. 시스템(120) 내 컴포넌트 사이에도 서로 RPC 호출 발생시 직접 서비스를 호출할 수도 있으나 편의상 프록시를 거쳐서 서비스 호출을 수행한다.RPC calls may also occur between components within
마이크로서비스 기반의 네트워크 디바이스 아키텍쳐는 도 1에 도시된 바와 같다. 마이크로서비스 기반의 네트워크 디바이스 내부는 다양한 서비스를 제공하는 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126))를 포함한다.The microservice-based network device architecture is as shown in FIG. Inside the microservice-based network device, a plurality of components (
복수의 컴포넌트 각각은 필요에 따라 내부에 다양한 형태의 DB나 장치 또는 파일을 소유할 수 있다. 복수의 컴포넌트 각각은 외부로 RPC(Remote Procedure Call) 인터페이스를 제공하여 서비스를 제공한다. 복수의 컴포넌트 각각이 제공하는 RPC 인터페이스는 다양한 주소와 프로토콜을 가질 수 있기 때문에 직접 노출하여 서비스하기 보다는 프록시로 게이트웨이를 구축하여 서비스한다.Each of the plurality of components may have various types of DBs, devices, or files therein as needed. Each of the plurality of components provides a service by providing an RPC (Remote Procedure Call) interface to the outside. Since the RPC interface provided by each of the plurality of components can have various addresses and protocols, a gateway is constructed as a proxy rather than directly exposed and serviced.
프록시는 시스템(120) 내의 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126))가 갖고 있는 어드레스나 포트를 내외부 장비로 전달 및 연결한다. 프록시는 응답 메시지를 클라이언트(110)가 처리할 수 있는 형태로 재가공하여 메시지를 응답한다.A proxy is a number of components (
Web 브라우저(114)를 이용하여 시스템(120) 내의 복수의 모듈로 접속하면, 시스템(120) 내의 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126))에 대한 프록시를 호출한다. SSH를 이용해서 호출된 서비스도 커멘드 해석 쉘(126)이 받아서, 프록시를 호출한다. When a plurality of modules in the
컨피그 매니저(121)는 각 컴포넌트에서 설정을 조회하기 위한 RPC(*Show())의 호출을 통해서 설정을 저장할 수 있다. 컨피그 매니저(121)는 설정을 적용하기 위한 RPC(*Update() 등)의 호출을 통해서 설정을 적용할 수 있다.The
컨피그 매니저(121)는 새로운 기능이 필요할 때마다 새로운 마이크로 서비스를 하나씩 프록시로 업로드한 후 새로운 마이크로 서비스에서 요구하는 기능들을 API 형태로 제공하는 구조를 갖는다. 컨피그 매니저(121)는 네트워크 디바이스 설정을 저장 또는 적용하는 경우 클라이언트(110)로부터 프록시를 경유해서 설정값을 수신한다.The
사용자 매니저(122)는 사용자와 사용자별 서비스 접근 권한을 관리하고 또한 사용자를 인증하는 컴포넌트를 의미한다. 사용자 매니저(122)는 사용자 인증, 사용자 생성, 사용자 권한 부여를 수행한다. 사용자 매니저(122)는 사용자 계정별로 롤을 할당한다. The
사용자 매니저(122)는 서비스 담당 컴포넌트로부터 수신한 토큰명을 기반으로 매칭된 사용자명을 체크한다. 사용자 매니저(122)는 사용자명을 기반으로 매칭되어 있는 기 정의된 롤을 체크한다. 사용자 매니저(122)는 롤들이 갖고 있는 함수 그룹별 접근권한들을 체크한다. 사용자 매니저(122)는 함수 그룹별 접근권한 중 가장 높은 접근권한을 전송한다.The
사용자 매니저(122)는 사용자 인증을 수행한 클라이언트(110)로 액세스 토큰을 발행한다.The
사용자 매니저(122)는 클라이언트(110)로부터 수신된 사용자 이름(Username), 패스워드(password)가 인증되는 경우, 클라이언트(110)에 대한 액세스 토큰을 발행하고, 액세스 토큰에 사용자 이름에 대응하는 사용자 정보를 매핑하여 자신의 캐시에 저장한다.When the user name and password received from the
사용자 매니저(122)는 서비스 담당 컴포넌트로부터 액세스 토큰, 함수 그룹을 수신하고, 자신의 캐시에 기 저장된 정보를 기반으로 액세스 토큰, 함수 그룹에 대응하는 접근권한과 롤 리스트가 존재하는 지의 여부를 확인한 확인 결과를 생성한다.The
사용자 매니저(122)는 캐시에 기 저장된 정보를 기반으로 액세스 토큰, 함수 그룹에 대응하는 접근권한과 롤 리스트가 존재하는 경우, 함수 그룹에 대응하는 접근권한과 롤 리스트를 서비스 담당 컴포넌트로 전송한다.The
사용자 매니저(122)는 클라이언트(110)로부터 사용자 업데이트 함수, 사용자 삭제 함수, 롤 업데이트 함수 중 어느 하나의 함수가 호출되면, 자신의 캐시에서 사용자 업데이트, 사용자 삭제, 롤 업데이트 중 어느 하나가 발생한 정보를 삭제한다. 사용자 매니저(122)는 복수의 컴포넌트로 사용자 업데이트, 사용자 삭제, 롤 업데이트 중 어느 하나가 발생한 정보를 삭제하라고 지시한다.When any one of a user update function, a user delete function, and a role update function is called from the
사용자 매니저(122)는 클라이언트(110)로부터 롤 삭제 함수가 호출되면, 자신의 캐시에서 롤 삭제 함수에 대응하는 삭제 대상 롤을 매핑하고 있는 사용자가 있는지의 여부를 조회한다. 사용자 매니저(122)는 조회 결과, 삭제 대상 롤을 매핑하고 있는 사용자가 존재하는 경우, 삭제 대상 롤에 대한 삭제를 거부하고 클라이언트(110)로 오류를 응답한다.When the role deletion function is called from the
사용자 매니저(122)는 클라이언트로부터 롤 삭제 함수가 호출되면, 자신의 캐시에서 롤 삭제 함수에 대응하는 삭제 대상 롤을 매핑하고 있는 사용자가 있는지의 여부를 조회한다. 사용자 매니저(122)는 조회 결과, 삭제 대상 롤을 매핑하고 있는 사용자가 미존재하는 경우, 삭제 대상 롤을 매핑하고 있는 복수의 다른 컴포넌트가 존재하는 지의 여부를 확인한다. 사용자 매니저(122)는 확인 결과, 삭제 대상 롤을 매핑하고 있는 다른 컴포넌트가 존재하는 경우, 삭제 대상 롤에 대한 삭제를 거부하고 클라이언트로 오류를 응답한다.When the role deletion function is called from the client, the
사용자 매니저(122)는 클라이언트(110)로부터 롤 삭제 함수가 호출되면, 자신의 캐시에서 롤 삭제 함수에 대응하는 삭제 대상 롤을 매핑하고 있는 사용자가 있는지의 여부를 조회한다. 사용자 매니저(122)는 조회 결과, 삭제 대상 롤을 매핑하고 있는 사용자가 미존재하는 경우, 삭제 대상 롤을 매핑하고 있는 복수의 다른 컴포넌트가 존재하는 지의 여부를 확인한다. 사용자 매니저(122)는 확인 결과 삭제 대상 롤을 매핑하고 있는 다른 컴포넌트가 미존재하는 경우, 삭제 대상 롤을 삭제한다.When the role deletion function is called from the
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 중 서비스를 담당하는 컴포넌트는 클라이언트(110)가 서비스를 호출하면 클라이언트(110)가 호출한 서비스에 대한 접근권한을 확인하기 위해서 사용자 매니저(122)로 액세스 토큰, 함수 그룹명을 파라미터로 첨부하여 사용자 접근권한 요청 메시지를 전송한다.Multiple components subdivided according to the internal functions of the micro-service architecture (
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 중 서비스를 담당하는 컴포넌트는 사용자 매니저(122)로부터 액세스 토큰에 매칭된 롤(role)을 확인한다. 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 함수 그룹 및 롤에 매칭된 접근권한(Access Right)을 확인한다.Multiple components subdivided according to the internal functions of the micro-service architecture (
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 중 서비스를 담당하는 컴포넌트는 함수 그룹 및 롤에 매칭된 접근권한이 기 설정된 요구 접근권한(Required Access Right) 이상인 지의 여부를 확인하여 확인 결과를 생성한다. 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 확인 결과에 따라 클라이언트(110)를 함수 그룹으로 접근하도록 하는 접근 권한을 부여한다.Multiple components subdivided according to the internal functions of the micro-service architecture (
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 서비스 호출 메시지로부터 액세스 토큰, 함수 그룹, 서브 식별자를 추출하고 사용자 매니저로 액세스 토큰, 함수 그룹을 전송한다.Among a plurality of components subdivided according to the internal function of the micro-service architecture, the component responsible for the service extracts the access token, function group, and sub identifier from the service call message and transmits the access token and function group to the user manager.
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 함수 그룹에 대응하는 접근권한이 해당 컴포넌트에 기 설정된 요구 접근권한 이상인지를 확인한 확인 결과를 생성한다.Among a plurality of components subdivided according to the internal functions of the micro-service architecture, a component in charge of a service generates a confirmation result confirming whether the access right corresponding to the function group is greater than or equal to the access right set in advance for the corresponding component.
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 함수 그룹에 대응하는 접근권한이 해당 컴포넌트에 기 설정된 요구 접근권한 이상인 경우 클라이언트(110)를 함수 그룹으로 접근하도록 접근 권한을 부여한다.Among a plurality of components subdivided according to the internal function of the micro-service architecture, a component in charge of a service allows the
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 함수 그룹에 대응하는 접근권한이 해당 컴포넌트에 기 설정된 요구 접근권한 미만인 경우, 서비스 호출 메시지로부터 추출한 서브 식별자가 롤 리스트에 포함된 복수의 접근가능 롤 중 어느 하나에 대응하는 것으로 확인되면, 클라이언트(110)가 함수 그룹에 대응하는 컴포넌트로 접근하는 것을 허용한다.Among a plurality of components subdivided according to the internal functions of the micro-service architecture, if the access authority corresponding to the function group of the component in charge of the service is less than the required access authority preset for the corresponding component, the sub identifier extracted from the service call message is the role list If it is confirmed that it corresponds to any one of the plurality of accessible roles included in , the
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 함수 그룹에 대응하는 접근권한이 해당 컴포넌트에 기 설정된 요구 접근권한 미만인 경우, 서비스 호출 메시지로부터 추출한 서브 식별자가 롤 리스트에 포함된 복수의 접근가능 롤 중 대응되는 롤이 없는 것으로 확인되면, 클라이언트(110)가 함수 그룹에 대응하는 컴포넌트로 접근하는 것을 거부한다.Among a plurality of components subdivided according to the internal functions of the micro-service architecture, if the access authority corresponding to the function group of the component in charge of the service is less than the required access authority preset for the corresponding component, the sub identifier extracted from the service call message is the role list If it is confirmed that there is no corresponding role among the plurality of accessible roles included in , the
로그 매니저(123)는 전체 애플리케이션의 로그를 관리하는 컴포넌트를 의미한다. The
SCS(124)는 네트워크 디바이스에 데이터 플레인의 기능을 정의한다. SCS(124)는 데이터 플레인과 상호 작용하여 네트워크 디바이스의 필수 기능을 제공한다.
시스템 매니저(125)는 방화벽, 관리 인터페이스, NTP, SNMP 등의 시스템 관리를 수행한다. 커멘드 해석 쉘(126)은 터미널 클라이언트에게 제공하는 CLI(Command Line Interface) 컴포넌트를 의미한다.The
도 2는 본 실시예에 따른 사용자 매니저와 SCS에서 제공하는 RPC 함수를 나타낸 도면이다.2 is a diagram illustrating an RPC function provided by a user manager and an SCS according to the present embodiment.
사용자 매니저(122)와 SCS(124)에서 제공하는 RPC 함수는 도 2에 도시된 바와 같다. 사용자 매니저(122)와 SCS(124)에서 기능별로 제공하는 RPC 함수의 종류 및 개수가 다를 수 있지만 공통적으로 *Update(), *Clear(), *Delete(), *Show() 함수를 포함한다.The RPC function provided by the
*Update()는 설정을 신규로 생성하거나 기존 설정을 업데이트하는 함수를 의미한다.*Update() is a function that creates new settings or updates existing settings.
*Clear()는 설정을 초기화하는 함수를 의미한다.*Clear() means a function that initializes settings.
*Delete()는 설정을 삭제하는 함수로 신규로 생성하는 개념이 있을 때만 존재한다.*Delete() is a function that deletes settings and exists only when there is a concept of creating a new one.
*Show()는 설정을 조회하는 함수를 의미한다.*Show() means a function to query settings.
롤(Role) 함수는 역할로서 함수 그룹별 접근권한 셋의 리스트로 정의할 수 있다.A role function can be defined as a list of access rights set for each function group as a role.
사용자(User) 함수는 사용자로서 사용자는 복수 개의 롤을 가질 수 있다.The User function is a user, and a user can have a plurality of roles.
AuthLogin()은 사용자 이름 및 비밀번호로 서비스 접근 토큰을 할당받는 함수를 의미한다.AuthLogin() means a function that receives a service access token with a user name and password.
시스템 내의 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126))는 서비스 접근 토큰을 이용하여 서비스 접근 권한을 확인한다.A plurality of components in the system (
AuthShow()는 서비스 접근 토큰 및 접근할 함수 그룹을 이용하여 해당 토큰을 사용하는 사용자가 접근하는 함수 그룹에 어떠한 접근권한을 갖고 있는지의 여부를 확인하는 함수이다.AuthShow() is a function that uses a service access token and a function group to be accessed to check whether the user using the token has any access rights to the function group to be accessed.
AuthShow()는 서비스 접근 토큰 및 접근할 함수 그룹을 이용하여 해당 토큰을 사용하는 사용자가 어떤 롤 리스트를 갖고 있는지의 여부를 확인하는 함수이다.AuthShow() is a function that uses a service access token and a function group to be accessed to check whether a user using the token has a role list.
*ClearAuthCache() 함수는 컴포넌트가 갖고 있는 인증 캐시를 삭제하는 함수를 의미한다.*ClearAuthCache() function means a function that deletes the authentication cache that a component has.
도 3은 본 실시예에 따른 컴포넌트들에서 제공하는 RPC 함수와 각 함수가 소속된 함수 그룹, 요구 접근권한, 외부 공개여부를 나타낸 도면이다.3 is a diagram showing RPC functions provided by components according to the present embodiment, function groups to which each function belongs, requested access rights, and whether or not they are open to the outside world.
복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126))는 RPC 함수를 제공할 수 있다.A plurality of components (
각 함수는 종류별로 공통된 성격의 한 개의 그룹에 소속되어 있으며, 함수의 동작에 따라 다른 접근 권한을 요구한다.Each function belongs to a group with a common characteristic for each type, and requires different access rights depending on the operation of the function.
예컨대, PortUpdate() 함수는 설정을 변경하는 동작을 수행하기 때문에 읽기, 쓰기, 실행의 모든 권한을 요구한다.For example, the PortUpdate() function requires all read, write, and execute privileges because it performs an operation to change settings.
PortShow() 함수는 설정을 조회하는 동작만 수행하기 때문에 읽기 권한만을 요구한다.The PortShow() function only requires read permission because it only performs operations to inquire settings.
접근 권한의 종류는 다음과 같다.The types of access rights are as follows.
ALL : 전체 접근권한ALL: full access
READ_ONLY : 읽기만 가능READ_ONLY: read only
NONE : 접근권한 없음NONE: No access right
예컨대, PortUpdate() 함수에 접근하기 위해서는 접근하는 사용자가 함수 그룹 Port에 대해서 접근권한 ALL을 갖고 있어야 한다. PortShow() 함수는 함수 그룹 Port에 대해서, READ_ONLY 이상의 접근권한만 갖고 있으면 된다. 각 함수는 외부에 공개되는(Public) 함수와 공개되지 않는 함수로 구분되며, 공개되지 않는 함수는 시스템 내에서만 사용 가능하다.For example, to access the PortUpdate() function, the accessing user must have ALL access rights for the function group Port. The PortShow() function only needs to have READ_ONLY or higher access rights for the function group Port. Each function is divided into a public function and a non-public function, and the non-public function can only be used within the system.
도 4는 본 실시예에 따른 사용자 매니저에서 정의한 롤에 대한 함수 그룹과 접근권한 셋을 나타낸 도면이다.4 is a diagram showing function groups and access right sets for roles defined in the user manager according to the present embodiment.
사용자 매니저(122)는 롤을 정의할 수 있으며, 각 롤은 0개 이상의 함수 그룹과 접근권한의 셋을 포함한다. 예컨대, admin Role은 전체 함수 그룹에 대해 ALL 접근권한을 가진다. The
r1 Role의 함수 그룹 Port는 ALL 접근권한을 가진다. r1 Role의 함수 그룹 VSwitch는 READ_ONLY 접근권한을 가진다. r2 Role은 전체 함수 그룹에 대해 접근할 수 있는 권한이 없다.The function group Port of role r1 has ALL access authority. The function group VSwitch of role r1 has READ_ONLY access. Role r2 does not have access to the entire function group.
도 5는 본 실시예에 따른 사용자 매니저에서 생성한 사용자별 롤 할당을 나타낸 도면이다.5 is a diagram illustrating role assignment for each user created by the user manager according to the present embodiment.
사용자 매니저(122)는 사용자를 생성할 수 있으며, 각 사용자는 0개 이상의 롤을 할당할 수 있다. 예컨대, super 사용자는 admin Role을 가지며, guest 사용자는 monitor Role을 가진다. u1 사용자는 monitor와 r1 Role을 가지며, u2 사용자는 r2 Role을 가진다.The
도 6a,6b,6c,6d는 본 실시예에 따른 서비스 호출시 접근 권한이 없어서 거부되는 경우의 함수 호출 과정을 나타낸 도면이다.6a, 6b, 6c, and 6d are diagrams illustrating a process of calling a function when a service call is denied due to lack of access authority according to the present embodiment.
도 6a,6b,6c,6d에서는 클라이언트(110)가 서비스를 호출 시 접근 권한이 없어서 거부되는 경우에 대해 설명한다.6a, 6b, 6c, and 6d describe a case in which the
도 6a에 도시된 바와 같이, 클라이언트(110)가 사용자 인증을 하기 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 AuthLogin() 함수를 호출한다.As shown in FIG. 6A , the
클라이언트(110)는 사용자 매니저(122)로 Username(u1), password를 전달한 후 사용자 매니저(122)로부터 액세스 토큰(Access token)(t1)을 받는다. 여기서, 액세스 토큰(t1)은 Username, password를 대체하는 사용자 식별 정보로 사용되며, 함수 호출 시 기본적으로 전달되는 토큰을 의미한다.The
사용자 매니저(122)로부터 발행되는 액세스 토큰(t1)의 값은 유일하며 필요 시 만료시간(Expire time)을 설정할 수 있다. 사용자 매니저(122)는 사용자 인증이 완료되면 발급된 액세스 토큰(t1)의 정보와 사용자 정보(u1)를 내부의 캐시에 저장한다.The value of the access token t1 issued from the
도 6b에 도시된 바와 같이, 클라이언트(110)는 VSwitch 설정을 위해 관리 인터페이스를 이용하여 SCS(124)로 VSwitchUpdate() 함수를 호출한다. SCS(124)는 액세스 토큰(t1)과 설정할 VSwitch 이름(VSwitch v1) 등을 클라이언트(110)로부터 수신한다. 클라이언트(110)는 SCS(124)로 액세스 토큰 t1, 설정할 VSwitch v1을 전송한다.As shown in FIG. 6B, the
도 6c에 도시된 바와 같이, SCS(124)는 호출된 메시지에서 전달받은 액세스 토큰(t1)과 호출된 함수명의 소속 함수 그룹(VSwitch)을 추출한다. SCS(124)는 액세스 토큰(t1)에 대응하는 클라이언트가 호출한 함수의 접근권한이 있는지 확인하기 위해 사용자 매니저(122)로 AuthShow() 함수를 호출한다. 사용자 매니저(122)는 SCS(124)로부터 액세스 토큰(t1)과 호출된 함수의 함수 그룹(VSwitch)을 파라미터로 수신한다.As shown in FIG. 6C, the
사용자 매니저(122)는 전달받은 정보(액세스 토큰(t1)과 호출된 함수의 함수 그룹(VSwitch))를 이용하여 해당 클라이언트(110)가 접근하려는 함수에 대한 접근권한(READ_ONLY)과 해당 사용자의 롤 리스트(monitor와 r1 Role)를 응답한다.The
SCS(124)는 수신한 정보(접근하려는 함수에 대한 접근권한(READ_ONLY)과 해당 사용자의 롤 리스트(monitor와 r1 Role))를 캐시에 저장하며, 이후 동일한 요청 발생 시 캐시를 이용하여 빠르게 처리한다.The
도 6d에 도시된 바와 같이, VSwitchUpdate() 서비스 호출 시 함수 그룹 VSwitch의 접근권한이 ALL 이상을 가져야 접근할 수 있는데, SCS(124)는 해당 클라이언트(110)가 조건에 부합(접근권한(READ_ONLY))하지 않는 것으로 확인하고, 해당 클라이언트(110)의 접근을 거부하고 오류를 응답한다.As shown in FIG. 6D, when the VSwitchUpdate() service is called, the access right of the function group VSwitch must be ALL or higher to access. ), deny the access of the
도 7a,7b,7c,7d는 본 실시예에 따른 서비스 호출시 접근 권한이 허용되는 경우의 함수 호출 과정을 나타낸 도면이다.7a, 7b, 7c, and 7d are diagrams illustrating a function call process when access authority is allowed when calling a service according to the present embodiment.
도 7a,7b,7c,7d는 클라이언트(110)가 서비스 호출 시 접근 권한이 허용되는 경우에 대해 설명한다.7a, 7b, 7c, and 7d describe a case in which access authority is allowed when the
도 7a에 도시된 바와 같이, 클라이언트(110)가 사용자 인증을 하기 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 AuthLogin() 함수를 호출한다.As shown in FIG. 7A , the
클라이언트(110)는 사용자 매니저(122)로 Username(u1), password를 전달하고 사용자 매니저(122)로부터 액세스 토큰(t1)을 받는다. 여기서, 액세스 토큰(t1)은 Username, password를 대체하는 사용자 식별 정보로 사용되며, 함수 호출 시 기본적으로 전달되는 토큰을 의미한다. 사용자 매니저(122)는 사용자 인증이 완료되면 사용자 매니저(122)는 발급된 액세스 토큰(t1)의 정보와 사용자 정보(u1)를 내부 캐시에 저장한다.The
도 7b에 도시된 바와 같이, 클라이언트(110)는 Port 설정을 위해 관리 인터페이스를 이용하여 SCS(124)로 PortUpdate() 함수를 호출한다. SCS(124)로 액세스 토큰(t1)과 설정할 Port 이름(Port p1) 등을 클라이언트(110)로부터 수신한다. 클라이언트(110)는 SCS(124)로 액세스 토큰 t1, 설정할 Port p1을 전송한다.As shown in FIG. 7B, the
도 7c에 도시된 바와 같이, SCS(124)는 전달받은 액세스 토큰(t1)과 호출된 함수명이 소속된 함수 그룹을 추출한다. SCS(124)는 액세스 토큰(t1)에 대응하는 사용자가 호출한 함수의 접근권한이 있는지 확인하기 위해 사용자 매니저(122)에 AuthShow() 함수를 호출한다.As shown in FIG. 7C, the
사용자 매니저(122)는 SCS(124)로부터 전달받은 액세스 토큰(t)과 호출된 함수의 함수 그룹(Port)을 파라미터로 수신한다.The
사용자 매니저(122)는 전달받은 정보(액세스 토큰(t)과 호출된 함수의 함수 그룹(Port))를 이용하여 해당 클라이언트(110)가 접근하려는 함수에 대한 접근권한(ALL)과 해당 사용자의 롤 리스트(monitor와 r1 Role)를 응답한다.The
SCS(124)는 수신한 정보(접근하려는 함수에 대한 접근권한(ALL)과 해당 사용자의 롤 리스트(monitor와 r1 Role))를 캐시에 저장하며, 이후 동일한 요청 발생 시 캐시를 이용하여 빠르게 처리한다.The
도 7d에 도시된 바와 같이, PortUpdate() 서비스 호출 시 함수 그룹 Port의 접근권한이 ALL 이상을 가져야 접근할 수 있는데, SCS(124)는 해당 클라이언트(110)가 조건에 부합(접근권한(ALL))하는 것으로 확인하고 해당 클라이언트(110)의 접근을 허용하고 함수를 실행시켜 결과를 응답한다.As shown in FIG. 7D, when the PortUpdate() service is called, access is possible only when the access authority of the function group Port is ALL or higher. ), allows the
도 8은 본 실시예에 따른 SCS(124)의 함수 그룹, 서브 식별자, 접근가능 롤을 나타낸 도면이다.8 is a diagram showing function groups, sub identifiers, and accessible roles of the
SCS(124)는 서브 식별자(Sub-identifier) 기반 접근 권한을 확인하기 위해, 함수 그룹, 서브 식별자, 접근 가능 롤 정보를 저장한다. SCS(124)는 서브 식별자를 기반으로 접근 권한을 추가 확인한다.The
SCS(124)는 전체 함수 그룹에 대한 접근은 불가능하더라도, 해당 함수 그룹 내부에 일부 서브 식별자(예컨대, Port의 경우 Port name, VSwitch의 경우 VSwitch name)에 대해서 접근을 허용한다.Although access to the entire function group is impossible, the
종래에는 특정 네트워크 디바이스에 작업을 수행하여 작업자에게 Port p1에 대해서만 접근권한을 부여해야 할 경우, 접근권한을 부여할 수 있는 방법이 존재하지 않았다.Conventionally, when it is necessary to grant access rights only to Port p1 to a worker by performing a task on a specific network device, there is no method for granting access rights.
본 실시예에 따른 SCS(124)는 서브 식별자 기반으로 접근 권한 확인하여 함수 그룹 Port에 대해서 접근권한을 NONE을 할당하고, Port p1에 대해서만 접근권한을 부여하면, Port p1에 대해서 작업자가 접근하여 작업을 수행할 수 있다.The
SCS(124)는 특정 함수 그룹에 대해 서브 식별자 기반으로 부분적인 접근을 허용하는 방식인 서브 식별자 기반 접근 권한 확인을 수행한다.The
도 8에 도시된 바와 같이, SCS(124)는 함수 그룹 Port에 서브 식별자 Port p2에 대해서 접근 가능 롤 r2 Role만이 접근이 가능하도록 설정할 수 있다.As shown in FIG. 8 , the
도 9a,9b,9c,9d는 본 실시예에 따른 서브 식별자 기반의 접근 권한 확인 후 거부되는 경우의 함수 호출 과정을 나타낸 도면이다.9a, 9b, 9c, and 9d are diagrams illustrating a function call process in the case of rejection after checking access rights based on sub-identifiers according to the present embodiment.
도 9a,9b,9c,9d에서는 클라이언트(110)가 서비스 호출 시 서브 식별자에 따른 접근 권한이 없어서 거부되는 경우에 대해 설명한다.9a, 9b, 9c, and 9d describe a case in which the
도 9a에 도시된 바와 같이, 클라이언트(110)가 사용자 인증을 하기 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 AuthLogin() 함수를 호출한다.As shown in FIG. 9A , the
클라이언트(110)는 사용자 매니저(122)로 Username(u2), password를 전달한 후 사용자 매니저(122)로부터 액세스 토큰(Access token)(t2)을 받는다. 여기서, 액세스 토큰(t2)은 Username, password를 대체하는 사용자 식별 정보로 사용되며, 함수 호출 시 기본적으로 전달되는 토큰을 의미한다.The
사용자 매니저(122)로부터 발행되는 액세스 토큰(t2)의 값은 유일하며 필요 시 만료시간(Expire time)을 설정할 수 있다. 사용자 매니저(122)는 사용자 인증이 완료되면 발급된 액세스 토큰(t2)의 정보와 사용자 정보(u2)를 내부의 캐시에 저장한다.The value of the access token t2 issued from the
도 9b에 도시된 바와 같이, 클라이언트(110)는 Port 설정을 위해 관리 인터페이스를 이용하여 SCS(124)로 PortUpdate() 함수를 호출한다. SCS(124)는 액세스 토큰(t2)과 설정할 Port 이름(Port p1) 등을 클라이언트(110)로부터 수신한다. 클라이언트(110)는 SCS(124)로 액세스 토큰 t2, 설정할 Port p1을 전송한다.As shown in FIG. 9B, the
도 9c에 도시된 바와 같이, SCS(124)는 호출된 메시지에서 전달받은 액세스 토큰(t2)과 호출된 함수명이 소속된 함수 그룹(Port)을 추출한다. SCS(124)는 액세스 토큰(t2)에 대응하는 클라이언트가 호출한 함수의 접근권한이 있는지 확인하기 위해 사용자 매니저(122)로 AuthShow() 함수를 호출한다. 사용자 매니저(122)는 SCS(124)로부터 액세스 토큰(t2)과 호출된 함수의 함수 그룹(Port)을 파라미터로 수신한다.As shown in FIG. 9C, the
사용자 매니저(122)는 전달받은 정보(액세스 토큰(t2)과 호출된 함수의 함수 그룹(Port))를 이용하여 해당 클라이언트(110)가 접근하려는 함수에 대한 접근권한(NONE)과 해당 사용자의 롤 리스트(r2 Role)를 응답한다.The
SCS(124)는 수신한 정보(접근하려는 함수에 대한 접근권한(NONE)과 해당 사용자의 롤 리스트(r2 Role))를 캐시에 저장하며, 이후 동일한 요청 발생 시 캐시를 이용하여 빠르게 처리한다.The
도 9d에 도시된 바와 같이, PortUpdate() 서비스 호출 시 함수 그룹 Port의 접근권한 ALL 이상을 가지거나 서브 식별자가 p2인 경우 해당 클라이언트(110)가 접근할 수 있는데, SCS(124)는 해당 클라이언트(110)의 접근 권한(NONE)과 서브 식별자(p1) 모두가 조건에 만족하지 않으므로, 해당 클라이언트(110)의 접근을 거부하고 오류를 응답한다.As shown in FIG. 9D, when the PortUpdate() service is called, the
도 10은 본 실시예에 따른 SCS(124)의 함수 그룹, 서브 식별자, 접근가능 롤을 나타낸 도면이다.10 is a diagram showing function groups, sub identifiers, and accessible roles of the
SCS(124)는 서브 식별자(Sub-identifier) 기반 접근 권한을 확인하기 위해, 함수 그룹, 서브 식별자, 접근 가능 롤 정보를 저장한다. SCS(124)는 서브 식별자를 기반으로 접근 권한을 추가 확인한다.The
SCS(124)는 전체 함수 그룹에 대한 접근은 불가능하더라도, 해당 함수 그룹 내부에 일부 서브 식별자(예컨대, 함수 그룹(Port), 서브 식별자(p2), 접근 가능 롤(r2))에 대해서 접근을 허용한다.The
종래에는 특정 네트워크 디바이스에 작업을 수행하여 작업자에게 Port p1에 대해서만 접근권한을 부여해야 할 경우, 접근권한을 부여할 수 있는 방법이 존재하지 않았다.Conventionally, when it is necessary to grant access rights only to Port p1 to a worker by performing a task on a specific network device, there is no method for granting access rights.
본 실시예에 따른 SCS(124)는 서브 식별자 기반으로 함수 그룹 Port에 대해서 접근권한을 NONE을 할당하고, Port p1에 대해서만 접근권한을 부여하면, Port p1에 대해서 작업자가 접근하여 작업을 수행할 수 있다. SCS(124)는 특정 함수 그룹에 대해 서브 식별자 기반으로 부분적인 접근을 허용하는 방식인 서브 식별자 기반 접근 권한 확인을 수행한다.The
도 10에 도시된 바와 같이, SCS(124)는 함수 그룹 Port에 Port p2에 대해서 r2 Role은 접근이 가능하도록 설정할 수 있다.As shown in FIG. 10, the
도 11a,11b,11c,11d는 본 실시예에 따른 서브 식별자 기반의 접근 권한 확인 후 허용되는 경우의 함수 호출 과정을 나타낸 도면이다.11a, 11b, 11c, and 11d are diagrams illustrating a function call process when permission is granted after checking access rights based on sub-identifiers according to the present embodiment.
도 11a,11b,11c,11d에서는 클라이언트(110)가 서비스 호출 시 서브 식별자에 따른 접근 권한이 허용되는 경우에 대해 설명한다.In FIGS. 11a, 11b, 11c, and 11d, a case in which access authority according to a sub identifier is allowed when the
도 11a에 도시된 바와 같이, 클라이언트(110)가 사용자 인증을 하기 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 AuthLogin() 함수를 호출한다.As shown in FIG. 11A , the
클라이언트(110)는 사용자 매니저(122)로 Username(u2), password를 전달한 후 사용자 매니저(122)로부터 액세스 토큰(Access token)(t2)을 받는다. 여기서, 액세스 토큰(t2)은 Username, password를 대체하는 사용자 식별 정보로 사용되며, 함수 호출 시 기본적으로 전달되는 토큰을 의미한다.The
사용자 매니저(122)로부터 발행되는 액세스 토큰(t2)의 값은 유일하며 필요 시 만료시간(Expire time)을 설정할 수 있다. 사용자 매니저(122)는 사용자 인증이 완료되면 발급된 액세스 토큰(t2)의 정보와 사용자 정보(u2)를 내부의 캐시에 저장한다.The value of the access token t2 issued from the
도 11b에 도시된 바와 같이, 클라이언트(110)는 Port 설정을 위해 관리 인터페이스를 이용하여 SCS(124)로 PortUpdate() 함수를 호출한다. SCS(124)는 액세스 토큰(t2)과 설정할 Port 이름(Port p2) 등을 클라이언트(110)로부터 수신한다. 클라이언트(110)는 SCS(124)로 액세스 토큰 t2, 설정할 Port p2을 전송한다.As shown in FIG. 11B, the
도 11c에 도시된 바와 같이, SCS(124)는 호출된 메시지에서 전달받은 액세스 토큰(t2)과 호출된 함수명이 소속된 함수 그룹(Port)을 추출한다. SCS(124)는 액세스 토큰(t2)에 대응하는 클라이언트가 호출한 함수의 접근권한이 있는지 확인하기 위해 사용자 매니저(122)로 AuthShow() 함수를 호출한다.As shown in FIG. 11C, the
사용자 매니저(122) SCS(124)로부터 액세스 토큰(t2)과 호출된 함수의 함수 그룹(Port)을 파라미터로 수신한다.The
사용자 매니저(122)는 전달받은 정보(액세스 토큰(t2)과 호출된 함수의 함수 그룹(Port))를 이용하여 해당 클라이언트(110)가 접근하려는 함수에 대한 접근권한(NONE)과 해당 사용자의 롤 리스트(r2 Role)를 응답한다.The
SCS(124)는 수신한 정보(접근하려는 함수에 대한 접근권한(NONE)과 해당 사용자의 롤 리스트(r2 Role))를 캐시에 저장하며, 이후 동일한 요청 발생 시 캐시를 이용하여 빠르게 처리한다.The
도 11d에 도시된 바와 같이, PortUpdate() 서비스 호출 시 함수 그룹 Port의 접근권한 ALL 이상을 가지거나 서브 식별자가 p2인 경우 해당 클라이언트(110)가 접근할 수 있는데, SCS(124)는 해당 클라이언트(110)의 접근 권한(NONE)이 접근 불가이지만, 서브 식별자(p2)가 접근가능 롤(r2)과 액세스 토큰(t2)에 대응하는 클라이언트가 접근가능 롤(r2)을 갖고 있는 것으로 확인하고, 해당 클라이언트(110)의 접근을 허용하고 함수를 실행시켜 결과를 응답한다.As shown in FIG. 11D, when the PortUpdate() service is called, the
도 12는 본 실시예에 따른 접근 권한 부여 방법을 설명하기 위한 순서도이다.12 is a flowchart for explaining a method for granting access authority according to this embodiment.
클라이언트(110)가 사용자 매니저(122)로 사용자 인증 호출(AuthLogin() 함수에 Username, password 전달하여 호출)한다(S1210). 사용자 매니저(122)는 해당 클라이언트(110)의 사용자 인증(Username, password)이 성공했는지의 여부를 확인한다(S1212).The
단계 S1212의 확인 결과, 해당 클라이언트(110)의 사용자 인증(Username, password)이 성공한 경우, 사용자 매니저(122)는 액세스 토큰을 신규로 발행하고 사용자 정보를 매핑한 후 캐시에 저장한다. 사용자 매니저(122)는 클라이언트(110)로 사용자 인증 성공(액세스 토큰)을 응답한다(S1214).As a result of checking in step S1212, if user authentication (username, password) of the
클라이언트(110)는 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트(컨피그 매니저(121), 사용자 매니저(122), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126)) 중 서비스를 담당하는 컴포넌트로 서비스 호출 메시지(액세스 토큰 및 서브 식별자 전달하여 호출)를 전달한다(S1216). 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 서비스 호출 메시지로부터 액세스 토큰, 함수 그룹, 서브 식별자를 추출한다(S1218).The
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 캐시에 액세스 토큰의 함수 그룹에 대한 접근권한이 존재하는지 여부를 확인한다(S1220). 여기서, 액세스 토큰의 함수 그룹에 대한 접근권한이 존재한다면 액세스 토큰의 롤 리스트도 함께 존재한다.Among a plurality of components subdivided according to the internal function of the micro-service architecture, a component in charge of a service checks whether an access right to the function group of the access token exists in the cache (S1220). Here, if the access right for the function group of the access token exists, the role list of the access token also exists.
단계 S1220의 확인 결과, 액세스 토큰의 함수 그룹에 대한 접근권한이 존재하는 경우, 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 클라이언트(110)에 대응하는 함수 그룹 접근권한을 확인한다(S1222).As a result of checking in step S1220, if the access right to the function group of the access token exists, the component in charge of the service among the plurality of components subdivided according to the internal function of the micro-service architecture is the function group corresponding to the
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 클라이언트(110)에 대응하는 함수 그룹 접근권한이 사용자가 호출한 함수가 요구하는 접근권한 이상인지의 여부를 확인한다(S1224).Among a plurality of components subdivided according to the internal functions of the micro-service architecture, a component in charge of a service checks whether the function group access right corresponding to the
단계 S1224의 확인 결과, 클라이언트(110)에 대응하는 함수 그룹 접근권한이 사용자가 호출한 함수가 요구하는 접근권한 이상인 경우, 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 서비스의 접근을 허용하고 함수를 실행하여 결과를 클라이언트(110)로 응답한다(S1226).As a result of checking in step S1224, if the function group access right corresponding to the
단계 S1220의 확인 결과, 액세스 토큰의 함수 그룹에 대한 접근권한이 미존재하는 경우, 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 사용자 매니저(122)로 호출된 함수 그룹에 대한 사용자 접근권한을 요청(AuthShow() 함수에 액세스 토큰과 함수 그룹을 전달하여 호출)한다(S1232).As a result of checking in step S1220, if there is no access right to the function group of the access token, the component in charge of the service among a plurality of components subdivided according to the internal function of the micro-service architecture is called by the
사용자 매니저(122)는 액세스 토큰을 이용하여 사용자를 추출하고, 사용자를 이용하여 롤을 추출하고 롤을 이용하여 호출한 함수 그룹에 대한 접근권한을 추출한다(S1234).The
사용자 매니저(122)는 추출된 사용자 접근권한 및 사용자의 전체 롤 리스트를 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트로 응답한다(S1236). 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 수신한 정보로 액세스 토큰의 호출한 함수 그룹에 대한 접근권한 및 롤 리스트를 캐시에 저장한다(S1238).The
단계 S1224의 확인 결과, 클라이언트(110)에 대응하는 함수 그룹 접근권한이 사용자가 호출한 함수가 요구하는 접근권한 미만인 경우, 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 사용자가 호출한 함수 그룹 및 전달받은 서브 식별자가 접근을 허용하는 롤 리스트를 추출한다(S1242).As a result of checking in step S1224, if the function group access right corresponding to the
마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 사용자가 소유하고 있는 롤 리스트를 확인한다(S1244). 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 추출된 롤 리스트 상에 사용자가 소유하고 있는 롤 리스트가 하나라도 포함되어 있는지 확인한다(S1246).Among a plurality of components subdivided according to internal functions of the micro-service architecture, a component in charge of a service checks a role list owned by the user (S1244). Among the plurality of components subdivided according to the internal function of the micro-service architecture, the component in charge of the service checks whether at least one role list owned by the user is included in the extracted role list (S1246).
단계 S1246의 확인 결과, 추출된 롤 리스트 상에 사용자가 소유하고 있는 롤 리스트가 하나도 포함되지 않은 경우, 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 서비스의 접근을 거부하고 서비스 접근권한 없음을 클라이언트(110)로 응답한다(S1248).As a result of checking in step S1246, if no role list owned by the user is included in the extracted role list, the component in charge of the service among a plurality of components subdivided according to the internal function of the micro-service architecture has access to the service. It rejects and responds that there is no service access right to the client 110 (S1248).
단계 S1246의 확인 결과, 추출된 롤 리스트 상에 사용자가 소유하고 있는 롤 리스트가 하나라도 포함된 경우, 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트는 서비스의 접근을 허용하고 함수를 실행하여 결과를 클라이언트(110)로 응답한다(S1226).As a result of checking in step S1246, if at least one role list owned by the user is included in the extracted role list, the component in charge of the service among a plurality of components subdivided according to the internal function of the micro-service architecture has access to the service. is allowed, the function is executed, and the result is returned to the client 110 (S1226).
단계 S1212의 확인 결과, 해당 클라이언트(110)의 사용자 인증(Username, password)에 실패한 경우, 사용자 매니저(124)는 클라이언트(110)로 사용자 인증 오류를 응답한다(S1250).As a result of checking in step S1212, if user authentication (username, password) of the
도 12에서는 단계 S1210 내지 단계 S1250을 순차적으로 실행하는 것으로 기재하고 있으나, 반드시 이에 한정되는 것은 아니다. 다시 말해, 도 12에 기재된 단계를 변경하여 실행하거나 하나 이상의 단계를 병렬적으로 실행하는 것으로 적용 가능할 것이므로, 도 12는 시계열적인 순서로 한정되는 것은 아니다.Although it is described in FIG. 12 that steps S1210 to S1250 are sequentially executed, it is not necessarily limited thereto. In other words, since the steps described in FIG. 12 may be changed and executed or one or more steps may be executed in parallel, FIG. 12 is not limited to a time-series sequence.
전술한 바와 같이 도 12에 기재된 본 실시예에 따른 접근 권한 부여 방법은 프로그램으로 구현되고 컴퓨터로 읽을 수 있는 기록매체에 기록될 수 있다. 본 실시예에 따른 접근 권한 부여 방법을 구현하기 위한 프로그램이 기록되고 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다.As described above, the access authorization method according to the present embodiment described in FIG. 12 may be implemented as a program and recorded on a computer-readable recording medium. The computer-readable recording medium on which the program for implementing the access authorization method according to the present embodiment is recorded includes all kinds of recording devices in which data readable by a computer system is stored.
도 13a,13b,13c,13d,13e는 본 실시예에 따른 사용자 정보의 업데이트, 삭제 또는 롤 정보를 업데이트시 함수 호출 과정을 나타낸 도면이다.13a, 13b, 13c, 13d, and 13e are diagrams illustrating a process of calling a function when updating or deleting user information or updating role information according to the present embodiment.
도 13a에 도시된 바와 같이, 클라이언트(110)가 사용자 인증을 하기 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 AuthLogin() 함수를 호출한다.As shown in FIG. 13A , the
도 13b에 도시된 바와 같이, 클라이언트(110)가 사용자 업데이트/삭제 또는 롤 업데이트를 위하여 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 UserUpdate()/UserDelete() 또는 RoleUpdate() 함수를 호출한다.As shown in FIG. 13B, the
도 13c에 도시된 바와 같이, 사용자 매니저(122)는 사용자 정보의 업데이트/삭제 또는 롤 정보의 업데이트가 발생한 경우, 변경이 일어난 사용자의 인증 캐시를 삭제한다.As shown in FIG. 13C , the
도 13d에 도시된 바와 같이, 사용자 매니저(122)는 복수의 컴포넌트(컨피그 매니저(121), 로그 매니저(123), SCS(124), 시스템 매니저(125), 커멘드 해석 쉘(126))에 사용자 정보의 업데이트/삭제 또는 롤 정보의 업데이트가 발생한 경우, 인증 캐시 정보를 삭제하라고 지시한다. 예컨대, 사용자 매니저(122)는 SCS(124)로 SCSClearAuthCache() 함수를 호출하여 인증 캐시 정보 삭제를 요청할 수 있다.As shown in FIG. 13D, the
도 13e에 도시된 바와 같이, 사용자 매니저(122)는 시스템 매니저(125)로 SysMgrClearAuthCache() 함수를 호출하여 인증 캐시 정보 삭제를 요청할 수 있다. 사용자 매니저(122)는 모든 서비스에 대해 해당 컴포넌트로 인증 캐시 정보 삭제를 요청할 수 있다.As shown in FIG. 13E , the
도 14a,14b,14c,14d는 본 실시예에 따른 롤 정보 삭제 거부 시나리오 1에 대한 함수 호출 과정을 나타낸 도면이다.14a, 14b, 14c, and 14d are diagrams illustrating a process of calling a function for role information
도 14a,14b,14c,14d에서는 롤을 사용자 매니저(122)가 사용 중일 경우 롤 정보 삭제 거부 시나리오 1에 대해 설명한다. 도 14a에 도시된 바와 같이, 클라이언트(110)가 사용자 인증을 하기 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 AuthLogin() 함수를 호출한다.14a, 14b, 14c, and 14d describe
도 14b에 도시된 바와 같이, 클라이언트(110)가 롤 삭제를 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 RoleDelete() 함수를 호출한다. 예컨대, 클라이언트(110)는 사용자 매니저(122)로 Role r2를 삭제할 것을 요청한다.As shown in FIG. 14B, the
도 14c에 도시된 바와 같이, 사용자 매니저(122)는 삭제대상 Role r2를 매핑하고 있는 사용자가 있는지의 여부를 조회한다. 예컨대, 사용자 매니저(122)는 Role r2를 매핑하고 있는 사용자가 존재한다고 가정한다.As shown in FIG. 14C, the
도 14d에 도시된 바와 같이, 사용자 매니저(122)는 Role r2를 매핑하고 있는 사용자가 존재하므로 삭제를 거부하고 클라이언트(110)로 오류를 응답한다.As shown in FIG. 14D , the
도 15a,15b,15c,15d,15e는 본 실시예에 따른 롤 정보 삭제 거부 시나리오 2에 대한 함수 호출 과정을 나타낸 도면이다.15a, 15b, 15c, 15d, and 15e are diagrams illustrating a process of calling a function for role information
도 15a,15b,15c,15d,15e에서는 다른 컴포넌트에서 롤을 사용 중일 경우 롤 정보 삭제 거부 시나리오 1에 대해 설명한다. 도 15a에 도시된 바와 같이, 클라이언트(110)가 사용자 인증을 하기 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 AuthLogin() 함수를 호출한다.15a, 15b, 15c, 15d, and 15e describe role information
도 15b에 도시된 바와 같이, 클라이언트(110)가 롤 삭제를 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 RoleDelete() 함수를 호출한다. 예컨대, 클라이언트(110)는 사용자 매니저(122)로 Role r2를 삭제할 것을 요청한다.As shown in FIG. 15B, the
도 15c에 도시된 바와 같이, 사용자 매니저(122)는 삭제대상 Role r2를 매핑하고 있는 사용자가 있는지의 여부를 조회한다. 예컨대, 사용자 매니저(122)는 Role r2를 매핑하고 있는 사용자가 미존재한다고 가정한다.As shown in FIG. 15C, the
도 15d에 도시된 바와 같이, 사용자 매니저(122)는 Role r2를 매핑하고 있는 다른 컴포넌트가 없는지 모든 컴포넌트에 *ShowRole() 함수를 호출하여 확인한다.As shown in FIG. 15D , the
예컨대, 사용자 매니저(122)는 SCS(124)로 PortShowRole(), VSwitchShowRole(), FlowRuleShowRole()을 호출하여 Role r2가 매핑 중인지의 여부를 확인한다. SCS(124)는 Role r2가 Port p2에서 접근 가능한 Role로 등록되어 있는 경우, 클라이언트(110)로 롤을 매핑 중 이라고 응답한다.For example, the
도 15e에 도시된 바와 같이, 사용자 매니저(122)는 Role r2를 매핑하고 있는 다른 컴포넌트가 존재하므로 삭제를 거부하고 클라이언트(110)로 오류를 응답한다.As shown in FIG. 15E , the
도 16a,16b,16c,16d,16e,16f는 본 실시예에 따른 롤 정보 삭제 허용 시나리오 3에 대한 함수 호출 과정을 나타낸 도면이다.16a, 16b, 16c, 16d, 16e, and 16f are diagrams illustrating a process of calling a function for role information
도 16a,16b,16c,16d,16e,16f에서는 롤 삭제 허용 시 발생하는 시나리오 3에 대해 설명한다. 도 16a에 도시된 바와 같이, 클라이언트(110)가 사용자 인증을 하기 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 AuthLogin() 함수를 호출한다.16a, 16b, 16c, 16d, 16e, and 16f describe
도 16b에 도시된 바와 같이, 클라이언트(110)가 롤 삭제를 위해 관리 인터페이스를 이용하여 사용자 매니저(122)로부터 RoleDelete() 함수를 호출한다. 예컨대, 클라이언트(110)는 사용자 매니저(122)로 Role r1을 삭제할 것을 요청한다.As shown in FIG. 16B, the
도 16c에 도시된 바와 같이, 사용자 매니저(122)는 삭제대상 Role r1를 매핑하고 있는 사용자가 있는지의 여부를 조회한다. 예컨대, 사용자 매니저(122)는 Role r1를 매핑하고 있는 사용자가 미존재한다고 가정한다.As shown in FIG. 16C, the
도 16d에 도시된 바와 같이, 사용자 매니저(122)는 Role r1를 매핑하고 있는 다른 컴포넌트가 없는지 모든 컴포넌트에 *ShowRole() 함수를 호출하여 확인한다. 예컨대, 사용자 매니저(122)는 SCS(124)로 PortShowRole(), VSwitchShowRole(), FlowRuleShowRole()을 호출하여 Role r1를 매핑 중인지의 여부를 확인한다. SCS(124)는 사용자 매니저(122)로 Role r1을 매핑하지 않고 있다고 응답한다.As shown in FIG. 16D , the
도 16e에 도시된 바와 같이, 사용자 매니저(122)는 Role r1를 매핑하고 있는 다른 컴포넌트가 없는지 모든 컴포넌트에 *ShowRole() 함수를 호출하여 확인한다. 예컨대, 사용자 매니저(122)는 *ShowRole()을 호출하여 시스템 매니저(125)로 Role r1를 매핑 중인지의 여부를 확인한다. 시스템 매니저(125)는 Role r1을 매핑하지 않고 있다고 사용자 매니저(122)로 응답한다. 사용자 매니저(122)는 계속해서 *ShowRole()을 호출하여 나머지 모든 컴포넌트에 Role r1을 매핑 중인지 확인한다.As shown in FIG. 16E, the
도 16f에 도시된 바와 같이, 사용자 매니저(122)는 Role r1를 매핑하고 있는 다른 컴포넌트가 없으므로 정상적으로 Role r1을 삭제하고 결과를 클라이언트(110)로 응답한다.As shown in FIG. 16F , the
이상의 설명은 본 실시예의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 실시예가 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 실시예의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 실시예들은 본 실시예의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예에 의하여 본 실시예의 기술 사상의 범위가 한정되는 것은 아니다. 본 실시예의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 실시예의 권리범위에 포함되는 것으로 해석되어야 할 것이다.The above description is merely an example of the technical idea of the present embodiment, and various modifications and variations can be made to those skilled in the art without departing from the essential characteristics of the present embodiment. Therefore, the present embodiments are not intended to limit the technical idea of the present embodiment, but to explain, and the scope of the technical idea of the present embodiment is not limited by these embodiments. The scope of protection of this embodiment should be construed according to the claims below, and all technical ideas within the scope equivalent thereto should be construed as being included in the scope of rights of this embodiment.
110: 클라이언트
120: 시스템
121: 컨피그 매니저
122: 사용자 매니저
123: 로그 매니저
124: SCS
125: 시스템 매니저
126: 커멘드 해석 쉘110: client
120: system
121: Config Manager
122: user manager
123: log manager
124: SCS
125: system manager
126: command interpreting shell
Claims (13)
상기 클라이언트에서 상기 액세스 토큰을 첨부하여 마이크로-서비스 아키텍처의 내부 기능에 따라 세분화된 복수의 컴포넌트 중 서비스를 담당하는 컴포넌트로 서비스 호출 메시지를 전송하는 과정;
상기 서비스를 담당하는 컴포넌트에서 상기 사용자 매니저로부터 상기 액세스 토큰에 매칭된 롤(role)을 확인하는 과정;
상기 서비스를 담당하는 컴포넌트에서 상기 롤에 매칭된 접근권한(Access Right)을 확인하는 과정;
상기 서비스를 담당하는 컴포넌트에서 상기 롤에 매칭된 접근권한이 기 설정된 요구 접근권한(Required Access Right) 이상인 지의 여부를 확인하여 확인 결과를 생성하는 과정;
상기 확인 결과에 따라 상기 서비스를 담당하는 컴포넌트에서 상기 클라이언트가 접근하도록 접근 권한을 부여하는 과정;을 포함하되,
상기 서비스를 담당하는 컴포넌트에서 상기 서비스 호출 메시지로부터 상기 액세스 토큰, 함수 그룹, 서브 식별자를 추출하고 상기 사용자 매니저로 상기 액세스 토큰, 상기 함수 그룹을 전송하며,
상기 사용자 매니저에서 상기 서비스를 담당하는 컴포넌트로부터 상기 액세스 토큰, 상기 함수 그룹을 수신하고, 자신의 캐시에 기 저장된 정보를 기반으로 상기 액세스 토큰, 상기 함수 그룹에 대응하는 접근권한과 롤 리스트가 존재하는 지의 여부를 확인한 확인 결과를 생성하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.A process of issuing an access token from the user manager to a client that has performed user authentication;
attaching the access token to the client and transmitting a service call message to a component in charge of a service among a plurality of components subdivided according to an internal function of a micro-service architecture;
checking a role matched to the access token from the user manager in a component in charge of the service;
checking an access right matched to the role in a component in charge of the service;
generating a confirmation result by checking whether or not the access right matched to the role in the component in charge of the service is greater than or equal to a preset required access right;
Including; granting access authority for the client to access in a component in charge of the service according to the confirmation result;
A component in charge of the service extracts the access token, function group, and sub-identifier from the service call message and transmits the access token and the function group to the user manager;
The user manager receives the access token and the function group from the component in charge of the service, and based on information previously stored in its own cache, the access right and role list corresponding to the access token and the function group exist. Microservice-based service access authorization method, characterized in that for generating a confirmation result confirming whether or not.
상기 사용자 매니저에서 상기 클라이언트로부터 수신된 사용자 이름(Username), 패스워드(password)가 인증되는 경우, 상기 클라이언트에 대한 상기 액세스 토큰을 발행하고, 상기 액세스 토큰에 상기 사용자 이름에 대응하는 사용자 정보를 매핑하여 자신의 캐시에 저장하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.According to claim 1,
When the user name and password received from the client are authenticated by the user manager, the access token for the client is issued, and user information corresponding to the user name is mapped to the access token. A microservice-based service access authorization method characterized by storing in its own cache.
상기 사용자 매니저에서 확인 결과, 자신의 캐시에 기 저장된 정보를 기반으로 상기 액세스 토큰, 상기 함수 그룹에 대응하는 접근권한과 롤 리스트가 존재하는 경우, 상기 함수 그룹에 대응하는 접근권한과 롤 리스트를 상기 서비스를 담당하는 컴포넌트로 전송하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.According to claim 1,
As a result of checking in the user manager, if the access token and the access rights and role list corresponding to the function group exist based on the information pre-stored in the cache, the access rights and role list corresponding to the function group are displayed. A microservice-based service access authorization method characterized by transmitting to a component in charge of the service.
상기 서비스를 담당하는 컴포넌트에서 상기 함수 그룹에 대응하는 접근권한이 해당 컴포넌트에 기 설정된 상기 요구 접근권한 이상인지를 확인한 상기 확인 결과를 생성하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.According to claim 5,
Microservice-based service access authorization method, characterized in that in the component in charge of the service, the confirmation result is generated by confirming whether the access authority corresponding to the function group is greater than or equal to the required access authority preset in the corresponding component.
상기 서비스를 담당하는 컴포넌트에서 상기 확인 결과에 따라 상기 함수 그룹에 대응하는 접근권한이 해당 컴포넌트에 기 설정된 상기 요구 접근권한 이상인 경우 상기 클라이언트를 상기 함수 그룹으로 접근하도록 접근 권한을 부여하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.According to claim 6,
In the component in charge of the service, if the access right corresponding to the function group according to the check result is greater than or equal to the required access right set in advance for the corresponding component, the client is given access right to access the function group. Characterized in that A microservice-based service access authorization method.
상기 서비스를 담당하는 컴포넌트에서 상기 확인 결과에 따라 상기 함수 그룹에 대응하는 접근권한이 해당 컴포넌트에 기 설정된 상기 요구 접근권한 미만인 경우, 상기 서비스 호출 메시지로부터 추출한 상기 서브 식별자가 상기 롤 리스트에 포함된 복수의 접근가능 롤 중 어느 하나에 대응하는 것으로 확인되면, 상기 클라이언트가 상기 함수 그룹에 대응하는 컴포넌트로 접근하는 것을 허용하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.According to claim 6,
In the component in charge of the service, if the access authority corresponding to the function group according to the check result is less than the requested access authority preset in the corresponding component, the sub-identifier extracted from the service call message is included in the role list. If it is confirmed that it corresponds to any one of the accessible roles of the microservice-based service access authorization method, characterized in that to allow the client to access the component corresponding to the function group.
상기 서비스를 담당하는 컴포넌트에서 상기 확인 결과에 따라 상기 함수 그룹에 대응하는 접근권한이 해당 컴포넌트에 기 설정된 상기 요구 접근권한 미만인 경우, 상기 서비스 호출 메시지로부터 추출한 상기 서브 식별자가 상기 롤 리스트에 포함된 복수의 접근가능 롤 중 대응되는 롤이 없는 것으로 확인되면, 상기 클라이언트가 상기 함수 그룹에 대응하는 컴포넌트로 접근하는 것을 거부하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.According to claim 6,
In the component in charge of the service, if the access authority corresponding to the function group according to the check result is less than the requested access authority preset in the corresponding component, the sub-identifier extracted from the service call message is included in the role list. If it is confirmed that there is no corresponding role among the accessible roles of the microservice-based service access authorization method, characterized in that to deny the client access to the component corresponding to the function group.
상기 사용자 매니저에서 상기 클라이언트로부터 사용자 업데이트 함수, 사용자 삭제 함수, 롤 업데이트 함수 중 어느 하나의 함수가 호출되면, 자신의 캐시에서 사용자 업데이트, 사용자 삭제, 롤 업데이트 중 어느 하나가 발생한 정보를 삭제하고, 복수의 컴포넌트로 상기 사용자 업데이트, 상기 사용자 삭제, 상기 롤 업데이트 중 어느 하나가 발생한 정보를 삭제하라고 지시하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.According to claim 1,
When any one of a user update function, a user delete function, and a role update function is called from the client in the user manager, it deletes information in which any one of user update, user deletion, and role update has occurred from its own cache, and A microservice-based service access authorization method characterized in that instructing to delete information generated by any one of the user update, the user deletion, and the role update as a component of.
상기 사용자 매니저에서 상기 클라이언트로부터 롤 삭제 함수가 호출되면, 자신의 캐시에서 상기 롤 삭제 함수에 대응하는 삭제 대상 롤을 매핑하고 있는 사용자가 있는지의 여부를 조회하고, 조회 결과, 상기 삭제 대상 롤을 매핑하고 있는 사용자가 존재하는 경우, 상기 삭제 대상 롤에 대한 삭제를 거부하고 상기 클라이언트로 오류를 응답하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.According to claim 1,
When a role deletion function is called from the client in the user manager, it inquires whether there is a user mapping a role to be deleted corresponding to the role deletion function in its own cache, and maps the role to be deleted as a result of the inquiry. and rejecting the deletion of the role to be deleted and responding with an error to the client if there is a user who is doing so.
상기 사용자 매니저에서 상기 클라이언트로부터 롤 삭제 함수가 호출되면, 자신의 캐시에서 상기 롤 삭제 함수에 대응하는 삭제 대상 롤을 매핑하고 있는 사용자가 있는지의 여부를 조회하고, 조회 결과, 상기 삭제 대상 롤을 매핑하고 있는 사용자가 미존재하는 경우, 상기 삭제 대상 롤을 매핑하고 있는 복수의 다른 컴포넌트가 존재하는 지의 여부를 확인하고, 확인 결과, 상기 삭제 대상 롤을 매핑하고 있는 다른 컴포넌트가 존재하는 경우, 상기 삭제 대상 롤에 대한 삭제를 거부하고 상기 클라이언트로 오류를 응답하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.According to claim 1,
When a role deletion function is called from the client in the user manager, it inquires whether there is a user mapping a role to be deleted corresponding to the role deletion function in its own cache, and maps the role to be deleted as a result of the inquiry. If the user who is playing the role does not exist, it is checked whether a plurality of other components mapping the role to be deleted exist, and as a result of the check, if there is another component mapping the role to be deleted, the deletion is performed. A microservice-based service access authorization method characterized by rejecting deletion of a target role and responding with an error to the client.
상기 사용자 매니저에서 상기 클라이언트로부터 롤 삭제 함수가 호출되면, 자신의 캐시에서 상기 롤 삭제 함수에 대응하는 삭제 대상 롤을 매핑하고 있는 사용자가 있는지의 여부를 조회하고, 조회 결과, 상기 삭제 대상 롤을 매핑하고 있는 사용자가 미존재하는 경우, 상기 삭제 대상 롤을 매핑하고 있는 복수의 다른 컴포넌트가 존재하는 지의 여부를 확인하고, 확인 결과, 상기 삭제 대상 롤을 매핑하고 있는 다른 컴포넌트가 미존재하는 경우, 상기 삭제 대상 롤을 삭제하는 것을 특징으로 하는 마이크로서비스 기반의 서비스 접근 권한 부여 방법.
According to claim 1,
When a role deletion function is called from the client in the user manager, it inquires whether there is a user mapping a role to be deleted corresponding to the role deletion function in its own cache, and maps the role to be deleted as a result of the inquiry. If the user who is playing the role does not exist, it is checked whether a plurality of other components mapping the role to be deleted exist, and as a result of the check, if there is no other component mapping the role to be deleted, the A microservice-based service access authorization method characterized by deleting a role to be deleted.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020220132107A KR102535012B1 (en) | 2022-10-14 | 2022-10-14 | Method Authorizing Access to Service Based on Microservice |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020220132107A KR102535012B1 (en) | 2022-10-14 | 2022-10-14 | Method Authorizing Access to Service Based on Microservice |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR102535012B1 true KR102535012B1 (en) | 2023-05-26 |
Family
ID=86536353
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020220132107A KR102535012B1 (en) | 2022-10-14 | 2022-10-14 | Method Authorizing Access to Service Based on Microservice |
Country Status (1)
| Country | Link |
|---|---|
| KR (1) | KR102535012B1 (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102262093B1 (en) * | 2020-07-22 | 2021-06-08 | 한국과학기술정보연구원 | Gateway apparatus, and control method thereof |
| KR102430882B1 (en) * | 2021-12-13 | 2022-08-09 | 에스지에이솔루션즈 주식회사 | Method, apparatus and computer-readable medium for container work load executive control of event stream in cloud |
-
2022
- 2022-10-14 KR KR1020220132107A patent/KR102535012B1/en active IP Right Grant
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102262093B1 (en) * | 2020-07-22 | 2021-06-08 | 한국과학기술정보연구원 | Gateway apparatus, and control method thereof |
| KR102430882B1 (en) * | 2021-12-13 | 2022-08-09 | 에스지에이솔루션즈 주식회사 | Method, apparatus and computer-readable medium for container work load executive control of event stream in cloud |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11930015B2 (en) | Systems and method for authenticating users of a data processing platform from multiple identity providers | |
| JP3415456B2 (en) | Network system, command use authority control method, and storage medium storing control program | |
| US10135827B2 (en) | Secure access to remote resources over a network | |
| US7752661B2 (en) | Method and system for server support of pluggable authorization systems | |
| CN106411857B (en) | A kind of private clound GIS service access control method based on virtual isolation mech isolation test | |
| US7367046B1 (en) | Method and apparatus for assigning network addresses to network devices | |
| US20030226036A1 (en) | Method and apparatus for single sign-on authentication | |
| EP2212821A1 (en) | Methods and systems for user authorization | |
| CN112541190B (en) | Map authority control method and control system based on unified user information | |
| US6732172B1 (en) | Method and system for providing cross-platform access to an internet user in a heterogeneous network environment | |
| CN101166173A (en) | A single-node login system, device and method | |
| CN107257337A (en) | A kind of shared authority control method of multiterminal and its system | |
| US9077708B2 (en) | Information processing system, control method for controlling the information processing system, and storage medium | |
| JP4558402B2 (en) | Principal moves across security boundaries without service interruption | |
| KR102535012B1 (en) | Method Authorizing Access to Service Based on Microservice | |
| KR102206847B1 (en) | System and method for hybrid security | |
| JPH0779243A (en) | Network connection device and network connection method | |
| US20220166763A1 (en) | System and method for managing integrated account based on token | |
| US6826695B1 (en) | Method and system for grouping of systems in heterogeneous computer network | |
| KR20090128203A (en) | Apparatus and method for controlling access in hosting service environment | |
| JPH1131132A (en) | Authentication/authority control system | |
| KR102214162B1 (en) | A user-based object access control system using server's hooking | |
| JPH04336345A (en) | Decentralized file system | |
| US20230244401A1 (en) | Data management system, volume access control method and non-transitory computer readable medium | |
| CN118018248A (en) | Access control method, system, electronic device and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant |