KR20200083498A - 애플리케이션 프로그램 인터페이스(api) 호출자를 인증하는 방법 및 시스템 - Google Patents

애플리케이션 프로그램 인터페이스(api) 호출자를 인증하는 방법 및 시스템 Download PDF

Info

Publication number
KR20200083498A
KR20200083498A KR1020207014132A KR20207014132A KR20200083498A KR 20200083498 A KR20200083498 A KR 20200083498A KR 1020207014132 A KR1020207014132 A KR 1020207014132A KR 20207014132 A KR20207014132 A KR 20207014132A KR 20200083498 A KR20200083498 A KR 20200083498A
Authority
KR
South Korea
Prior art keywords
api
caller
capif
ccf
interface
Prior art date
Application number
KR1020207014132A
Other languages
English (en)
Other versions
KR102591619B1 (ko
Inventor
라자벨사미 라자듀라이
나렌드라나트 두르가 타구두
니산트 굽타
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR1020237035362A priority Critical patent/KR20230152766A/ko
Publication of KR20200083498A publication Critical patent/KR20200083498A/ko
Application granted granted Critical
Publication of KR102591619B1 publication Critical patent/KR102591619B1/ko

Links

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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0485—Networking architectures for enhanced packet encryption processing, e.g. offloading of IPsec packet processing or efficient security association look-up
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Communication Control (AREA)

Abstract

LTE와 같은 4G 통신 시스템 이후의 시스템보다 더 높은 데이터 송신 속도를 지원하기 위한 5G 또는 pre-5G 통신 시스템이 개시된다. 본 명세서의 실시예는 공통 애플리케이션 프로그램 인터페이스 프레임워크(CAPIF)를 사용하여 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법 및 시스템을 개시한다. 이러한 방법은 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자로부터의 연결 요청을 수신할 때 CAPIF 코어 기능부(CCF)가 적어도 하나의 API 호출자와의 보안 TLS(Transport Layers Security) 연결을 설립하는 단계를 포함한다. 또한, 방법은 CCF가 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자의 CAPIF-2e 인터페이스 보안(C2eIS)을 위해 적어도 하나의 API 호출자에 의해 사용되는 적어도 하나의 보안 방법을 결정하는 단계를 포함한다. 방법은 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대해 API 노출 기능부(AEF)가 C2eIS를 인에이블하는 단계를 더 포함한다.

Description

애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법 및 시스템
본 개시는 셀룰러 통신 분야에 관한 것으로서, 특히 공통 애플리케이션 프로그램 인터페이스 프레임워크(common application program interface framework, CAPIF)를 사용하여 애플리케이션 프로그램 인터페이스(application program interface, API) 호출자를 인증하는 것에 관한 것이다.
4세대(4G) 통신 시스템 상용화 이후 증가한 무선 데이터 트래픽 요구를 충족시키기 위해, 개선된 5세대(5G) 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 행해졌다. 이러한 이유로, 5G 통신 시스템 또는 프리-5G 통신 시스템은 beyond 4G 네트워크 통신 시스템 또는 post-LTE 시스템이라고 한다.
높은 데이터 송신 속도를 달성하기 위해, mmWave 대역(예를 들어, 60GHz 대역)에서의 5G 통신 시스템의 구현이 고려되고 있다. 5G 통신 시스템에서, 빔포밍(beamforming), 대규모 MIMO, FD-MIMO(Full Dimensional MIMO), 어레이 안테나, 아날로그 빔포밍 및 대규모 안테나와 같은 기술은 mmWave 대역에서의 전파 경로 손실을 완화하고, 전파 송신 거리를 증가시키기 위해 논의된다.
또한, 진화된 소형 셀, 진보된 소형 셀, 클라우드 RAN(Radio Access Network), 초 고밀도 네트워크(ultra-dense network), D2D(Device to Device) 통신, 무선 백홀, 이동 네트워크, 협력 통신, CoMP(Coordinated Multi-Point), 간섭 제거는 5G 통신 시스템에서 시스템 네트워크를 개선하기 위해 개발되었다.
또한, 5G 시스템은 FQAM(Hybrid FSK and QAM Modulation) 및 SWSC(Sliding Window Superposition Coding)와 같은 ACM(Advanced Coding Modulation) 방식, 및 FBMC(Filter Bank Multi Carrier), NOMA(Non-Orthogonal Multiple Access) 및 SCMA(Sparse Code Multiple Access)와 같은 진보된 액세스 기술을 개발하였다.
현재, 공통 애플리케이션 프로그램 인터페이스(API) 프레임워크(CAPIF) 인터페이스(CAPIF-1, CAPIF-1e, CAPIF-2 및 CAPIF-2e)의 보안 양태(security aspects) 및 각각의 보안 정보 흐름은 개방되어 있다. 따라서, CAPIF가 상이한 아키텍처 및 성능 요구 사항을 가진 방대한 서비스를 지원하므로 하나 이상의 인증 방법과 보안 인터페이스 설정 방법/절차를 지원하기 위해 다양한 보안 방법이 필요하다. 상술한 문제점을 고려하여, API 호출자의 인증 시스템 및 방법이 필요하다.
다양한 실시예가 공통 애플리케이션 프로그램 인터페이스 프레임워크(CAPIF)를 사용하여 API 호출자를 인증하는 시스템 및 방법을 제공한다.
또한, 다양한 실시예는 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자로부터의 연결 요청을 수신할 때 CAPIF 코어 기능부(CAPIF core function, CCF)가 CAPIF-1e 인터페이스를 통해 적어도 하나의 API 호출자와의 보안 연결을 설립하는 시스템 및 방법을 제공한다.
또한, 다양한 실시예는 CCF가 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자의 CAPIF-2e 인터페이스 보안(CAPIF-2e interface security, C2eIS)을 위해 적어도 하나의 API 호출자에 의해 사용되는 적어도 하나의 보안 방법을 결정하는 시스템 및 방법을 제공한다.
또한, 다양한 실시예는 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대한 C2eIS를 인에이블(enable)하는 시스템 및 방법을 제공한다.
따라서, 본 명세서의 실시예는 공통 애플리케이션 프로그램 인터페이스 프레임워크(CAPIF)를 사용하여 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법 및 시스템을 제공한다. 이러한 방법은 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자로부터의 연결 요청을 수신할 때 CAPIF 코어 기능부(CCF)가 적어도 하나의 API 호출자와의 보안 연결을 설립하는 단계를 포함하며, CCF와 적어도 하나의 API 호출자 사이에 보안 연결을 설립하는 것은 CAPIF-1e 인터페이스를 통한 CCF와 적어도 하나의 API 호출자 사이의 상호 인증에 기초한다. 또한, 방법은 CCF가 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자로부터의 연결 요청을 수신할 때 CAPIF 코어 기능부(CCF)가 적어도 하나의 API 호출자의 CAPIF-2e 인터페이스 보안(C2eIS)을 위해 적어도 하나의 API 호출자에 의해 사용되는 적어도 하나의 보안 방법을 결정하는 단계를 포함하며, 적어도 하나의 보안 방법은 TLS-PSK(Transport Layers Security-Pre-Shared Key), TLS-PKI(TLS-Public Key Infrastructure), IKEv2(Internet Key Exchange version 2), IPsec(Internet Protocol Security) 및 OAuth 2.0 중 적어도 하나를 포함한다. 방법은 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대해 API 노출 기능부(API exposing function, AEF)가 C2eIS를 인에이블하는 단계를 더 포함한다. C2eIS는 인증, 인터페이스 보호 및 인가(authorization) 중 적어도 하나를 포함한다.
일 실시예에서, 적어도 하나의 보안 방법은 CCF에 의해 결정되고, API 호출자가 가입된 서비스 타입, AEF와 API 호출자 사이의 인터페이스 타입, 필요한 보안 TLS 세션의 길이, 액세스 시나리오, API 호출자의 능력, AEF의 능력, API 호출자의 선호도(preferences) 및 적어도 하나의 API 호출자와 CCF 사이의 협상(negotiation) 중 적어도 하나에 기초하여 API 호출자에게 나타내어진다. 일 실시예에서, 적어도 하나의 결정된 보안 방법은 또한 CAPIF-2e 인터페이스 상에서 결정된 보안 방법을 수행하기 위해 CCF에 의해 AEF에 나타내어지거나, 요구되거나 요구되지 않는다.
일 실시예에서, 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대해 AEF가 C2eIS를 인에이블하는 단계는 결정된 적어도 하나의 보안 방법이 TLS-PSK인 경우에 CCF로부터 수신된 PSK(pre-shared key)를 사용하여 CAPIF-2e 인터페이스를 통해 적어도 하나의 API 호출자와의 보안 전송 계층 보안(Transport layer security, TLS) 연결을 설립하는 단계를 포함하며, 여기서 PSK는 CAPIF-1e 인터페이스를 통해 CCF와 적어도 하나의 API 호출자 사이의 보안 TLS 연결을 설립한 후 적어도 하나의 API 호출자 및 CCF 중 적어도 하나에 의해 도출된다. 또한, CAPIF-3 인터페이스를 통해 CCF로부터 적어도 하나의 API 호출자의 인가권(authorization rights)을 수신한다. 또한, 적어도 하나의 API 호출자가 CCF로부터 적어도 하나의 API 호출자의 수신된 인가권에 기초하여 적어도 하나의 서비스 API에 액세스하도록 인가한다.
일 실시예에서, 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대해 AEF가 C2eIS를 인에이블하는 단계는 결정된 적어도 하나의 보안 방법이 TLS-PKI인 경우에 클라이언트와 서버 인증서 기반 상호 인증(server certificate based mutual authentication)을 사용하여 CAPIF-2e 인터페이스를 통해 적어도 하나의 API 호출자와의 보안 TLS 연결을 설립하는 단계를 포함한다. 또한, CAPIF-3 인터페이스를 통해 CCF로부터 적어도 하나의 API 호출자의 인가권을 수신한다. 또한, 적어도 하나의 API 호출자가 CCF로부터 적어도 하나의 API 호출자의 수신된 인가권에 기초하여 적어도 하나의 서비스 API에 액세스하도록 인가한다.
일 실시예에서, 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대해 AEF가 C2eIS를 인에이블하는 단계는 결정된 적어도 하나의 보안 방법이 OAuth(Open Authorization: token-based authentication and authorization)인 경우에 인증서 기반 상호 인증을 사용하여 CAPIF-2e 인터페이스를 통해 적어도 하나의 API 호출자와의 보안 TLS 연결을 설립하는 단계를 포함한다. 또한, 액세스 토큰(access token)과 함께 적어도 하나의 API 호출자로부터 서비스 API 액세스 요청을 수신하며, 여기서 액세스 토큰은 CAPIF-1e 인터페이스를 통해 CCF와 적어도 하나의 API 호출자 사이의 보안 TLS 연결을 설립한 후 적어도 하나의 API 호출자로부터 OAuth 기반 액세스 토큰 요청을 수신할 때 CCF에 의해 생성된다. 또한, 적어도 하나의 API 호출자가 적어도 하나의 API 호출자로부터 수신된 액세스 토큰에 기초하여 적어도 하나의 서비스 API에 액세스하도록 인가한다.
일 실시예에서, 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대해 AEF가 C2eIS를 인에이블하는 단계는 결정된 적어도 하나의 보안 방법이 Oauth 2.0인 경우에 서버 인증서 기반 인증을 사용하여 CAPIF-2e 인터페이스를 통해 적어도 하나의 API 호출자와의 보안 TLS 연결을 설립하는 단계를 포함한다. 또한, 액세스 토큰과 함께 적어도 하나의 API 호출자로부터 서비스 API 액세스 요청을 수신하며, 여기서 액세스 토큰은 CAPIF-1e 인터페이스를 통해 CCF와 적어도 하나의 API 호출자 사이의 보안 TLS 연결을 설립한 후 적어도 하나의 API 호출자로부터 OAuth 2.0 기반 액세스 토큰 요청을 수신할 때 CCF에 의해 생성된다. 또한, 적어도 하나의 API 호출자가 적어도 하나의 API 호출자로부터 수신된 액세스 토큰에 기초하여 적어도 하나의 서비스 API에 액세스하도록 인가한다.
따라서, 본 명세서의 실시예는 공통 애플리케이션 프로그램 인터페이스 프레임워크(CAPIF)를 사용하여 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 시스템을 제공한다. 이러한 시스템은 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자로부터의 연결 요청을 수신할 때 적어도 하나의 API 호출자와의 보안 연결을 설립하도록 구성된 CAPIF 코어 기능부(CCF)를 포함하며, CCF와 적어도 하나의 API 호출자 사이에 보안 연결을 설립하는 것은 CAPIF-1e 인터페이스를 통한 CCF와 적어도 하나의 API 호출자 사이의 상호 인증에 기초한다. 또한, CCF는 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자의 C2Eis에 대한 적어도 하나의 API 호출자에 의해 사용되는 적어도 하나의 보안 방법을 결정하도록 구성되며, 적어도 하나의 보안 방법은 TLS-PSK(Transport Layers Security-Pre-Shared Key), TLS-PKI(TLS-Public Key Infrastructure), IKEv2(Internet Key Exchange version 2), IPsec(Internet Protocol Security), 애플리케이션 계층 보호, 기본 인가 메커니즘(native authorization mechanism) 및 OAuth 2.0 중 적어도 하나를 포함한다. 또한, 시스템은 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대해 C2eIS를 인에이블하도록 구성된 API 노출 기능부(AEF)를 포함한다. 일 실시예에서, 적어도 하나의 보안 방법은 API 호출자가 가입된 서비스 타입, AEF와 API 호출자 사이의 인터페이스 상세 사항, 액세스 시나리오, 필요한 보안 전송 계층 보안(TLS) 세션의 길이, API 호출자의 능력, AEF의 능력, API 호출자의 선호도 및 적어도 하나의 API 호출자와 CCF 사이의 협상 중 적어도 하나에 기초하여 결정된다.
본 명세서의 예시적인 실시예의 이러한 및 다른 양태는 다음의 설명 및 첨부된 도면과 함께 고려될 때 더 잘 인식되고 이해될 것이다. 그러나, 다음의 설명은 예시적인 실시예 및 이의 많은 특정 상세 사항을 나타내면서 제한이 아니라 예시로서 제공된다는 것이 이해되어야 한다. 본 명세서의 예시적인 실시예의 범위 내에서 본 개시의 사상을 벗어나지 않고 많은 변경 및 수정이 행해질 수 있으며, 본 명세서의 예시적인 실시예는 이러한 모든 수정을 포함한다.
본 개시의 효과는 상술한 효과에 한정되지 않는다. 게다가, 본 개시의 기술적 특징에 의해 예상되는 잠재적 효과는 다음의 설명으로부터 명확하게 이해될 수 있다.
아래의 상세한 설명을 착수하기 전에, 본 특허 문서 전체에 걸쳐 사용된 특정 단어 및 문구를 정의하는 것이 유리할 수 있다: 용어 "포함한다(include)" 및 "포함한다(comprise)"뿐만 아니라 이의 파생어는 제한 없이 포함(inclusion)을 의미하고; 용어 "또는"는 포괄적이며, 및/또는(and/or)을 의미한다. 문구 "와 관련된(associated with)" 및 "이와 관련된(associated therewith)" 뿐만 아니라 이의 파생어는 포함하고(include), 내에 포함되고(included within), 와 상호 연결하고(interconnect with), 함유하고(contain), 내에 함유되고(be contained within), 에 또는 와 연결하고(connect to or with), 에 또는 와 결합하고(couple to or with), 와 통신 가능하고(be communicable with), 와 협력하고(cooperate with), 인터리브하고(interleave), 병치하고(juxtapose), 에 가까이 있고(be proximate to), 에 또는 와 바운딩되고(be bound to or with), 가지고(have), 소유하고 있고(have a property of) 등인 것을 의미할 수 있으며; 용어 "제어기"는 적어도 하나의 동작을 제어하는 임의의 디바이스, 시스템 또는 이의 일부를 의미하고, 이러한 디바이스는 하드웨어, 펌웨어 또는 소프트웨어, 또는 이의 적어도 2개의 일부 조합으로 구현될 수 있다. 임의의 특정 제어기와 연관된 기능은 국부적으로든 또는 원격적으로든 중앙 집중되거나 분산될 수 있다는 것이 주목되어야 한다.
또한, 아래에서 설명되는 다양한 기능은 하나 이상의 컴퓨터 프로그램에 의해 구현되거나 지원될 수 있으며, 각각의 컴퓨터 프로그램은 컴퓨터 판독 가능 프로그램 코드(computer readable program code)로부터 형성되고, 컴퓨터 판독 가능 매체(computer readable medium)에서 구현된다. 용어 "애플리케이션" 및 "프로그램"은 적절한 컴퓨터 판독 가능 프로그램 코드에서 구현을 위해 적응된 하나 이상의 컴퓨터 프로그램, 소프트웨어 구성 요소(software components), 명령어 세트(sets of instructions), 절차, 기능, 객체(object), 클래스, 인스턴스, 관련된 데이터 또는 이의 일부를 지칭한다. 문구 "컴퓨터 판독 가능 프로그램 코드"는 소스 코드(source code), 객체 코드(object code) 및 실행 가능 코드(executable code)를 포함하는 임의의 타입의 컴퓨터 코드를 포함한다. 문구 "컴퓨터 판독 가능 매체"는 판독 전용 메모리(read only memory; ROM), 랜덤 액세스 메모리(random access memory; RAM), 하드 디스크 드라이브, 콤팩트 디스크(compact disc; CD), 디지털 비디오 디스크(digital video disc; DVD), 또는 임의의 다른 타입의 메모리와 같이 컴퓨터에 의해 액세스될 수 있는 임의의 타입의 매체를 포함한다. "비일시적(non-transitory)" 컴퓨터 판독 가능 매체는 일시적 전기적 또는 다른 신호를 송신하는 유선, 무선, 광학 또는 다른 통신 링크를 배제한다. 비일시적 컴퓨터 판독 가능 매체는 데이터가 영구적으로 저장될 수 있는 매체, 및 재기록 가능 광 디스크 또는 소거 가능 메모리 디바이스와 같이 데이터가 저장되고 나중에 중복 기록(overwriting)될 수 있는 매체를 포함한다.
특정 단어 및 문구에 대한 정의는 본 특허 문서 전체에 걸쳐 제공된다. 통상의 기술자는 대부분의 경우는 아니지만 이러한 정의가 이러한 정의된 단어 및 문구의 이전 및 이후의 사용에 적용된다는 것을 이해해야 한다.
본 명세서의 실시예는 첨부된 도면에 도시되어 있으며, 전체에 걸쳐 유사한 참조 문자는 다양한 도면에서 상응하는 부분을 나타낸다. 본 명세서의 실시예는 도면을 참조하여 다음의 설명으로부터 더 잘 이해될 것이다.
도 1은 본 명세서에 개시된 바와 같은 실시예에 따라 API 호출자를 인증 및 인가하기 위한 공통 애플리케이션 프로그램 인터페이스 프레임워크(CAPIF) 기능적 보안 메커니즘을 예시하는 시스템 다이어그램을 도시한다.
도 2는 본 명세서에 개시된 바와 같은 실시예에 따라 PSK(pre-shared key)를 사용하여 CAPIF-1e, CAPIF-2e 및 CAPIF-3 기준점을 통한 API 호출자의 인증 및 인가를 위한 보안 채널 설립을 예시하는 시퀀스 다이어그램을 도시한다.
도 3은 본 명세서에 개시된 실시예에 따라 인증서 기반 상호 인증을 사용하여 CAPIF-2e 및 CAPIF-3 기준점을 통한 API 호출자의 인증 및 인가를 위한 보안 채널 설립을 예시하는 시퀀스 다이어그램을 도시한다.
도 4는 본 명세서에 개시된 바와 같은 실시예에 따라 OAuth 기반 액세스 토큰을 사용하여 CAPIF-1e 및 CAPIF-2e 기준점을 통한 API 호출자의 인증 및 인가를 위한 보안 채널 설립을 예시하는 시퀀스 다이어그램을 도시한다.
도 5는 본 명세서에 개시된 바와 같은 실시예에 따라 서비스 API 호출 이전에 API 호출자와 API 노출 기능부(AEF) 사이의 인증을 위한 절차 흐름을 예시하는 시퀀스 다이어그램을 도시한다.
도 6은 본 명세서에 개시된 실시예에 따라 비-CCF(제3자 기반) 인증 절차를 예시하는 시퀀스 다이어그램을 도시한다.
도 7은 본 명세서에 개시된 실시예에 따라 CCF가 AEF에 의한 API 호출자의 인증 및 인가와, 이 사이의 보안 통신을 위한 메커니즘을 결정하는 시나리오를 예시하는 시퀀스 다이어그램을 도시한다.
도 8은 본 명세서에 개시된 실시예에 따라 CCF에 의해 결정되고 나타내어지는 바와 같은 TLS-PSK(transport layer security pre-shared key) 방법을 사용하여 Northbound API/서비스 API를 호출하는 API 호출자를 예시하는 시퀀스 다이어그램을 도시한다.
도 9는 본 명세서에 개시된 바와 같은 실시예에 따라 CCF에 의해 결정되고 나타내어지는 바와 같은 액세스 토큰 방법을 사용하여 Northbound API/서비스 API를 호출하는 API 호출자를 예시하는 시퀀스 다이어그램을 도시한다.
본 명세서의 예시적인 실시예 및 이의 다양한 특징 및 유리한 상세 사항은 첨부된 도면에 도시되고, 다음의 설명에서 상세히 설명되는 비제한적인 실시예를 참조하여 보다 완전하게 설명된다. 잘 알려진 구성 요소 및 처리 기술에 대한 설명은 본 명세서의 실시예를 불필요하게 모호하게 하지 않기 위해 생략된다. 본 명세서의 설명은 단지 본 명세서의 예시적인 실시예가 실시될 수 있는 방식의 이해를 용이하게 하고, 통상의 기술자가 본 명세서의 예시적인 실시예를 더 실시할 수 있도록 의도된다. 따라서, 본 개시는 본 명세서의 예시적인 실시예의 범위를 제한하는 것으로서 해석되지 않아야 한다. 통상의 기술자는 본 개시의 원리가 임의의 적절히 배치된 시스템 또는 디바이스로 구현될 수 있음을 이해할 것이다.
이하, 첨부된 도면을 참조하여 다양한 실시예가 설명될 것이다. 그러나, 본 개시를 본 명세서에 개시된 특정 형태로 제한하는 것으로 의도되지 않는다는 것이 이해되어야 하며; 오히려, 본 개시는 다양한 수정, 균등물 및/또는 실시예의 대안을 포함하도록 해석되어야 한다. 도면을 설명할 때, 유사한 참조 번호는 유사한 구성 요소를 명시하기 위해 사용될 수 있다.
본 명세서에 사용된 바와 같이, "가진다(have)", "가질 수 있다(may have)", "포함한다(include)" 또는 "포함할 수 있다(may include)"라는 표현은 상응하는 특징(예를 들어, 숫자, 기능, 동작, 또는 컴포넌트(component)와 같은 구성 요소)의 존재를 지칭하고, 하나 이상의 부가적인 특징을 배제하지 않는다.
본 개시에서, "A 또는 B", "A 또는/및 B 중 적어도 하나", 또는 "A 또는/및 B 중 하나 이상"이라는 표현은 열거된 항목의 모든 가능한 조합을 포함할 수 있다. 예를 들어, "A 또는 B", "A 및 B 중 적어도 하나" 또는 "A 또는 B 중 적어도 하나"라는 표현은 (1) 적어도 하나의 A, (2) 적어도 하나의 B 또는 (3) 적어도 하나의 A 및 적어도 하나의 B 둘 다를 포함할 수 있다.
다양한 실시예에서 사용되는 "제1", "제2", "제1" 또는 "제2"라는 표현은 순서 및/또는 중요도(importance)에 관계없이 다양한 구성 요소를 수정할 수 있지만, 상응하는 구성 요소를 제한하지는 않는다. 예를 들어, 제1 사용자 디바이스 및 제2 사용자 디바이스는 모두 사용자 디바이스일지라도 상이한 사용자 디바이스를 나타낸다. 예를 들어, 본 개시의 범위를 벗어나지 않고 제1 요소는 제2 요소로 명명될 수 있고, 유사하게 제2 요소는 제1 요소로 명명될 수 있다.
요소(예를 들어, 제1 요소)가 다른 요소(예를 들어, 제2 요소)에 (동작 가능하게 또는 통신 가능하게) "연결되거나" 또는 "결합되는" 것으로서 지칭될 때, 이는 다른 요소에 직접 연결되거나 직접 결합될 수 있거나, 임의의 다른 요소(예를 들어, 제3 요소)가 이 사이에 개재될 수 있다는 것이 이해되어야 한다. 대조적으로, 요소(예를 들어, 제1 요소)가 다른 요소(예를 들어, 제2 요소)에 "직접 연결되거나" 또는 "직접 결합되는" 것으로서 지칭될 때, 이 사이에 개재된 요소(예를 들어, 제3 요소)가 없다는 것이 이해될 수 있다.
본 명세서에 사용된 바와 같이, "에 구성된(configured to)"이라는 표현은 "에 적절한(suitable for)", "에 대한 능력을 갖는(having the capability to)", "에 설계된(designed to)", "에 적응된(adapted to)", "으로 만들어진(made to)", 또는 "가능한(capable of)"이라는 표현과 교환 가능하게 사용될 수 있다. "에 구성된"이라는 용어는 반드시 하드웨어에서 "에 특별히 설계된 것(specifically designed to)"을 의미할 수는 없다. 대안으로, 일부 상황에서, "에 구성된 디바이스(device configured to)"라는 표현은 디바이스가, 다른 디바이스 또는 구성 요소와 함께, "할 수 있다(is able to)"는 것을 의미할 수 있다. 예를 들어, "A, B 및 C를 수행하도록 적응된(또는 구성된) 프로세서(processor adapted (or configured) to perform A, B, and C)"라는 문구는 메모리 디바이스에 저장된 하나 이상의 소프트웨어 프로그램을 실행함으로써 상응하는 동작만을 수행하기 위한 전용 프로세서(예를 들어, 내장된 프로세서) 또는 상응하는 동작을 수행할 수 있는 범용 프로세서(예를 들어, 중앙 처리 유닛(CPU) 또는 애플리케이션 프로세서(AP))를 의미할 수 있다.
본 개시에서 사용된 용어는 단지 특정한 실시예를 설명하기 위해 사용되며, 본 개시를 제한하려는 의도가 아니다. 단수의 표현은 문맥에서 명백하게 상이하지 않으면 한 복수의 표현을 포함할 수 있다. 달리 정의되지 않으면, 기술적 또는 과학적인 용어를 포함하여 본 명세서에 사용된 모든 용어는 본 개시가 속하는 기술 분야에서 통상의 기술자에 의해 일반적으로 이해되는 것과 동일한 의미를 갖는다. 일반적으로 사용되는 사전에서 정의된 것과 같은 용어는 관련 기술 분야의 문맥상의 의미(contextual meanings)와 동일한 의미를 갖는 것으로 해석될 수 있으며, 본 개시에서 명확하게 정의되지 않으면 이상적이거나 지나치게 공식적인 의미를 갖는 것으로 해석되지 않아야 한다. 어떤 경우에, 본 개시에서 정의된 용어라도 실시예를 배제하는 것으로 해석되지 않아야 한다.
본 명세서의 실시예는 공통 애플리케이션 프로그램 인터페이스 프레임워크(CAPIF)를 사용하여 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법 및 시스템을 제공한다. 이러한 방법은 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자로부터 연결 요청을 수신할 때 CAPIF 코어 기능부(CCF)가 적어도 하나의 API 호출자와의 보안 연결을 설립하는 단계를 포함하며, CCF와 적어도 하나의 API 호출자 사이에 보안 연결을 설립하는 것은 CAPIF-1e 인터페이스를 통한 CCF와 적어도 하나의 API 호출자 사이의 상호 인증에 기초한다. 또한, 방법은 CCF가 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자의 C2eIS(즉, 인증, 인터페이스 보호 및 인가)를 위한 적어도 하나의 API 호출자에 의해 사용되는 적어도 하나의 보안 방법을 결정 및 지시하는 단계를 포함하며, 적어도 하나의 보안 방법은 TLS-PSK(Transport Layers Security-Pre-Shared Key), TLS-PKI(TLS-Public Key Infrastructure), IKEv2, IPsec 및 OAuth 2.0 중 적어도 하나를 포함한다. 방법은 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대해 API 노출 기능부(AEF)가 C2eIS를 인에이블하는 단계를 더 포함한다. 이제 도면, 특히 도 1 내지 도 9를 참조하면, 여기서 유사한 참조 부호는 도면 전체에 걸쳐 상응하는 특징을 일관되게 나타내고, 예시적인 실시예가 도시된다.
도 1은 본 명세서에 개시된 바와 같은 실시예에 따라 인터페이스를 인증하고 안전하게 하며, API 호출자(102)를 인가하기 위한 CAPIF 기능적 보안 메커니즘을 도시한 시스템(100) 다이어그램을 도시한다.
시스템(100)은 하나 이상의 API 호출자(102, 104), CAPIF 코어 기능부(CCF)(106), 애플리케이션 프로그램 인터페이스 노출 기능부(AEF)(108), API 퍼블리싱 기능부(publishing function)(110) 및 API 관리 기능부(112)를 포함한다. 일 실시예에서, 하나 이상의 API 호출자(102, 104)는 컴퓨터, 랩탑, 휴대 전화, 개인 휴대 정보 단말기(personal digital assistant, PAD) 및 서버 또는 하나 이상의 서비스 API를 위해 AEF(108)에 액세스하기를 시도하는 임의의 다른 디바이스 중 적어도 하나일 수 있지만 이에 제한되지는 않는다. 일 실시예에서, 하나 이상의 API 호출자는 네트워크 상에 존재하는 하나 이상의 서비스 API를 호출하도록 구성될 수 있다. CCF(106)는 서비스 API의 모든 공통 양태를 축적하도록 구성될 수 있는 기능적 엔티티이다. CCF(106)는 모든 서비스 API에 공통적인 인증, 모니터링, 로깅 인증(logging authorization), 디스커버리(discovery)를 위해 구성될 수 있다. AEF(108)는 하나 이상의 서비스 API를 API 호출자(즉, 102 및 104)에 노출시키기 위해 구성될 수 있는 엔티티이다. API 호출자(102)는 서비스 API를 호출하기 위해 AEF(108)와 직접 연결될 수 있다. 그러나, API 호출자(102)는 API 퍼블리싱 기능부(110) 및 API 관리 기능부(112)와 직접 연결되지 않을 수 있다. API 퍼블리싱 기능부(110)는 서비스 API의 라이브러리(library)를 CCF(106) 상에 퍼블리싱(publishing)하도록 구성될 수 있다. 또한, API 관리 기능부(112)는 CCF(106)에 저장된 로그(log)의 로깅 및 감사(auditing)의 기능 관련된 관리(functions related managing)를 관리하도록 구성될 수 있다.
일 실시예에서, PLMN(public land mobile network) 트러스트 도메인(trust domain)에 존재하는 API 호출자(104)는 오퍼레이터에 의해 신뢰되고, PLMN 트러스트 도메인 외부에 존재하는 API 호출자(102)는 오퍼레이터에 의해 신뢰(trust)되지 않을 수 있다. 오퍼레이터에 의해 신뢰되는 API 호출자(104)는 어떠한 보안 검사도 거치지 않을 수 있다. 그러나, PLMN 트러스트 도메인 외부에 존재하는 API 호출자(102)는 더 많은 레벨의 보안 검사를 거칠 수 있다.
또한, 시스템(100)은 하나 이상의 인터페이스/기준점을 포함한다. 하나 이상의 인터페이스는 CAPIF-1, CAPIF-1e, CAPIF-2, CAPIF-2e, CAPIF-3, CAPIF-4 및 CAPIF-5 인터페이스를 포함한다. 이러한 인터페이스는 3GPP(3rd Generation Partnership Project) TS 23.222 표준에 정의되어 있으며, CAPIF 기능은 3GPP TS 23.222 표준에 정의되어 있다. CAPIF-1, CAPIF-2, CAPIF-3, CAPIF-4 및 CAPIF-5 인터페이스는 PLMN(public land mobile network) 트러스트 도메인 내에 존재하지만, CAPIF-1e 및 CAPIF-2e 인터페이스는 CCF(106)와 PLMN 트러스트 도메인 외부에 존재하는 API 호출자(102)에 대한 AEF(108) 액세스 포인트 사이에 존재한다. CAPIF-1, CAPIF-2, CAPIF-3, CAPIF-4 및 CAPIF-5 인터페이스에 대한 보안은 3GPP TS 23.222 표준에 정의된 바와 같이 TLS(Transport Layer Security)를 지원한다.
PLMN 트러스트 도메인 내에 존재하고 PLMN 트러스트 도메인 외부에 존재하는 API 호출자(즉, 102, 104) 모두에 대해 인증 및 인가가 필요하다. PLMN 트러스트 도메인 외부에 존재하는 API 호출자(102)를 인증 및 인가하기 위해, CCF(106)는 AEF(108)와 협력해야 하고, CAPIF 서비스/서비스 API에 대한 액세스를 그랜트(grant)하기 전에 API 호출자(102)를 인증하고 인가하기 위해 CAPIF-1e, CAPIF-2e 및 CAPIF-3 인터페이스를 온보드(onboard)로 이용한다. API 호출자(104)가 PLMN 트러스트 도메인 내에 있을 때, CCF(106)는 AEF(108)와 협력하여 CAPIF 서비스에 대한 액세스를 그랜트하기 전에 CAPIF-1, CAPIF-2 및 CAPIF-3 인터페이스를 통해 API 호출자(104)의 인증 및 인가를 수행할 수 있다.
CAPIF-1/1-e는 API 호출자(102)와 CCF(106) 사이에 있다. 또한, 시스템(100)은 API 호출자(102)의 아이덴티티(identity) 및 크리덴셜(credential)에 기초하거나 유효한 보안 토큰을 제시하는 API 호출자(102)를 인증한다. API 호출자와 CCF 사이에는 상호 인증이 있다. 또한, 시스템(100)은 하나 이상의 서비스 API에 액세스하기 전에 API 호출자에 대한 인증을 제공한다. API 호출자(102)와 AEF(108) 사이의 CAPIF-2/2e에 대해, 시스템(100)은 API 호출자(102)의 아이덴티티 및 크리덴셜에 기초하거나 유효한 보안 토큰(OAuth)을 제시하는 API 호출자(102)를 인증한다. 또한, 시스템(100)은 서비스 API에 액세스하기 전에 API 호출자(102)에 대한 인증을 제공한다. 또한, 서비스 API에 액세스할 때 API 호출자에 대한 인가 및 검증이 있다. 또한, 시스템(100)은 PLMN 오퍼레이터가 설정한 정책(PLMN operator configured policies)에 기초하여 서비스 API 액세스를 제어한다. CAPIF-1e 및 CAPIF-2e는 API 호출자(102)가 PLMN 트러스트 도메인 외부에 있는 기준점이다.
본 명세서의 실시예는 CAPIF를 사용하여 API 호출자를 인증하는 방법 및 시스템(100)을 제공하며, 방법은 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자(102)로부터 연결 요청을 수신할 때 CCF(106)가 적어도 하나의 API 호출자(102)와의 보안 연결을 설립하는 단계를 포함한다. CCF(106)와 적어도 하나의 API 호출자(102) 사이에는 보안 연결이 설정되고, CAPIF-1e 인터페이스를 통한 CCF와 적어도 하나의 API 호출자(102) 사이의 상호 인증에 기초한다. 또한, 방법은 CCF(106)가 CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자(102)의 C2eIS(즉, 인증, 인터페이스 보호 및 인가)를 위한 적어도 하나의 API 호출자에 의해 사용되는 적어도 하나의 보안 방법을 결정하는 단계를 포함한다. 적어도 하나의 보안 방법은 TLS-PSK(Transport Layers Security-Pre-Shared Key), TLS-PKI(TLS-Public Key Infrastructure), IKEv2(Internet Key Exchange version 2), IPsec(Internet Protocol Security), 애플리케이션 계층 보호, 기본 인가 메커니즘 및 OAuth 중 적어도 하나를 포함한다. 또한, 방법은 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자(102)에 대해 AEF(108)가 C2eIS를 인에이블하는 단계를 포함한다. 일 실시예에서, 적어도 하나의 보안 방법은 API 호출자(102)가 가입된 서비스 타입, AEF(108)와 API 호출자(102) 사이의 인터페이스 타입, 액세스 시나리오, 필요한 보안의 전송 계층 보안(TLS) 세션의 길이, API 호출자(102)의 능력, AEF(108)의 능력, API 호출자(102)의 선호도 및 적어도 하나의 API 호출자(102)와 CCF(106) 사이의 협상 중 적어도 하나에 기초하여 결정된다. 일 실시예에서, 적어도 하나의 결정된 보안 방법은 또한 CAPIF-2e 인터페이스 상에서 결정된 보안 방법을 수행하기 위해 CCF(106)에 의해 AEF(108)에 나타내어지거나, 요구되거나 요구되지 않는다.
일 실시예에서, 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자(102)에 대해 AEF(108)가 C2eIS를 인에이블하는 단계는 결정된 적어도 하나의 보안 방법이 TLS-PSK인 경우에 CCF(106)로부터 수신된 PSK를 사용하여 CAPIF-2e 인터페이스를 통해 AEF(108)와 적어도 하나의 API 호출자(102) 사이의 보안 TLS 연결을 설립립하는 단계를 포함하며, 여기서 PSK는 CAPIF-1e 인터페이스를 통해 CCF(106)와 적어도 하나의 API 호출자(102) 사이의 보안 TLS 연결을 설립한 후 적어도 하나의 API 호출자(102) 및 CCF(106) 중 적어도 하나에 의해 도출된다. 또한, CAPIF-3 인터페이스를 통해 CCF로부터 적어도 하나의 API 호출자의 인가권을 수신한다. 또한, 적어도 하나의 API 호출자(102)가 CCF(106)로부터 적어도 하나의 API 호출자(102)의 수신된 인가권에 기초하여 적어도 하나의 서비스 API에 액세스하도록 인가한다.
일 실시예에서, API 호출자(102)는 서비스 API를 위해 AEF(108)와 직접 접촉하도록 발견하고 식별하며, 그 후 API 호출자(102)는 AEF(108)와의 인증을 직접 개시한다. 그 후, 클라이언트 및 서버 인증서에 기초한 상호 인증은 API 호출자(102)와 AEF(108) 사이에서 수행되어 CCF(106)의 도움으로 보안 TLS 연결을 설립해야 한다. 여기서, API 호출자(102)는 CCF(106)에 의해 또는 서비스 디스커버리 동안 미리 설정되거나 제공되고, 특정 서비스 API에 필요한 정보를 획득한다. 여기서, 서비스에 대한 결정된 보안 방법 및 관련된 유효한 보안 크리덴셜이 API 호출자(102)와 함께 이용 가능하다면, CCF(106)와 접촉하지 않고 AEF(108)와 직접 요청이 수행될 필요가 있다. 또한, AEF(108)는 API 호출자를 인증하기 위한 CCF(예를 들어, API 호출자(102)를 인증하기 위한 루트 인증서(root certificate)(106)가 AEF(108)와 함께 사전 제공되고 이용 가능한 경우)에 의존하지 않을 수 있다. API 호출자(102)와 AEF(108) 사이의 CAPIF-2e 상에서 보안 TLS 연결을 성공적으로 설정한 후, AEF(108)는 CAPIF-3 기준점을 통해 CCF(106)로부터 API 호출자(102)의 인가를 요청한다. 또한, CCF(106)는 CAPIF-3을 통해 API 호출자(102)의 인가에 응답한다. 또한, CAPIF-2e 인터페이스를 통한 보안 TLS 연결을 설립할 때, API 호출자(102)는 적용 가능한 3GPP 노스바운드(northbound) API/서비스 API를 호출한다. 또한, AEF(108)는 API 호출자(102)의 인가권에 기초한 API 호출을 받아들인다(honor).
일 실시예에서, 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자에 대해 AEF(108)가 C2eIS를 인에이블하는 단계는 결정된 적어도 하나의 보안 방법이 TLS-PKI인 경우에 클라이언트와 서버 인증서 기반 상호 인증을 사용하여 CAPIF-2e 인터페이스를 통해 적어도 하나의 API 호출자(102)와의 보안 TLS 연결을 설립하는 단계를 포함한다. 또한, CAPIF-3 인터페이스를 통해 CCF(106)로부터 적어도 하나의 API 호출자(102)의 인가권을 수신한다. 또한, 적어도 하나의 API 호출자(102)가 CCF(106)로부터 적어도 하나의 API 호출자(102)의 수신된 인가권에 기초하여 적어도 하나의 서비스 API에 액세스하도록 인가한다.
일 실시예에서, 결정된 적어도 하나의 보안 방법에 기초하여 적어도 하나의 API 호출자(102)에 대해 AEF(108)가 C2eIS를 인에이블하는 단계는 결정된 적어도 하나의 보안 방법이 OAuth인 경우에 인증서 기반 상호 인증 및 서버 측 인증서 기반 인증 중 적어도 하나를 사용하여 CAPIF-2e 인터페이스를 통해 AEF(108)와 적어도 하나의 API 호출자(102) 사이의 보안 TLS 연결을 설립하는 단계를 포함한다. 또한, 액세스 토큰과 함께 적어도 하나의 API 호출자(102)로부터 서비스 API 액세스 요청을 수신하며, 여기서 액세스 토큰은 CAPIF-1e 인터페이스를 통해 CCF(106)와 적어도 하나의 API 호출자(102) 사이의 보안 TLS 연결을 설립한 후 적어도 하나의 API 호출자(102)로부터 OAuth 기반 액세스 토큰 요청을 수신할 때 CCF(106)에 의해 생성된다. 또한, 적어도 하나의 API 호출자(102)가 적어도 하나의 API 호출자(102)로부터 수신된 액세스 토큰에 기초하여 적어도 하나의 서비스 API에 액세스하도록 인가한다.
일 실시예에서, CAPIF에 대해 제안된 보안 양태 및 관련 정보 흐름은 제5 세대(5G) 시스템에 대해 정의된 기계 타입 통신 및 서비스 기반 아키텍처(Machine Type Communication and Service Based Architecture)에 대해 정의된 T8 인터페이스와 같은 다른 기준점에 적용 가능하다.
도 1은 시스템(100)의 예시적인 유닛을 도시하지만, 다른 실시예는 이에 제한되지 않는다는 것이 이해되어야 한다. 다른 실시예에서, 시스템(100)은 더 적거나 더 많은 수의 유닛을 포함할 수 있다. 또한, 유닛의 라벨 또는 명칭은 예시를 위해서만 사용되며, 본 명세서의 실시예의 범위를 제한하지 않는다. 시스템(100)에서 동일하거나 실질적으로 유사한 기능을 수행하기 위해 하나 이상의 유닛이 조합될 수 있다.
도 2는 본 명세서에 개시된 바와 같은 실시예에 따라 PSK를 사용하여 CAPIF-1e, CAPIF-2e 및 CAPIF-3 기준점을 통한 API 호출자(102)의 인증 및 인가를 위한 보안 채널 설립을 도시하는 시퀀스 다이어그램을 도시한다.
도 2에 따르면, 본 명세서의 실시예는 API 호출자(102)를 인증하기 위한 전용 보안 연결/세션을 설정한다. API 호출자(102)와 AEF(108) 사이의 전용 보안 연결은 PSK 기반 및 인증서 기반 방법과 같은 2개의 상이한 방법을 사용하여 설정될 수 있다. 설정된 전용 보안 세션은 모든 API 호출 및 응답을 위해 사용될 수 있다. 전용 보안 세션을 설정하기 위해, CAPIF-1e 인터페이스를 통해 CCF(106)와 API 호출자(102) 사이의 성공적인 상호 인증 후에 PSK가 도출될 수 있다. 또한, PSK는 CAPIF-2e 인터페이스를 통해 API 호출자(102)와 AEF(108) 사이의 보안 연결(예를 들어, TLS 또는 IPSec)을 설정하는데 사용될 수 있다. CAPIF-1e 보안 메커니즘은 CAPIF-2e에 대한 보안 TLS 연결을 인증하기 위한 키를 "부트스트랩(bootstrap)"하는데 사용될 수 있다. PSK가 없으면, API 호출자(102)와 AEF(108) 사이의 인증서 기반 상호 인증은 CAPIF-2e 인터페이스를 통해 보안 TLS 세션을 설정하는데 사용될 수 있다.
도 2는 PSK를 사용하여 보안 채널을 설정하기 위한 API 호출자(102), CCF(106) 및 AEF(108) 사이의 높은 수준의 보안 정보 흐름을 도시한다(액세스 시나리오의 경우: API 호출자(102)는 서비스 API 호출 이전에 AEF(108)에 액세스함). 보안 정보는 CAPIF-1e, CAPIF-2e 및 CAPIF-3 기준점을 통해 교환되고, 아래 단계에서 상세히 설명된다.
단계 1에서, 방법은 CAPIF-1e 인터페이스를 통해 API 호출자(102)와 CCF(106) 사이에 보안 TLS 세션/연결을 설립하는 단계를 포함한다. 방법은 API 호출자(102)와 CCF(106)가 CAPIF-1e 인터페이스를 통해 API 호출자(102)와 CCF(106) 사이에 보안 TLS 세션/연결을 설립하도록 한다. 보안 TLS 세션은 API 호출자(102)와 CCF(106) 사이의 상호 인증에 기초하여 API 호출자(102)와 CCF(106) 사이에서 설정될 수 있다. 상호 인증은 인증서 기반 상호 인증(즉, 클라이언트(즉, API 호출자(102)) 및 서버(즉, CCF(106) 인증서에 기초한 상호 인증)일 수 있다.
단계 2에서, 방법은 CAPIF-1e 인터페이스를 통해 PSK를 도출하는 단계를 포함한다. 방법은 API 호출자(102) 및 CCF(106)가 PSK를 도출하도록 한다. 보안 TLS 세션을 성공적으로 설정한 후, PSK는 TLS 세션의 마스터 시크릿(master secret), AEF(108)의 특정 파라미터, 세션 파라미터 및 다른 가능한 파라미터를 기반으로 도출될 수 있다. 일 실시예에서, CCF(106)에서의 PSK의 도출은 PSK에 대한 요청이 AEF(108)로부터 수신될 때까지 지연될 수 있다. 일 실시예에서, PSK는 특정 AEF(108)에만 해당한다(PSK는 AEF ID에 바인딩(binding)됨). AEF ID는 적어도 CAPIF 내에서의 고유 식별자이다. AEFPSK = KDF(TLS Session Master_Secret, TLS Session 파라미터, AEF ID, <다른 잠재적 파라미터>). KDF는 Key Derivation Function이다. AEFPSK와 PSK 용어는 이러한 문서 전체에서 교환 가능하게 사용된다.
단계 3a에서, 방법은 AEF(108)와 함께 보안 채널 설립(TLS-PSK) 요청을 개시하는 단계를 포함한다. 방법은 API 호출자(102)가 AEF(108)와 함께 TLS-PSK 요청을 개시할 수 있게 한다. API 호출자(102)에서 PSK를 도출할 때, API 호출자(102)는 AEF(108)와의 보안 채널 설립 요청을 개시한다. 일 실시예에서, API 호출자(102)는 API 호출자(102)와 AEF(108) 사이에 보안 TLS 연결을 설립하기 전에 언제든지 PSK를 도출할 수 있다.
단계 3b에서, 방법은 CAPIF-3 기준점을 통해 API 호출자(108)로부터 도출된 CCF(106)로부터 PSK를 요청하는 단계를 포함한다. 방법은 AEF(108)가 CAPIF-3 기준점을 통해 API 호출자(102)로부터 도출된 PSK에 대한 CCF(106)를 요청할 수 있게 한다.
단계 3c에서, 방법은 CAPIF-3 기준점을 통해 CCF(106)로부터 PSK를 수신하는 단계를 포함한다. 방법은 AEF(108)가 CAPIF-3 기준점을 통해 CCF(106)로부터 PSK를 수신할 수 있게 한다. CCF(106)는 AEF(108)로부터 요청을 수신할 때 CAPIF-3 기준점을 통해 도출된 PSK에 응답하도록 설정될 수 있다. 일 실시예에서, CCF(106)는 AEF(108)로부터의 어떠한 요청도 없이 통지 메시지에서 PSK를 도출하여 이를 AEF(108)로 송신할 수 있다. 이러한 경우에, 도 2에 도시된 바와 같은 단계 3b 및 3c는 대기 시간(latency)을 줄이기 위해 생략될 수 있다.
단계 3d에서, 방법은 PSK를 사용하여 API 호출자(102)와 AEF(108) 사이에 보안 TLS 연결을 설립하는 단계를 포함한다. 방법은 AEF(108)가 PSK를 사용하여 API 호출자(102)와 AEF(108) 사이에 보안 TLS 연결을 설립할 수 있게 한다. API 호출자(102)와 AEF(108) 사이의 보안 TLS 연결은 CAPIF-2e 인터페이스를 통해 설정될 수 있다.
단계 4에서, 방법은 CAPIF-3 기준점을 통해 CCF(106)로부터 API 호출자(102)의 인가권을 요청하는 단계를 포함한다. 방법은 AEF(108)가 CAPIF-3 기준점을 통해 CCF(106)로부터 API 호출자(102)의 인가권을 요청할 수 있게 한다.
단계 5에서, 방법은 CAPIF-3을 통해 CCF(106)로부터 API 호출자(102)의 인가권을 수신하는 단계를 포함한다. 방법은 AEF(108)가 CAPIF-3 인터페이스를 통해 CCF(106)로부터 API 호출자(102)의 인가권을 수신할 수 있게 한다.
단계 6에서, 방법은 보안 CAPIF-2e 인터페이스를 통해 AEF와 함께 적용 가능한 3GPP 노스바운드 API/서비스 API를 호출하는 API 호출자(102)를 포함한다.
단계 7에서, 방법은 CCF(106)로부터 적어도 하나의 API 호출자(102)의 수신된 인가권에 기초하여 적어도 하나의 API 호출자(102)가 적어도 하나의 서비스 API에 액세스하도록 인가하는 단계를 포함한다. 방법은 CCF(108)로부터 적어도 하나의 API 호출자(102)의 수신된 인가권에 기초하여 AEF(108)로 하여금 적어도 하나의 API 호출자(102)가 적어도 하나의 서비스 API에 액세스하도록 인가할 수 있게 한다. AEF(108)는 API 호출자(102)의 인가권에 기초한 API 호출을 받아들인다.
도 3은 본 명세서에 개시된 바와 같은 실시예에 따라 인증서 기반 상호 인증을 사용하여 CAPIF-2e 및 CAPIF-3 기준점을 통해 API 호출자(102)의 인증 및 인가를 위한 보안 채널 설립을 도시하는 시퀀스 다이어그램을 도시한다.
본 명세서의 실시예는 CAPIF-2e 및 CAPIF-3 기준점을 통한 보안 정보의 교환을 허용한다.
단계 1a에서, API 호출자(102)는 서비스 API를 위해 AEF(108)와 직접 접촉하도록 발견하고 식별하며, 그 후 API 호출자(102)는 AEF(108)와의 인증을 직접 개시한다. 또한, 클라이언트 및 서버 인증서에 기초한 상호 인증은 API 호출자(102)와 AEF(108) 사이에서 수행되어 CCF(106)의 도움으로 보안 TLS 연결을 설립해야 한다(단계 1b). 이러한 시나리오에서, API 호출자는 CCF(106)에 의해 또는 서비스 디스커버리 동안 미리 설정되거나 제공되고, 특정 서비스 API에 필요한 정보를 획득한다. 여기서, API 호출자(102)는 CCF(106)와 접촉하지 않고(또는 후에) AEF와의 연결을 직접 요청할 수 있다. CAPIF-2e 상에서(즉, API 호출자(102)와 AEF(108) 사이에서) 보안 TLS 연결을 성공적으로 설정한 후, AEF(108)는 CAPIF-3 기준점을 통해 CCF(106)로부터 API 호출자(102)의 인가권을 요청한다. 또한, CCF(106)는 CAPIF-3 기준점을 통해 API 호출자(102)의 인가권에 응답한다. 또한, CAPIF-2e 인터페이스를 통한 보안 TLS 연결을 설립할 때, API 호출자(102)는 적용 가능한 3GPP 노스바운드 API/서비스 API를 호출한다. 또한, AEF(108)는 API 호출자(102)의 인가권에 기초한 API 호출을 받아들인다.
도 4는 본 명세서에 개시된 바와 같은 실시예에 따라 OAuth 기반 액세스 토큰을 사용하여 CAPIF-1e 및 CAPIF-2e 기준점을 통해 API 호출자(102)의 인증 및 인가를 위한 보안 채널 설립을 도시하는 시퀀스 다이어그램을 도시한다. 본 명세서의 실시예는 CAPIF-1e 인터페이스를 통해 보안 채널을 설정한다. CAPIF-2e 기준점은 액세스 토큰을 사용하여 AEF(108)에 대한 API 호출자(102)의 서비스 API 호출을 인가하고 받아들인다.
도 4는 API 호출자(102), CCF(106) 및 AEF(108) 사이의 높은 수준의 보안 정보 흐름을 도시한다. 보안 정보는 CAPIF-1e, CAPIF-2e 및 CAPIF-3 기준점을 통해 교환될 수 있다. 방법은 OAuth 2.0 인증 프레임워크를 기반으로 한다. OAuth 2.0과 관련하여, CCF(106)은 인증 및 토큰 프로토콜 엔드포인트(token protocol endpoint)에 매핑된다. 또한, API 호출자(102)는 자원 소유자, 클라이언트 및 리디렉션 엔드포인트(redirection endpoint)에 매핑되고, AEF(108)는 자원 서버에 매핑된다. 액세스 토큰을 사용하여 CAPIF-1e 및 CAPIF-2e 기준점을 통해 API 호출자(102)의 인증 및 인가에 대한 예시는 클라이언트 엔드포인트 타입이 크리덴셜(credentials)로서 등록되고, 인가 그랜트 타입(authorization grant type)이 클라이언트 크리덴셜이고, 액세스 토큰이 베어러 타입(RFC 6750)이고 JWT(JSON 웹 토큰)를 기반으로 한다는 가정에 기초한다.
단계 1에서, 방법은 API 호출자(102) 및 CCF(108)가 CAPIF-1e 인터페이스를 통해 인증서 기반 상호 인증에 기초하여 보안 TLS 세션을 설정하는 단계를 포함한다. 방법은 API 호출자(102) 및 CCF(106)가 인증서 기반 상호 인증에 기초하여 보안 TLS 세션을 설정할 수 있게 한다.
단계 2에서, 방법은 https 요청을 사용하여 CCF(106)로부터 액세스 토큰을 요청하는 단계를 포함한다. 방법은 API 호출자(102)가 https 요청을 사용하여 CCF(106)로부터 액세스 토큰을 요청할 수 있게 한다. CAPIF-1e를 통해 보안 TLS 세션을 성공적으로 설정한 후, API 호출자(102)는 https 요청을 사용하여 CCF(106)로부터 액세스 토큰을 요청한다. https 요청은 그랜트 타입 "client_credentials", 범위(scope)(요청된 허가(permissions) 세트), API 호출자 클라이언트 식별자 및 CCF(106)에 등록하는 동안 생성되어 공유된 시크릿(secret)을 포함한다.
단계 3에서, 방법은 유효한 크리덴셜, 요청 타입 및 요청된 범위에 대해 API 호출자(102)로부터 그랜트 요청을 검증하는 단계를 포함한다. 방법은 CCF(106)가 유효한 크리덴셜, 요청 타입 및 요청된 범위에 대해 API 호출자(102)로부터 그랜트 요청을 검증할 수 있게 한다.
단계 4에서, 방법은 액세스 토큰을 생성하는 단계를 포함한다. 방법은 CCF(106)가 액세스 토큰을 생성할 수 있게 한다. CCF(106)에 의한 성공적인 그랜트 요청 검증 후, 액세스 토큰이 생성될 수 있다. 생성된 액세스 토큰은 IETF RFC 7519에 정의된 바와 같은 JSON Web Token으로서 인코딩될 수 있다. 액세스 토큰은 IETF RFC 7515에 정의된 바와 같은 JSON 웹 디지털 서명 프로파일을 포함할 수 있다. 또한, 액세스 토큰은 리디렉션 균일 자원 식별자(uniform resource identifier, URI)를 통해 공유되며, 여기서 URI는 CCF(106)에 등록하는 동안 API 호출자(102)에 의해 제공된다.
단계 5에서, 방법은 CAPIF-2e 인터페이스를 통해 서버 인증서에 기초하여 AEF(108)의 엔드포인트의 단방향 인증을 사용하여 AEF(108)와의 보안 TLS 연결을 설립하는 단계를 포함한다. 방법은 API 호출자(102)가 CAPIF-2e 인터페이스를 통해 서버 인증서에 기초하여 AEF(108)의 엔드포인트의 단방향 인증을 사용하여 AEF(108)와의 보안 TLS 연결을 설립할 수 있게 한다.
단계 6에서, 방법은 액세스 토큰과 함께 3GPP 노스바운드 API/서비스 API에 대한 액세스 요청/호출을 CAPIF-2e 인터페이스를 통해 AEF(108)에 송신하는 단계를 포함한다(액세스 시나리오의 경우: API 호출자(102)는 서비스 API를 호출할 때 AEF(108)에 액세스함). 방법은 API 호출자(102)가 액세스 토큰과 함께 3GPP 노스바운드 API/서비스 API에 대한 액세스 요청/호출을 CAPIF-2e 인터페이스를 통해 AEF(108)에 송신할 수 있게 한다. CCF(106)로부터 수신된 액세스 토큰은 API 호출 요청과 함께 송신될 수 있다. 토큰은 https 요청(API 호출)의 "Authorization" 헤더 아래에 "Bearer" 특성 값으로서 배치된다.
단계 7에서, 방법은 액세스 토큰의 일부인 서명에 기초하여 액세스 토큰을 검증하는 단계를 포함한다. 방법은 AEF(108)가 액세스 토큰의 일부인 서명에 기초하여 액세스 토큰을 검증할 수 있게 한다. 유효한 서명은 액세스 토큰의 허가권(authorization permissions)에 대한 API 호출자의 요청을 검증한다.
단계 7에서, API 호출자(102)의 액세스 토큰 및 인가권을 성공적으로 검증할 때, 요청된 서비스 API는 호출되고, 적절한 결과는 API 호출자(102)에 대한 응답으로서 송신된다.
일 실시예에서, 다양한 요소 및 요구 사항이 적절한 보안 방법(즉, PSK 및 OAuth.2.0)의 적용성에 영향을 줄 수 있다. 그러나 비즈니스 요구 사항의 필요는 보안 방법을 선택하기 위한 일반적인 요소일 수 있지만, 구현은 보안 방법을 결정할 때 다음의 기준을 사용할 수 있다.
방법 1에 대한 선택 기준(즉, PSK 기반): 이러한 방법은 전용 보안 세션을 설정할 수 있다. 전용 보안 TLS 세션이 (세션 시작 중에 인가로) 설정될 때, 이것은 모든 호출 요청에 대한 인가 검증을 피하는 여러 API 호출에 사용될 수 있다. 이러한 방법은 다음의 기준/시나리오에 기초하여 선택될 수 있다.
1. 보안 TLS 채널 세션이 오랜 지속 시간(예컨대, 12시간 이상) 동안 활성적일 필요가 있는 경우, API 호출자(102)는 모든 요청에 대해 보안 TLS 연결을 설립하지 않고 일정 기간을 통해 API 호출에 대한 이러한 세션을 사용한다.
2. 짧은 기간(예컨대, 5분 내에 500번의 호출) 내에 API 호출의 빠른 버스트(burst)가 필요한 경우, API 호출자(102)는 이러한 방법을 사용하여 AEF(108)로 전용 보안 TLS 세션을 설정하고, 모든 호출 요청에 대한 인가 검증을 피할 수 있다.
3. API 호출자(102) 또는 CAPIF-2e 기준점 또는 AEF(108)가 최소화될 메시지 교환의 크기, 최소화된 전력 소비 등과 같은 엄격한 요구 사항을 갖는 경우. API 호출자(102)는 이러한 방법을 선택할 수 있다.
방법 2에 대한 선택 기준(즉, OAuth): 이러한 방법은 OAuth 2.0을 기반으로 하고, 보안 비동기 API 호출 요청 및 응답을 위한 프레임워크를 제공한다. 이러한 방법은 다음의 기준/시나리오에 기초하여 선택될 수 있다.
API 호출이 드물고, 보안 세션에 대한 필요성이 오래 지속되지 못하면, OAuth 2.0이 선택될 수 있다.
AEF(108) 상에서 이용 가능한 자원이 인증 후 보안 TLS 세션을 유지하기에 적합하지 않은 경우, 예를 들어, 네트워크 로드(load)로 인해, 인증 및 인가 기능은 별개의 네트워크 엔티티로서 오프로드(offload)된다. 그런 다음, OAuth 2.0은 선택될 수 있다.
보안 방법(PSK 기반 또는 OAuth 또는 PKI 기반 등 중 하나)은 액세스 시나리오, 요청된 서비스 상의 특성 및 제약 조건(constraints), 인터페이스 상세 사항(interface details)(예컨대, IP 주소/포트), 기준점의 상태, 엔티티의 능력 등을 기반으로 결정되고 선택될 수 있다.
도 5는 본 명세서에 개시된 바와 같은 실시예에 따라 서비스 API 호출 이전에 API 호출자(102)와 AEF(108) 사이의 인증을 위한 절차 흐름을 도시하는 시퀀스 다이어그램을 도시한다.
본 명세서의 실시예는 API 호출자(102)가 AEF(108)와 직접 접촉할 수 있게 하고, AEF(108)로 인증한다(CCF(106)로 수행하기 위한 전제 조건이 필요하지 않음). 서비스 디스커버리가 이미 수행된 경우, API 호출자(102)는 API 호출자(102)가 후속 API 호출을 위해 발견한 AEF(108)의 AEF 인증서를 검증하기 위해 CCF(106)에게 루트 인증서 기관(certificate authority, CA)의 루트 인증서를 제공하도록 요청한다. CA는 오퍼레이터에 의해 호스팅될 수 있거나 오퍼레이터에 의해 트러스트된다. 대안으로, CCF(106)는 서비스 디스커버리의 시간 또는 인가의 시간 또는 인증 중에 또는 독립적/독점적 메시지 교환(요청-응답)으로서 API 호출자(102)에 (가입된) 상응하는 AEF(108) 상세 사항을 갖는 AEF 인증서를 검증하기 위해 CA의 루트 인증서의 리스트를 제공한다.
일 실시예에서, 서비스 디스커버리 절차 동안, AEF(108)에 대한 상세 사항은 API 호출자(102)의 서비스 디스커버리 요청에 응답하여 CCF(106)에 의해 API 호출자(102)에 제공된다. AEF(108)의 상세 사항은 보안 파라미터(예컨대, 인증 방법, AEF 인증서를 검증하기 위한 CA의 루트 인증서, 토큰, 보안 크리덴셜(토큰)의 수명 및 액세스 방법(TLS-PSK 또는 TLS 인증서 또는 액세스 토큰 기반 또는 TLS 공개 키 암호화를 사용하는 CAPIF 기반(서비스 요청 전의 CCF에 의한 인증), 제3 자 토큰 기반(Third Party Token based)을 포함한다. 다른 실시예에서, API 호출자(102)는 서비스 디스커버리 요청에서 인증 방법에 대한 선호도(preference)(예를 들어, 서비스 요청의 예상 빈도에 기초한 선호도)를 포함할 수 있다. API 호출자(102)로부터 요청을 수신할 때, CCF(106)는 API 호출자(102)의 선호도 및 다른 기준을 고려하여 인증 방법을 결정한다. CCF(106)는 요청에 응답하여 선택된 인증 방법을 API 호출자(102)에 나타낸다. 일 실시예에서, 인디케이션(indicatioln)(선택된 인증 방법 및 기준점 보호(인터페이스 보안))은 보안 TLS 연결 요청/프로토콜에 포함된다.
도 5에 따르면, API 호출자(102)는 노스바운드 API/서비스 API를 호출하기 전에 AEF(108)로 인증한다. 이러한 시나리오에서, 보안 PSK 기반 또는 인증서 기반 보안 연결 설정 방법이 사용될 수 있다. PSK 기반 또는 인증서 기반 방법은 API 호출자(102)가 AEF(108)로 인증하는 절차를 예시하고, 후속 API 호출을 보안하기 위해 TLS 세션을 설정한다.
도 6은 본 명세서에 개시된 바와 같은 실시예에 따라 Non-CCF(제3자 기반) 인증 절차를 도시하는 시퀀스 다이어그램을 도시한다. 본 명세서의 실시예는 API 호출자(102)와 AEF(108) 사이의 인터페이스를 보안하기 위해 Non-CCF(제3자 기반) 인증 절차를 제공한다. 이러한 시나리오에서, API 호출자는 CCF(106)에 의해 또는 서비스 디스커버리 동안 미리 설정되거나 제공되고, 특정 서비스 API에 필요한 정보를 획득한다. 또한, 요청은 CCF(106)와 접촉하지 않고(또는 후에) AEF(108)로 직접 이루어질 필요가 있다.
도 7은 본 명세서에 개시된 실시예에 따라 CCF가 AEF(108)에 의한 API 호출자(102)의 인증 및 인가와 이들 간의 보안 통신을 위한 메커니즘을 결정하는 시나리오를 도시하는 시퀀스 다이어그램을 도시한다.
단계 1에서, API 호출자(102) 및 CCF(106)는 예를 들어 클라이언트 및 서버 인증서를 기반으로 하는 상호 인증을 사용하는 TLS에 대한 보안 통신 채널을 설정한다.
단계 2에서, API 호출자(102)는 보안 방법 요청을 CCF(106)에 송신한다. CCF(106)에 대한 요청은 API 호출자 ID, API 호출자(102)의 바람직한 보안 방법과 함께 서비스 상세 사항, 인터페이스 상세 사항, 노스바운드 API 상세 사항과 같은 AEF(108)의 상세 사항을 포함한다.
단계 3에서, CCF(106)는 API 호출자(102)의 인증 및 인가를 위해 AEF(108)에 의해 사용될 보안 방법을 선택한다. 선택은 단계 2에서 API 호출자(102)로부터 수신된 정보를 고려한다.
일 실시예에서, CCF(106)는 모든 요청된 AEF의 각각의 요청된 인터페이스에 대해 PSK 기반, PKI 기반, OAuth 2.0, IKEv2, IPsec, 애플리케이션 계층 보안 등의 기반 보안 방법 중 적어도 하나를 선택한다.
일 실시예에서, 인증 방법은 다음의 파라미터: API 호출자(102)가 가입한 서비스의 타입, 인터페이스 상세 사항(예컨대, IP 주소/포트), AEF(108)와 API 호출자(102) 사이의 프로토콜, 특정 서비스에 액세스하기 위해 요청될 때(다수의 서비스가 가입될 때), 시간 기반 시나리오(가입된 API), TLS 세션이 얼마나 오래 지속되어야 하는지에 대한 필요성, API 호출자의 능력, AEF(108)의 능력, API 호출자(102)로부터의 요청(사용자 입력, 사용 시간, 이전에 알려진 요청의 수)에 기초하여, 특정 방법은 (AEF 또는 API 호출자마다) CCF(106)에 의해 선택되고, API 호출자(102)에 나타내어진다.
일 실시예에서, AEF(108)에 의한 API 호출자(102)의 보안 통신, 인증 및 인가 방법은 AEF(108)의 서비스 API 인터페이스 상세 사항, 즉 동일한(또는 상이한) AEF(108)의 둘 이상의 API 인터페이스 상에 호스팅된 동일한 서비스 API와 연관되고, 서비스가 필요한 경우 각각의 API 인터페이스에 상응하는 상이한 보안 방법을 가질 수 있다. CCF(106)는 보안 방법을 결정할 때 이러한 정보를 고려한다.
단계 4에서, CCF(106)는 각각의 AEF(108)(또는 AEF의 각각의 서비스 API 인터페이스)에 대해 선택된 보안 방법, 선택된 보안 방법과 관련된 모든 보안 정보(예를 들어, TLS 및/또는 IPsec를 직접 설정하고/하거나 IKEv2를 통해 IPsec를 설정하기 위한 Pre Shared Key 등)를 나타내는 보안 방법 응답을 API 호출자(102)에 송신한다. API 호출자(102)는 AEF(108)와의 후속 통신 설정에서 이러한 선택된 보안 방법을 사용해야 한다.
도 8은 본 명세서에 개시된 바와 같은 실시예에 따라 CCF(106)에 의해 결정되고 나타내어진 바와 같은 TLS-PSK 방법을 사용하여 노스바운드 API/서비스 API를 호출하는 API 호출자(102)를 도시하는 시퀀스 다이어그램을 도시한다.
CCF(106)는 인증 응답을 API 호출자(102)에 송신할 수 있다. 또한, API 호출자(102)는 인증과 함께 서비스 API 호출 요청을 AEF(108)에 송신한다. 또한, API 호출자(102) 정보는 인증을 위해 획득된다. 또한, AEF는 PSK에 기초하여 검증 및 인증을 식별한다. 또한, AEF는 API 호출자(102)에 서비스 API 호출 응답을 제공한다.
도 9는 본 명세서에 개시된 바와 같은 실시예에 따라 CCF(106)에 의해 결정되고 지시된 바와 같은 액세스 토큰 방법을 사용하여 노스바운드 API/서비스 API를 호출하는 API 호출자(102)를 도시하는 시퀀스 다이어그램을 도시한다.
도 9에 따르면, CCF(106)는 API 호출자(102)로부터의 인증 요청에 기초하여 API 호출자(102)에 인증 응답을 공유한다. 또한, API 호출자(102)는 인증 정보와 함께 서비스 API 호출 요청을 AEF-2(108)에 제공한다. 또한, AEF-2(108)는 인증을 위한 API 호출자(102) 정보를 수신하도록 설정될 수 있다. 또한, AEF-2(108)는 API 호출자(102)에 의해 제시된 토큰에 기초하여 아이덴티티 검증 및 인증을 수행하고, API 호출자(102)와 AEF(108) 사이의 보안 TLS 연결을 설립한다. 또한, 아이덴티티 검증 및 인증에 기초하여, AEF- 2(108)은 서비스 API 호출 응답을 제공한다.
본 명세서에 개시된 실시예는 적어도 하나의 하드웨어 디바이스 상에서 실행되고, 요소를 제어하기 위해 네트워크 관리 기능을 수행하는 적어도 하나의 소프트웨어 프로그램을 통해 구현될 수 있다. 도 1에 도시된 요소는 하드웨어 디바이스, 또는 하드웨어 디바이스 및 소프트웨어 모듈의 조합 중 적어도 하나일 수 있다. 예를 들어, 본 명세서에 개시된 실시예는 5G 코어 네트워크에서 네트워크 노출 기능부(NEF)를 관리하는 네트워크 엔티티로 구현될 수 있고, 네트워크 엔티티는 송수신기를 포함하는 서버 및 NEF와 관련된 개시된 절차를 처리하도록 구성된 프로세서로서 구현될 수 있다.
특정 실시예에 대한 상술한 설명이 본 명세서의 실시예의 일반적인 특성을 충분히 밝힘으로써, 다른 실시예가 현재의 지식을 적용함으로써 일반적인 개념으로부터 벗어나지 않고 이러한 특정 실시예를 용이하게 수정하고/하거나 적응할 수 있으며, 따라서, 이러한 적응 및 수정은 개시된 실시예의 등가물의 의미 및 범위 내에서 이해되어야 하고 의도된다. 본 명세서에 사용된 문구 또는 용어는 설명을 위한 것이며 제한하려는 것이 아님을 이해해야 한다. 따라서, 본 명세서의 실시예는 실시예와 관련하여 설명되었지만, 통상의 기술자는 본 명세서의 실시예가 본 명세서에 설명된 바와 같은 실시예의 사상 및 범위 내에서 수정하여 실시될 수 있음을 인식할 것이다.

Claims (11)

  1. 공통 애플리케이션 프로그램 인터페이스 프레임워크(CAPIF)를 사용하여 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법에 있어서,
    CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 적어도 하나의 API 호출자로부터의 연결 요청을 수신할 때 CAPIF 코어 기능부(CCF)가 적어도 하나의 API 호출자와의 보안 연결을 설립하는 단계;
    상기 CCF가 CAPIF-2e 인터페이스 상에서 상기 적어도 하나의 서비스 API에 액세스하기 위해 상기 적어도 하나의 API 호출자의 CAPIF-2e 인터페이스 보안(C2eIS)을 위해 상기 적어도 하나의 API 호출자에 의해 사용되는 적어도 하나의 보안 방법을 결정하는 단계; 및
    API 노출 기능부(AEF)가 결정된 적어도 하나의 보안 방법에 기초하여 상기 적어도 하나의 API 호출자에 대해 상기 C2eIS를 인에이블하는 단계를 포함하는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법.
  2. 제 1 항에 있어서,
    상기 CCF와 상기 적어도 하나의 API 호출자 사이에 상기 보안 연결을 설립하는 단계는 CAPIF-1e 인터페이스를 통한 상기 CCF와 상기 적어도 하나의 API 호출자 사이의 상호 인증에 기초하는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법.
  3. 제 1 항에 있어서,
    상기 적어도 하나의 보안 방법은 TLS-PSK(Transport Layers Security-Pre-Shared Key), TLS-PKI(TLS-Public Key Infrastructure), IKEv2(Internet Key Exchange version 2), IPsec(Internet Protocol Security), 애플리케이션 계층 보호, 기본 인가 메커니즘 및 OAuth 2.0 중 적어도 하나를 포함하는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법.
  4. 제 1 항에 있어서,
    상기 C2eIS는 상기 적어도 하나의 API 호출자의 인증, 인터페이스 보호 및 인가 중 적어도 하나를 포함하는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법.
  5. 제 1 항에 있어서,
    상기 적어도 하나의 보안 방법은 상기 API 호출자가 가입된 서비스 타입, 상기 AEF와 상기 API 호출자 사이의 인터페이스 상세 사항, 필요한 보안 TLS(Transport layer security) 세션의 길이, 상기 API 호출자의 능력, 상기 AEF의 능력, 상기 API 호출자의 선호도, 및 상기 적어도 하나의 API 호출자와 상기 CCF 사이의 협상 중 적어도 하나에 기초하여 결정되는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법.
  6. 제 1 항에 있어서,
    상기 결정된 적어도 하나의 보안 방법에 기초하여 상기 적어도 하나의 API 호출자에 대해 상기 AEF가 상기 C2eIS를 인에이블하는 단계는,
    상기 결정된 적어도 하나의 보안 방법이 TLS-PSK - 상기 PSK는 상기 CAPIF-1e 인터페이스를 통해 상기 CCF와 상기 적어도 하나의 API 호출자 사이의 상기 보안 TLS 연결을 설립한 후 상기 적어도 하나의 API 호출자 및 상기 CCF 중 적어도 하나에 의해 도출됨 - 인 경우에 상기 CCF로부터 수신된 PSK(pre-shared key)를 사용하여 상기 CAPIF-2e 인터페이스를 통해 상기 적어도 하나의 API 호출자와의 보안 TLS 연결을 설립하는 단계;
    상기 CAPIF-3 인터페이스를 통해 상기 CCF로부터 상기 적어도 하나의 API 호출자의 인가권을 수신하는 단계; 및
    상기 적어도 하나의 API 호출자가 상기 CCF로부터 상기 적어도 하나의 API 호출자의 수신된 인가권에 기초하여 상기 적어도 하나의 서비스 API에 액세스하도록 인가하는 단계를 포함하는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법.
  7. 제 1 항에 있어서,
    상기 결정된 적어도 하나의 보안 방법에 기초하여 상기 적어도 하나의 API 호출자에 대해 상기 AEF가 상기 C2eIS를 인에이블하는 단계는,
    상기 결정된 적어도 하나의 보안 방법이 상기 TLS-PKI인 경우에 클라이언트와 서버 인증서 기반 상호 인증을 사용하여 상기 CAPIF-2e 인터페이스를 통해 상기 적어도 하나의 API 호출자와의 보안 TLS 연결을 설립하는 단계;
    상기 CAPIF-3 인터페이스를 통해 상기 CCF로부터 상기 적어도 하나의 API 호출자의 인가권을 수신하는 단계; 및
    상기 적어도 하나의 API 호출자가 상기 CCF로부터 상기 적어도 하나의 API 호출자의 수신된 인가권에 기초하여 상기 적어도 하나의 서비스 API에 액세스하도록 인가하는 단계를 포함하는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법.
  8. 제 1 항에 있어서,
    상기 결정된 적어도 하나의 보안 방법에 기초하여 상기 적어도 하나의 API 호출자에 대해 상기 AEF가 상기 C2eIS를 인에이블하는 단계는,
    상기 결정된 적어도 하나의 보안 방법이 Oauth 2.0인 경우에 인증서 기반 상호 인증 및 서버 인증서 기반 인증 중 적어도 하나를 사용하여 상기 CAPIF-2e 인터페이스를 통해 상기 적어도 하나의 API 호출자와의 보안 TLS 연결을 설립하는 단계;
    액세스 토큰 - 상기 액세스 토큰은 상기 CAPIF-1e 인터페이스를 통해 상기 CCF와 상기 적어도 하나의 API 호출자 사이의 상기 보안 TLS 연결을 설립한 후 상기 적어도 하나의 API 호출자로부터 OAuth 2.0 기반 액세스 토큰 요청을 수신할 때 상기 CCF에 의해 생성됨 - 과 함께 상기 적어도 하나의 API 호출자로부터 서비스 API 액세스 요청을 수신하는 단계; 및
    상기 적어도 하나의 API 호출자가 상기 적어도 하나의 API 호출자로부터 수신된 액세스 토큰에 기초하여 상기 적어도 하나의 서비스 API에 액세스하도록 인가하는 단계를 포함하는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법.
  9. 제 1 항에 있어서,
    상기 적어도 하나의 보안 방법은 상기 적어도 하나의 API 호출자의 C2eIS에 대한 상기 보안 프로토콜의 상세 사항을 포함하는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 방법.
  10. 공통 애플리케이션 프로그램 인터페이스 프레임워크(CAPIF)를 사용하여 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 장치에 있어서,
    CAPIF-2e 인터페이스 상에서 적어도 하나의 서비스 API에 액세스하기 위해 상기 적어도 하나의 API 호출자로부터의 연결 요청을 수신할 때 적어도 하나의 API 호출자와의 보안 연결을 설립하고;
    CAPIF-2e 인터페이스 상에서 상기 적어도 하나의 서비스 API에 액세스하기 위해 상기 적어도 하나의 API 호출자의 CAPIF-2e 인터페이스 보안(C2eIS)을 위해 상기 적어도 하나의 API 호출자에 의해 사용되는 적어도 하나의 보안 방법을 결정하도록 구성된 CAPIF 코어 기능부(CCF); 및
    상기 결정된 적어도 하나의 보안 방법에 기초하여 상기 적어도 하나의 API 호출자에 대해 상기 C2eIS를 인에이블하도록 구성된 API 노출 기능부(AEF)를 포함하는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 장치.
  11. 제 10 항에 있어서,
    제 2 항 내지 제 9 항 중 어느 한 항에 따라 동작하도록 구성되는, 애플리케이션 프로그램 인터페이스(API) 호출자를 인증하는 장치.
KR1020207014132A 2017-11-16 2018-11-16 애플리케이션 프로그램 인터페이스(api) 호출자를 인증하는 방법 및 시스템 KR102591619B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020237035362A KR20230152766A (ko) 2017-11-16 2018-11-16 애플리케이션 프로그램 인터페이스(api) 호출자를 인증하는 방법 및 시스템

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
IN201741041088 2017-11-16
IN201741041088??? 2018-11-05
PCT/KR2018/014062 WO2019098730A1 (en) 2017-11-16 2018-11-16 Method and system for authenticating application program interface (api) invokers

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020237035362A Division KR20230152766A (ko) 2017-11-16 2018-11-16 애플리케이션 프로그램 인터페이스(api) 호출자를 인증하는 방법 및 시스템

Publications (2)

Publication Number Publication Date
KR20200083498A true KR20200083498A (ko) 2020-07-08
KR102591619B1 KR102591619B1 (ko) 2023-10-19

Family

ID=66433799

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020237035362A KR20230152766A (ko) 2017-11-16 2018-11-16 애플리케이션 프로그램 인터페이스(api) 호출자를 인증하는 방법 및 시스템
KR1020207014132A KR102591619B1 (ko) 2017-11-16 2018-11-16 애플리케이션 프로그램 인터페이스(api) 호출자를 인증하는 방법 및 시스템

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020237035362A KR20230152766A (ko) 2017-11-16 2018-11-16 애플리케이션 프로그램 인터페이스(api) 호출자를 인증하는 방법 및 시스템

Country Status (5)

Country Link
US (2) US11303676B2 (ko)
EP (2) EP3972310A1 (ko)
KR (2) KR20230152766A (ko)
CN (2) CN111373712B (ko)
WO (1) WO2019098730A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024071697A1 (ko) * 2022-09-28 2024-04-04 삼성전자 주식회사 이동 통신 시스템에서 사용자 동의 정보를 관리하는 방법 및 장치

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110046001B (zh) * 2018-01-15 2022-03-25 华为技术有限公司 一种授权撤回的方法及装置
CN110348205B (zh) * 2018-04-08 2022-04-22 华为技术有限公司 一种api拓扑隐藏方法、设备及系统
US11140169B1 (en) * 2018-10-31 2021-10-05 Workday, Inc. Cloud platform access system
CN113867980A (zh) * 2019-01-14 2021-12-31 华为技术有限公司 调用应用程序接口的方法和装置
US10785652B1 (en) 2019-09-11 2020-09-22 Cisco Technology, Inc. Secure remote access to a 5G private network through a private network slice
CN117221385A (zh) * 2020-02-14 2023-12-12 瑞典爱立信有限公司 用于服务api发布的方法、网络实体和介质
US11818173B2 (en) * 2020-05-29 2023-11-14 Palo Alto Networks, Inc. Reducing memory footprint after TLS connection establishment
CN116097219A (zh) * 2020-08-06 2023-05-09 华为技术有限公司 应用程序接口调用方法及其装置、系统
CN114844945A (zh) * 2021-02-01 2022-08-02 中国移动通信有限公司研究院 网络能力管理方法、能力开放平台及网络能力管理系统
US11620363B1 (en) 2021-03-15 2023-04-04 SHAYRE, Inc. Systems and methods for authentication and authorization for software license management
EP4295564A4 (en) * 2021-03-23 2024-05-22 Samsung Electronics Co., Ltd. METHOD AND SYSTEM FOR DISCOVERING A TARGET APPLICATION PROGRAM INTERFACE
US11632362B1 (en) * 2021-04-14 2023-04-18 SHAYRE, Inc. Systems and methods for using JWTs for information security
US11621830B1 (en) 2021-06-28 2023-04-04 SHAYRE, Inc. Systems and methods for facilitating asynchronous secured point-to-point communications
WO2023144649A1 (en) * 2022-01-28 2023-08-03 Lenovo (Singapore) Pte. Ltd. Application programming interface (api) access management in wireless systems
CN117378171A (zh) * 2022-05-09 2024-01-09 北京小米移动软件有限公司 订阅处理方法、装置、介质和芯片
WO2024021137A1 (zh) * 2022-07-29 2024-02-01 北京小米移动软件有限公司 Api调用者认证方法以及装置、通信设备及存储介质
WO2024031722A1 (zh) * 2022-08-12 2024-02-15 北京小米移动软件有限公司 北向应用程序接口api调用方法及装置
CN117641358A (zh) * 2022-08-12 2024-03-01 华为技术有限公司 通信方法和通信装置
WO2024031723A1 (zh) * 2022-08-12 2024-02-15 北京小米移动软件有限公司 应用程序接口api调用方法及装置
WO2024060067A1 (en) * 2022-09-21 2024-03-28 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for internet protocol security authentication
CN118120176A (zh) * 2022-09-29 2024-05-31 北京小米移动软件有限公司 一种api的调用方法、装置、设备及存储介质
WO2024100055A1 (en) * 2022-11-07 2024-05-16 Telefonaktiebolaget Lm Ericsson (Publ) Application programming interface access in a communication network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080134237A1 (en) * 2006-08-18 2008-06-05 Sony Corporation Automatically reconfigurable multimedia system with interchangeable personality adapters
KR20160045635A (ko) * 2013-05-21 2016-04-27 삼성전자주식회사 통신용 논리 채널을 이용한 전자 장치
KR20170063842A (ko) * 2014-09-26 2017-06-08 알까뗄 루슨트 제3자 데이터 공유를 위한 프라이버시 보호

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4829822B2 (ja) 2007-03-19 2011-12-07 株式会社リコー 遠隔機器管理システム
CN104598257B (zh) * 2013-10-30 2019-01-18 华为技术有限公司 远程应用程序运行的方法和装置
US20160277413A1 (en) * 2015-03-20 2016-09-22 Kabushiki Kaisha Toshiba Access Permission Device, Access Permission Method, Program, and Communicating System
US9602292B2 (en) 2015-07-25 2017-03-21 Confia Systems, Inc. Device-level authentication with unique device identifiers
US10432631B2 (en) * 2016-03-11 2019-10-01 Oracle International Corporation System and method for providing a universal security handler for a cloud-based integration platform
EP3586257B1 (en) * 2017-02-22 2022-10-26 Fingerprint Cards Anacatum IP AB Biometrics-based remote login
CN109587187A (zh) * 2017-09-28 2019-04-05 华为技术有限公司 用于调用网络功能服务的方法、装置和系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080134237A1 (en) * 2006-08-18 2008-06-05 Sony Corporation Automatically reconfigurable multimedia system with interchangeable personality adapters
KR20160045635A (ko) * 2013-05-21 2016-04-27 삼성전자주식회사 통신용 논리 채널을 이용한 전자 장치
KR20170063842A (ko) * 2014-09-26 2017-06-08 알까뗄 루슨트 제3자 데이터 공유를 위한 프라이버시 보호

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024071697A1 (ko) * 2022-09-28 2024-04-04 삼성전자 주식회사 이동 통신 시스템에서 사용자 동의 정보를 관리하는 방법 및 장치

Also Published As

Publication number Publication date
CN111373712A (zh) 2020-07-03
EP3695575A1 (en) 2020-08-19
KR20230152766A (ko) 2023-11-03
CN116405938A (zh) 2023-07-07
EP3695575A4 (en) 2020-11-11
CN111373712B (zh) 2023-04-04
KR102591619B1 (ko) 2023-10-19
US20220217178A1 (en) 2022-07-07
US20190149576A1 (en) 2019-05-16
EP3972310A1 (en) 2022-03-23
US11303676B2 (en) 2022-04-12
EP3695575B1 (en) 2022-01-05
WO2019098730A1 (en) 2019-05-23

Similar Documents

Publication Publication Date Title
KR102591619B1 (ko) 애플리케이션 프로그램 인터페이스(api) 호출자를 인증하는 방법 및 시스템
EP3752941B1 (en) Security management for service authorization in communication systems with service-based architecture
US10645583B2 (en) Security management for roaming service authorization in communication systems with service-based architecture
CN109428717B (zh) 管理具有多个证书颁发者的嵌入式通用集成电路卡调配
US9825937B2 (en) Certificate-based authentication
JP6086987B2 (ja) ホットスポットネットワークにおける未知のデバイスに対する制限付き証明書登録
CN113796111A (zh) 在无线通信系统中提供移动边缘计算服务的装置和方法
EP3834449A1 (en) Network function authentication based on public key binding in access token in a communication system
JP2020506578A (ja) ユーザ機器の二次認証
US11070355B2 (en) Profile installation based on privilege level
TW201345217A (zh) 具區域功能性身份管理
WO2019041802A1 (zh) 基于服务化架构的发现方法及装置
US10148651B2 (en) Authentication system
JP2016511849A (ja) 独立アイデンティティ管理システム
WO2020053481A1 (en) Network function authentication using a digitally signed service request in a communication system
TW201306610A (zh) 驗證協定之自動協商及選擇
US20210037007A1 (en) Method and device for performing onboarding
US20210112411A1 (en) Multi-factor authentication in private mobile networks
KR20200130141A (ko) 무선 통신 시스템에서 모바일 엣지 컴퓨팅 서비스를 제공하기 위한 장치 및 방법
KR20230121093A (ko) Msgin5g 서버의 인증 및 인가 방법 및 시스템
US20220116774A1 (en) Methods and systems for authentication and establishment of secure connection for edge computing services
TW201225697A (en) Identity management on a wireless device
Spoorthi et al. Mobile single sign-on solution for enterprise cloud applications
WO2024062373A1 (en) Registration handling of ledger-based identity
CN116419220A (zh) 认证和/或密钥管理方法、第一设备、终端及通信设备

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant