KR101453155B1 - Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법 - Google Patents

Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법 Download PDF

Info

Publication number
KR101453155B1
KR101453155B1 KR1020120057167A KR20120057167A KR101453155B1 KR 101453155 B1 KR101453155 B1 KR 101453155B1 KR 1020120057167 A KR1020120057167 A KR 1020120057167A KR 20120057167 A KR20120057167 A KR 20120057167A KR 101453155 B1 KR101453155 B1 KR 101453155B1
Authority
KR
South Korea
Prior art keywords
resource
client
access
service provider
provider domain
Prior art date
Application number
KR1020120057167A
Other languages
English (en)
Other versions
KR20130133988A (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 KR1020120057167A priority Critical patent/KR101453155B1/ko
Priority to PCT/KR2012/009879 priority patent/WO2013180357A1/ko
Priority to US14/403,977 priority patent/US9319413B2/en
Publication of KR20130133988A publication Critical patent/KR20130133988A/ko
Application granted granted Critical
Publication of KR101453155B1 publication Critical patent/KR101453155B1/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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • 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
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/02—Access restriction performed under specific conditions
    • 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols

Abstract

M2M 통신에서 리소스 접근 권한 설정 방법를 개시한다.
본 실시예에 의하면, M2M 서비스 제공자 도메인상의 리소스에 접근하고자 하는 개체가 해당 리소스에 접근하기 위한 인증키로서 MAS(M2M Authentication Server)로부터 임시 접근을 위한 액세스 토큰(Access Token)를 발급받아 사용함으로써, 다수의 개체 간의 정보 공유를 할 수 있는 동시에 권한이 없는 개체가 타 개체의 정보에 접근하는 것을 방지하고, 개체 간 리소스 데이터를 공유에 있어서 발생할 수 있는 보안상 위협을 방지할 수 있는 M2M 통신에서 리소스 접근 권한 설정 방법을 제공한다.

Description

Ｍ2Ｍ 통신에서 리소스 접근 권한 설정 방법{Method for Authorizing Access to Resource in M2M Communications}
본 발명은 M2M(Machine-to-Machine) 통신에서 리소스 접근 권한 설정 방법에 관한 것이다. 더욱 상세하게는 M2M 통신에서 개체들이 다른 개체(D/GSCL)상에 위치한 리소스에 접근하고자 할 때, 해당 리소스에 대한 각 개체의 접근 권한을 설정하는 리소스 접근 권한 설정 방법에 관한 것이다.
이 부분에 기술된 내용은 단순히 본 실시예에 대한 배경 정보를 제공할 뿐 종래기술을 구성하는 것은 아니다.
일반적으로, M2M 통신은 다양한 장치(Machine)에 무선통신 모듈이 장착되어 사람의 개입 없이 또는 최소한의 사람의 개입으로 다양한 통신 서비스를 가능하게 하는 기술로서, 기존의 인간 대 인간 중심의 통신에서 더 나아가 장치와 장치 사이의 통신 서비스를 가능하게 하는 기술이다. 이러한 M2M 기술은 단순히 사람과 장치 또는 장치와 장치 간 단순한 데이터 전송 차원의 통신 기능에서 벗어나 통신과 IT 기술을 결합하여 다양한 장치들의 정보를 수집하고 이를 유용한 정보로 가공하여 필요한 정보를 맞춤형으로 제공해 주기 위한 솔루션으로 그 범위가 확대되고 있다.
현재 진행 중인 한 M2M 관련 표준에서는 M2M 단말 또는 M2M 게이트웨이와 M2M 서버 등에서 관리되는 정보 데이터를 리소스 데이터로 표현하고 있다. M2M 서비스 구조를 데이터 정보처리 측면에서 보면, M2M 단말 및 M2M 게이트웨이에서 수집된 데이터들을 M2M 서버로 전송하고, M2M 서비스 제공자(M2M Service Provider)의 네트워크 애플리케이션(Network Application: NA)이 실제 리소스 데이터의 소유자의 별도의 접근 허가 절차 없이 서비스 제공자의 정책에 의해 M2M 서버의 리소스 데이터에 접근하여 정보를 조회하는 구조로 되어 있다. M2M 기술의 표준화는 현재 초기 단계로서 리소스 데이터에 접근할 수 있는 권한을 설정하는 방법에 대해 구체적으로 제시하고 있지 않으며, 이러한 권한 설정에 대한 방법을 모색하기 위해 노력하고 있는 상황이다.
본 실시예는, 다양한 M2M 통신 환경에서 개체들 간에 자신의 리소스 데이터를 다른 개체와 공유할 수 있도록, 리소스에 접근할 수 있는 권한을 설정해 주는 방법을 제공하는 데 주된 목적이 있다.
본 실시예의 일 측면에 의하면, 제1 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)가 제2 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스(Resource)에 접근하고자 하는 경우에 있어서, 상기 클라이언트가 상기 제1 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 제1 M2M 서비스 제공자 도메인의 MAS(M2M Authentication Sever; 이하 'MAS1'이라고 칭함)로부터 클라이언트 크리덴셜(Client Credentials)을 할당받는 클라이언트 등록 과정, 상기 클라이언트가 상기 리소스의 URI(Universal Resource Identifier) 정보를 기초로 하여 상기 제2 M2M 서비스 제공자 도메인의 NSCL(이하 'NSCL2'라고 칭함)을 통해 상기 리소스의 리소스 소유자에게 상기 리소스에 대한 접근 권한부여(Authorization)를 요청하는 권한부여 요청 과정, 상기 리소스 소유자가 상기 MAS1을 통해 상기 클라이언트를 검증(Verification)하는 클라이언트 검증 과정, 상기 리소스 소유자가 상기 클라이언트에 대한 접근 권한부여를 승인하는 권한부여 승인 과정 및 상기 제2 M2M 서비스 제공자 도메인의 MAS(이하 'MAS2'라고 칭함)가 상기 클라이언트에게 액세스 토큰(Access Token)을 발급하는 액세스 토큰 발급 과정을 포함하는 M2M 통신에서 리소스 접근 권한 설정 방법을 제공한다.
본 실시예의 다른 측면에 의하면, 제1 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)가 제2 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하는 방법에 있어서, 상기 제1 M2M 서비스 제공자 도메인의 NSCL(이하 'NSCL1'이라고 칭함)에 클라이언트 등록 절차를 수행하여 상기 제1 M2M 서비스 제공자 도메인의 MAS(이하 'MAS1'이라 칭함)로부터 클라이언트 크리덴셜을 할당받는 과정, 상기 리소스의 리소스 소유자에게 상기 리소스의 URI 정보를 기초로 하여 상기 리소스에 대한 접근 권한부여를 요청하는 권한부여 요청 과정, 상기 제 2 M2M 서비스 제공자 도메인에 속하는 MAS(이하 'MAS2'이라 칭함)로부터 액세스 토큰을 발급받는 액세스 토큰 발급 과정 및 상기 발급받은 액세스 토큰을 기초로 상기 리소스에 접근하는 과정을 포함하는 것을 특징으로 하는 M2M 통신에서 클라이언트의 리소스 접근 방법을 제공한다.
본 실시예의 또다른 측면에 의하면, 제1 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스를 소유하는 리소스 소유자가, 제2 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 및 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)의 상기 리소스에 대한 접근권한을 부여하는 방법에 있어서, 상기 클라이언트에 관한 권한부여 요청을 수신하는 과정, 상기 제2 M2M 서비스 제공자 도메인에 속하는 MAS(이하 'MAS2'이라 칭함)를 통해 상기 클라이언트를 검증하는 과정 및 상기 리소스가 위치한 개체 및 상기 제1 M2M 서비스 제공자 도메인에 속하는 MAS(이하 'MAS1'라고 칭함)에 상기 클라이언트에 대한 접근 권한부여를 승인하는 과정을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법을 제공한다.
본 실시예의 또다른 측면에 의하면, 어떠한 M2M 서비스 제공자 도메인에도 속하지 않는 개체(이하 '클라이언트'라고 칭함)가 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하고자 하는 경우에 있어서, 상기 클라이언트가 상기 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 M2M 서비스 제공자 도메인의 MAS로부터 클라이언트 크리덴셜을 할당받는 클라이언트 등록 과정, 상기 클라이언트가 상기 리소스의 URI 정보를 기초로 하여 상기 M2M 서비스 제공자 도메인의 NSCL을 통해 상기 리소스의 리소스 소유자에게 상기 리소스에 대한 접근 권한부여를 요청하는 권한부여 요청 과정, 상기 리소스 소유자가 상기 M2M 서비스 제공자 도메인의 MAS를 통해 상기 클라이언트를 검증하는 클라이언트 검증 과정, 상기 리소스 소유자가 상기 MAS에 상기 클라이언트에 대한 접근 권한부여를 승인하는 권한부여 승인 과정 및 상기 MAS가 상기 클라이언트에게 액세스 토큰을 발급하는 액세스 토큰 발급 과정을 포함하는 M2M 통신에서 리소스 접근 권한 설정 방법을 제공한다.
본 실시예의 또다른 측면에 의하면, 어떠한 M2M 서비스 제공자 도메인에도 속하지 않는 개체(이하 '클라이언트'라고 칭함)가 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하는 방법에 있어서, 상기 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 M2M 서비스 제공자 도메인의 MAS로부터 클라이언트 크리덴셜을 할당받는 과정, 상기 리소스의 리소스 소유자에게 상기 리소스의 URI 정보를 기초로 하여 상기 리소스에 대한 접근 권한부여를 요청하는 과정, 상기 MAS로부터 액세스 토큰을 발급받는 과정 및 상기 발급받은 액세스 토큰을 기초로 상기 리소스에 접근하는 과정을 포함하는 것을 특징으로 하는 M2M 통신에서 클라이언트의 리소스 접근 방법을 제공한다.
본 실시예의 또다른 측면에 의하면, M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스를 소유한 리소스 소유자가, 어떠한 M2M 서비스 제공자 도메인에도 속하지 않는 개체(이하 '클라이언트'라고 칭함)의 상기 리소스에 대한 접근권한을 부여하는 방법에 있어서, 상기 클라이언트에 관한 권한부여 요청을 수신하는 과정, 상기 M2M 서비스 제공자 도메인에 속하는 MAS(이하 'MAS'이라 칭함)를 통해 상기 클라이언트를 검증하는 과정 및 상기 리소스가 위치한 개체 및 상기 MAS에 상기 클라이언트에 대한 접근 권한부여를 승인하는 과정을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법을 제공한다.
본 실시예의 또다른 측면에 의하면, 어느 한 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저(이하 '클라이언트'라고 칭함)가 동일한 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하고자 하는 경우에 있어서, 상기 클라이언트가 상기 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 M2M 서비스 제공자 도메인의 MAS로부터 클라이언트 크리덴셜을 할당받는 클라이언트 등록 과정, 상기 클라이언트가 상기 리소스의 URI 정보를 기초로 하여 상기 M2M 서비스 제공자 도메인의 NSCL을 통해 상기 리소스의 리소스 소유자에게 상기 리소스에 대한 접근 권한부여를 요청하는 권한부여 요청 과정, 상기 리소스 소유자가 상기 M2M 서비스 제공자 도메인의 MAS를 통해 상기 클라이언트를 검증하는 클라이언트 검증 과정, 상기 리소스 소유자가 상기 클라이언트에 대한 접근 권한부여를 승인하는 권한부여 승인 과정 및 상기 MAS가 상기 클라이언트에게 액세스 토큰을 발급하는 액세스 토큰 발급 과정을 포함하는 M2M 통신에서 리소스 접근 권한 설정 방법을 제공한다.
본 실시예의 또다른 측면에 의하면, 어느 한 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)가 동일한 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하는 방법에 있어서, 상기 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 M2M 서비스 제공자 도메인의 MAS로부터 클라이언트 크리덴셜을 할당받는 과정, 상기 리소스의 리소스 소유자에게 상기 리소스의 URI 정보를 기초로 하여 상기 리소스에 대한 접근 권한부여를 요청하는 과정, 상기 M2M 서비스 제공자 도메인의 MAS로부터 액세스 토큰을 발급받는 과정 및 상기 발급받은 액세스 토큰을 기초로 상기 리소스에 접근하는 과정을 포함하는 것을 특징으로 하는 M2M 통신에서 클라이언트의 리소스 접근 방법을 제공한다.
본 실시예의 또다른 측면에 의하면, M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스를 소유한 리소스 소유자가 상기 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)의 상기 리소스에 대한 접근권한을 부여하는 방법에 있어서, 상기 클라이언트에 관한 권한부여 요청을 수신하는 과정, 상기 M2M 서비스 제공자 도메인에 속하는 MAS를 통해 상기 클라이언트를 검증하는 과정 및 상기 리소스가 위치한 개체 및 상기 MAS에 상기 클라이언트에 대한 접근 권한부여를 승인하는 과정을 포함하는 것을 특징으로 하는 M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법을 제공한다.
본 실시예의 또다른 측면에 의하면, DSCL 또는 GSCL상에 리소스를 보유한 단말 또는 게이트웨이가 상기 리소스에 대한 클라이언트의 접근을 허용하는 방법에 있어서, 상기 리소스의 리소스 소유자로부터 상기 클라이언트에 관한 접근권한 설정 요청을 수신하는 과정, 상기 클라이언트의 상기 리소스에 관한 접근권한을 설정하는 과정, AAA 서비스를 제공하는 서버로부터 상기 클라이언트에게 발급한 액세스 토큰을 전달받는 과정 및 상기 AAA 서비스를 제공하는 서버로부터 전달받은 액세스 토큰과 상기 클라이언트가 제시하는 액세스 토큰의 일치 여부를 바탕으로 상기 클라이언트의 상기 리소스에 대한 접근의 허용여부를 판단하는 과정을 포함하는 것을 특징으로 하는 M2M 통신에서 클라이언트의 접근을 허용하는 방법을 제공한다.
삭제
삭제
삭제
삭제
이상에서 설명한 바와 같이 본 실시예에 의하면, M2M 서비스 제공자 도메인상의 리소스에 접근하고자 하는 개체가 해당 리소스에 접근하기 위한 인증키로서 MAS(M2M Authentication Server)로부터 임시 접근을 위한 액세스 토큰(Access Token)를 발급받아 사용함으로써, 다수의 개체 간의 정보 공유를 할 수 있는 동시에 권한이 없는 개체가 타 개체의 정보에 접근하는 것을 방지하고, 개체 간 리소스 데이터를 공유에 있어서 발생할 수 있는 보안상 위협을 방지할 수 있는 효과가 있다.
도 1은 M2M 서비스 개체들 간의 관계를 개략적으로 나타낸 블록 구성도이다.
도 2는 클라이언트와 리소스 소유자가 서로 다른 M2M 서비스 제공자 도메인에 있는 경우에 있어서 M2M 서비스 개체들 간의 관계를 개략적으로 나타낸 블록 구성도이다.
도 3는 클라이언트와 리소스 소유자가 서로 다른 M2M 서비스 제공자 도메인에 있고, 리소스 소유자가 NA2인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 4은 클라이언트와 리소스 소유자가 서로 다른 M2M 서비스 제공자 도메인에 있고, 리소스 소유자가 D/G2인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 5는 클라이언트가 M2M 서비스에 가입되어 있지 않은 경우에 있어서 M2M 서비스 개체들 간의 관계를 개략적으로 나타낸 블록 구성도이다.
도 6는 클라이언트가 M2M 서비스에 가입되어 있지 않고, 리소스 소유자가 NA인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 7은 클라이언트가 M2M 서비스에 가입되어 있지 않고, 리소스 소유자가 D/G1인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 8는 클라이언트와 리소스 소유자가 동일한 M2M 서비스 제공자 도메인에 속해 있는 경우에 있어서 M2M 서비스 개체들 간의 관계를 개략적으로 나타낸 블록 구성도이다.
도 9는 클라이언트와 리소스 소유자가 동일한 M2M 서비스 제공자 도메인에 속해 있고, 리소스 소유자가 NA인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 10은 클라이언트와 리소스 소유자가 동일한 M2M 서비스 제공자 도메인에 속해 있고, 리소스 소유자가 D/G2인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
이하, 본 실시예에 따른 M2M 통신에서 리소스 접근 권한 설정 방법을 실시하기 위한 구체적인 내용을 설명하면 다음과 같다. 도면에서 본 발명을 명확하게 설명하기 위해서 도면에서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 동일한 부분에 대해서는 동일한 도면 부호를 붙였다.
명세서 전체에서, 어떤 부분이 어떤 구성요소를 '포함'한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다. 이하에서 사용된 '리소스 소유자'는 해당 리소스에 접근하고자 하는 클라이언트에 대해 리소스 접근 권한부여 여부 및 그 접근 범위를 결정할 수 있는 개체로서, M2M 단말, M2M 게이트웨이 또는 M2M 애플리케이션일 수 있다. 또한, '클라이언트'는 타 M2M 단말, M2M 게이트웨이 또는 M2M 애플리케이션이 수집하거나 생성한 수집한 정보를 담고 있는 리소스에 접근하고자 하는 개체로서, M2M 서비스 제공자 도메인 내의 M2M 단말, M2M 게이트웨이 및 M2M 애플리케이션뿐만 아니라 어떠한 M2M 서비스 제공자 도메인에도 속하지 않는 엔드-유저(End-user)나 제3의 애플리케이션일 수 있다. 또한 '리소스'는 M2M 애플리케이션이 수집 또는 생성한 정보를 보유하고 있는 버킷(Bucket)으로서, 범용 리소스 식별자(Universal Resource Identifier: URI)인 리소스_URI(Resource_URI)를 사용하여 접근된다. 또한 'D/G'는 M2M 단말(Device: D) 및 M2M 게이트웨이(Gateway: G)를 의미한다. 한편, 명세서에 기재된 용어 또는 약어는 명세서에서 별도로 규정하지 않는 한 M2M 통신기술분야 및 ETSI(European Telecommunications Standards Institute)등의 M2M 기술 표준에 부합하도록 해석되어야 한다. 예를 들어, 명세서 전체에서 사용된 NSCL은 네트워크 도메인에서 M2M 서비스 능력 계층(M2M Service Capabilities Layer)를 의미한다. 또한 M2M 애플리케이션(M2M Application)은 서비스 로직(Service Logic)을 실행하고, 개방형 인터페이스를 통해 접근가능한 서비스 기능(Service Capabilities)을 사용하는 애플리케이션으로서 NA, GA, DA를 포함한다. 또한 NA는 서비스 로직을 실행하고 개방형 인터페이스를 통해 접근할 수 있는 서비스 기능을 사용하는 네트워크 및 응용 프로그램 도메인에 위치하는 애플리케이션을 말한다. 또한 GA는 서비스 로직을 실행하고 개방형 인터페이스를 통해 접근 가능한 서비스 기능을 사용하는 M2M 게이트웨이에 위치하는 애플리케이션을 말한다. 또한 DA는 서비스 로직을 실행하고 개방형 인터페이스를 통해 접근 가능한 서비스 기능을 사용하는 M2M 단말에 위치하는 애플리케이션을 말한다. 한편, 명세서 전체에서 클라이언트의 검증, 권한부여 코드 및 액세스 토큰 발급 등을 수행하는 서버를 ETSI M2M 표준분야에서 정의된 'MAS(M2M Authentication Sever)'로 기재하고 있으나, 실시예에 따라서는 인증(Authentication), 권한부여(Authorization), 어카운팅(Accounting)을 수행하는 일반적인 서버 또는 인증, 권한부여, 어카운팅 서비스를 제공하는 제3의 M2M 서비스 제공자 도메인의 서버가 될 수 있다.
이제 본 발명에 따른 M2M 통신에서 리소스 접근 권한 설정 방법에 대하여 도면을 참고로 하여 상세하게 설명한다.
도 1은 M2M 서비스 개체들 간의 관계를 개략적으로 나타낸 블록 구성도이다.
도 1은 M2M 통신에서 각각 별개의 서비스를 제공하는 다양한 M2M 서비스 제공자(M2M Service Provider)가 존재하는 경우를 가정하고 있다. 도 1에 도시된 바와 같이, 각 M2M 서비스 제공자 도메인(#1, #2)에는 NA(Network Application; 115, 125), NSCL(Network Service Capabilities Layer; 113, 123), MAS(M2M Authentication Server; 114, 124), GA(Gateway Application)를 포함하는 M2M 게이트웨이(Gateway; 111, 122), DA(Device Application)를 포함하는 M2M 단말(Device; 110, 112, 120, 121) 및 엔드-유저(End-user) 단말(116, 126)이 존재한다. M2M 단말들은 네트워크 도메인에 직접 접속할 수도 있고(112, 121의 경우), 네트워크 도메인의 프록시 역할을 하는 하나 이상의 게이트웨이를 거쳐 네트워크 도메인에 접속할 수도 있다(110, 120의 경우). 또한 어떠한 M2M 서비스 제공자에게도 가입되어 있지 않으면서 인터넷을 통해 외부에서 M2M 서비스 제공자 도메인에 접속하는 엔드-유저 단말(130)이 존재할 수 있다. 또한, 도 1에서는 각 M2M 서비스 제공자 도메인에 별개의 MAS가 존재하는 것으로 표현되어 있으나, 실시예에 따라서는 여러 M2M 서비스 제공자 도메인이 그 기능을 공유하는 MAS가 별도로 존재할 수도 있다.
한편, 리소스는 NSCL(113, 123)뿐만 아니라 단말(110, 112, 120, 121), 게이트웨이(111, 122)의 SCL상에 위치할 수도 있으나, 본 발명의 실시예에서는 D/G의 SCL상에 리소스가 위치하는 경우에 대한 권한부여 설정방법을 다루기로 한다. 리소스 소유자는 단말, 게이트웨이 및 NA가 될 수 있으며, 클라이언트는 단말, 게이트웨이, NA 및 엔드-유저가 될 수 있다.
클라이언트가 M2M 서비스 제공자 도메인 상에 존재하는 보호된 리소스 데이터에 접근하기 위한 권한을 획득하는 방법은, 클라이언트와 리소스 소유자가 속하는 M2M 서비스 제공자 도메인의 동일 여부에 따라 다음과 같이 3가지로 구분될 수 있다. 첫째, 리소스 소유자와 클라이언트가 서로 다른 M2M 서비스 제공자 도메인에 속하는 경우이다. 이러한 경우는 특정 업종에 특화되어 전문화된 서비스를 제공하는 수직적 서비스 도메인간의 융합이 그 예이다. 예를 들어 e_Health 단말 장치와 Home Network 장치 간 또는 Home Energy 장치들 간의 상호 정보 교환을 통해 환자를 위한 최적의 환경을 조성하고자 하는 경우를 들 수 있다. 이러한 경우는 이러한 장치들이 서버를 경유하여 정보를 교환하기보다는 상호 직접 통신하는 방법이 더 효율적인 경우이다. 이를 위해서는 사전에 각 M2M 서비스 도메인에 포함된 장치들 간에 서로의 데이터에 접근할 수 있는 접근권한을 설정해 주는 과정이 필요할 것이다. 둘째, 클라이언트가 M2M 서비스 제공자 도메인의 외부에 있는 경우이다. 예를 들어 사전에 어떠한 M2M 서비스에도 가입되어 있지 않은 휴대폰 단말의 애플리케이션을 이용하여, 이 휴대폰 단말이 기상정보제공서비스와 관련된 기상측정장치와 직접 통신하여 내 회사 주변의 기온과 습도 등 기상정보를 조회하고자 하는 경우나, 휴대폰 단말이 버스의 디지털운행기록계(Digital Tachograph: DTG)와 직접 통신하여 버스의 GPS 데이터를 조회하고자 하는 경우에 해당 데이터를 조회하기 위한 접근권한을 얻는 과정이 필요할 것이다. 셋째, 클라이언트와 리소스 소유자가 모두 동일한 M2M 서비스 제공자 도메인에 속하는 경우이다. 예를 들어 Car_to_Car 통신을 이용하여 차량간 데이터 통신을 수행하는 경우나, 다양한 e_Health 단말장치들 간에 환자의 상태정보 데이터를 교환하는 경우에, 동일한 M2M 서비스에 가입된 장치라 하더라도 허락없이 다른 장치의 데이터에 접근할 수 있게 하는 것은 문제가 될 수 있으므로 접근 권한을 얻는 과정이 필요할 것이다.
이하에서는 도 2 및 도 3을 참조하여 클라이언트와 리소스 소유자가 서로 다른 M2M 서비스 제공자 도메인에 있는 첫번째 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한을 부여하는 방법을 설명하기로 한다.
도 2는 클라이언트와 리소스 소유자가 서로 다른 M2M 서비스 제공자 도메인에 있는 경우에 있어서 M2M 서비스 개체들 간의 관계를 개략적으로 나타낸 블록 구성도이다.
도 2는 M2M 서비스 제공자 #1 도메인에 속하는 D/G1(200), NA1(230) 또는 엔드-유저(240)가 M2M 서비스 제공자 #2 도메인에 속하는 D/G2(260) 상에 위치한 리소스에 접근하고자 하는 경우를 가정하고 있다.
D/G2(260)에 위치한 리소스에 대한 D/G1(200)의 접근을 허용할지 여부 및 접근범위를 결정하는 개체는 해당 리소스가 담고 있는 정보를 생성 또는 수집한 D/G2(280)이거나 해당 M2M 서버상의 NA2(290)일 수 있다. 따라서 클라이언트가 M2M 서비스 제공자 #1 도메인에 속하는 D/G1(200), NA1(230) 또는 엔드-유저(240)이고, 리소스 소유자가 M2M 서비스 제공자 #2 도메인의 NA2(290)인 경우이다.
앞서 언급한 바와 같이, 도 2에서는 각 M2M 서비스 제공자 도메인에 별개의 MAS(210, 270)가 존재하는 것으로 표현되어 있으나, 실시예에 따라서는 인증, 권한부여, 어카운팅 서비스를 제공하는 제3의 M2M 서비스 제공자 도메인의 서버가 MAS(210, 270)의 기능을 대신할 수도 있다.
도 3는 클라이언트와 리소스 소유자가 서로 다른 M2M 서비스 제공자 도메인에 있고, 리소스 소유자가 NA2인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 3의 메커니즘은 클라이언트가 D/G1인 경우에 대하여 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 메커니즘을 설명하고 있으나, 클라이언트가 NA(230), 엔드-유저(240)인 경우에도 동일한 접근 권한 설정 메커니즘이 적용될 수 있음에 유의하여야 한다.
STEP 00은 ETSI M2M 표준에 따른 사전 절차 수행 단계이다. 사전 절차로서 클라이언트는 M2M 서비스 부트스트랩, M2M 서비스 연결, SCL 등록 절차를 완료한다. 또한 D/G1(200)이 D/GSCL과의 관계에서 DA, GA1의 등록 절차를 수행하는 것이 전제될 수도 있다.
STEP 01은 클라이언트 등록 단계(S310)이다. D/G1(200)은 NSCL1(210)에 클라이언트 등록 과정을 수행하여 클라이언트 크리덴셜(Client Credentials)로서 클라이언트_식별자(Client_ID) 및 클라이언트_시크릿(Client_Secret)을 할당받게 된다. NSCL1(210)은 D/G1(200)으로부터 클라이언트 등록 메시지를 수신하면 클라이언트 등록 메시지를 MAS1(210)에 전달한다. 클라이언트 등록 메시지를 전달받은 MAS1(210)은 D/G1(200)에 대한 클라이언트_식별자 및 클라이언트_시크릿을 생성하고 이를 NSCL1(210)을 통해 D/G1(200)에게 할당한다. 클라이언트_식별자 및 클라이언트_시크릿의 생성방식에는 제한이 없으나, 예를 들어, MAS1(210)은 클라이언트의 애플리케이션 식별자(App_ID), 노드 식별자(Node_ID), 서비스 연결 식별자(Service Connection_ID), SCL 식별자(SCL_ID) 등과 같은 ETSI M2M 표준에서 규정하고 있는 식별자(Identifier: ID)들 중 어느 하나를 클라이언트_식별자로 할당하거나, 이들 식별자에 애플리케이션 키(Application Key), 루트 키(Root Key), 연결 키(Connection Key)와 같은 하나 이상의 키들을 결합하여 생성된 값을 클라이언트_식별자로 할당할 수도 있을 것이다. 또한 클라이언트_시크릿은 이들 식별자와 키 중 적어도 하나 이상을 이용하여 다양한 방식으로 생성될 수 있을 것이다.
STEP 02는 서비스/리소스 검색 단계(S320)이다. 클라이언트가 권한부여 절차를 시작하기 위해서는 클라이언트가 필요로 하는 서비스를 제공하거나 리소스 정보를 가진 리소스 소유자를 찾는 절차가 필요하다. 위 서비스/리소스 검색 단계를 통하여 클라이언트는 리소스 소유자에 대한 정보(ID 또는 URI)와 리소스가 위치한 리소스 서버(D/GSCL)의 위치를 알게 된다. 이를 위해 리소스가 위치한 NSCL2(220)를 통해 리소스 소유자의 위치(ID 또는 URI)와 리소스가 위치한 리소스 서버(D/GSCL)의 위치 등에 관한 정보를 획득하는 방법을 고려할 수 있다. 예를 들어 서비스/리소스 검색 단계(S320)는 D/G1(200)이 NSCL(220)에 원하는 정보의 종류 등에 관한 검색 필터 기준(Discovery Filter Crieria) 등이 포함된 검색 메시지를 보내는 과정, NSCL1(220)이 검색 리소스(Discovery Resource)를 가지고 있는 NSCL2(260)에 검색 메시지를 전달하는 과정, NSCL2(220)는 검색 리소스를 이용하여 D/G1(200)이 제시한 검색 필터 기준과 매칭되는 리소스_URI 리스트를 검색하고 그 결과를 D/G1(200)에 전송하는 과정을 포함할 수 있다. 또한 서비스/리소스 검색 단계(S320)에서는 리소스 소유자인 D/G2(280), NA2(290)가 클라이언트인 D/G1(200)에게 자신의 URI, 리소스_URI 중 적어도 하나 이상을 알려주는 방법도 고려할 수 있을 것이다. 한편 클라이언트가 리소스 소유자 또는 리소스_URI를 이미 알고 있는 경우나 리소스 소유자 및 리소스의 위치가 사전에 설정되어 있는 경우에는 위 서비스/리소스 검색 단계는 생략될 수 있다. 즉, 클라이언트는 권한부여 요청 단계(S330) 이전에 리소스_URI 정보를 얻을 수 있는데, 이는 서비스/리소스 검색 단계(S320)에서 얻을 수도 있고, 서비스 제공자의 설정 내지 정책이나 다른 절차 등에 의해 사전에 리소스 소유자로부터 전달받을 수 있다.
STEP 03은 권한부여 요청 단계(S330)이다. 권한부여 요청 단계(S330)에서 클라이언트는 리소스 소유자에게 권한부여 요청(Authorization Request)을 수행한다. D/G1(200)은 권한부여 요청 메시지를 NSCL1(220)을 거쳐 NSCL2(260)에 전송한다. 한편, 권한부여 요청 메시지에는 authorization_type, resource_uri, client_id, client_secret, access_scope, callback_uri, state 등의 파라미터 중 하나 이상의 파라미터가 사용될 수 있다. 여기서 authorization_type은 권한부여 타입을 의미하고, client_id 및 client_secret은 클라이언트 크리덴셜을 의미하고, resource_uri는 리소스의 위치 정보를 의미하고, state는 권한부여 단계에서 클라이언트나 권한부여 서버 등이 서로 주고 받는 임의의 값을 의미한다. 또한 access_scope는 요청하는 접근 범위 즉, Creat/Retrieve/Update/Delete 중 요청하는 권한 범위 또는 접근 권한이 필요한 정보는 어떠한 것이 있는지에 관한 파라미터이다. NSCL2(260)는 리소스_URI에 대응하는 리소스 소유자가 누구인지를 SCL 또는 애플리케이션 리소스 레벨에서 검색한다. 검색된 리소스 소유자인 NA2(290)에게 NSCL2(260)는 권한부여 요청 메시지를 전달한다.
STEP 04는 클라이언트 검증(Verification) 단계(S340)이다. 리소스 소유자는 권한부여 요청 메시지에 대하여 해당 클라이언트에 대한 검증을 수행한다. 클라이언트를 검증하는 방법에는 MAS1(210)에 클라이언트의 검증을 요청하는 방법, 리소스 소유자에 연결된 엔드-유저가 검증을 해주는 방법, M2M 서비스 제공자(NSCL2/NA2, 260/290)에 검증을 요청하고 서비스 제공자의 접근권한 부여 정책에 따라 검증하는 방법이 있을 수 있다. 예시적으로, MAS1(210)에 클라이언트의 검증을 요청하는 방법은 NA2(290)가 D/G1(200)이 등록된 MAS1(210)에 클라이언트의 검증을 요청하는 과정, MAS1(210)이 클라이언트 크리덴셜을 기초로 D/G1(200)이 정상적으로 MAS1(210)에 등록된 장치인지 여부 등을 판단하는 검증 수행 과정 및 검증 수행 결과를 바탕으로 리소스 소유자에게 클라이언트 검증 응답 메시지를 전달하는 과정을 포함할 수 있다. 한편, 검증 요청 메시지에는 클라이언트 크리덴셜(클라이언트_식별자, 클라이언트_시크릿) 등의 파라미터가 포함될 수 있으며, 클라이언트 검증 응답 메시지에는 클라이언트 크리덴셜, 인증서(Certificates) 등이 포함될 수 있다.
STEP 05는 권한부여 승인 단계(S350)이다. 클라이언트 인증이 정상적으로 완료되면 NA2(290)는 D/G1(200)이 해당 리소스에 접근할 수 있도록 접근 권한을 설정하도록 NSCL2(260)을 거쳐 D/G2(280)에 요청한다. 접근 권한 설정을 요청하는 메시지에는 client_id, client_secret, access_scope, resource_location 등의 파라미터 중 적어도 하나 이상의 파라미터가 포함될 수 있다. 여기서 client_id 및 client_secret는 클라이언트 크리덴셜에 관한 파라미터이고, access_scope는 리소스 소유자가 허용하고자 하는 접근 범위에 관한 파라미터이다. resource_location은 리소스가 저장되어 있는 위치에 관한 파라미터로서, 예를 들어 리소스_URI 정보를 제공할 수 있다. D/G2(280)는 NA2(290)의 요청에 따라 해당 리소스에 대한 접근권한 리소스(accessRight resource)를 생성하거나 이미 접근권한 리소스가 존재할 경우에는 그 속성을 갱신(Update)한다. 여기서, 접근권한 리소스는 보호된 리소스에 대한 접근 권한에 대한 정보, 즉 보호된 리소스에 어떠한 개체가 무엇을 할 수 있는지에 관한 정보를 저장하고 있는 리소스이다. NA2(290)는 D/G1(200)에 대한 권한부여가 승인되었음을 알리는 권한부여 승인 메시지를 NSCL2(260)를 거쳐 MAS2(270)에 전송한다. 권한부여 승인 메시지에는 클라이언트_식별자를 비롯하여 리소스의 저장위치에 관한 정보, 예를 들어 NSCL에 저장되어 있는지 혹은 D/G2에게 저장되어 있는지 등의 정보가 포함될 수 있다.
STEP 06은 선택적 절차로서, 권한부여 코드 발급 및 액세스 토큰 요청 단계(S360)이다. MAS2(270)는 D/G1(200)의 권한부여 요청이 승인되었다는 증거로, 권한부여 코드(Authorization Code)를 생성하여 NSCL1 및 NSCL2를 거쳐 D/G1(200)에게 발급한다. D/G1(200)은 발급받은 권한부여 코드를 사용하여, 리소스 정보를 조회하기 위해 요구되는 액세스 토큰(Access Token)의 발급을 NSCL1 및 NSCL2를 거쳐 MAS2(270)에 요청한다. 한편, 액세스 토큰 발급 요청 메시지에는 authorization_type, code, callback_uri, client_id, client_secret 등의 파라미터 중 하나 이상의 파라미터가 사용될 수 있다. 여기서, authorization_type은 권한부여 타입을, code는 권한부여 코드를, callback_uri는 권한부여를 요청한 클라이언트 자신의 ID 또는 URI를, client_id 및 client_secret는 클라이언트 크리덴셜 정보를 나타내는 파라미터이다.
STEP 07은 액세스 토큰 발급 단계(S370)이다. MAS2(270)는 D/G1(200)의 권한부여 코드를 체크하고, 확인이 되면 액세스 토큰을 생성하여 리소스가 위치한 D/G2(280)에 전달하고, 허용된 접근범위와 함께 액세스 토큰을 D/G1(200)에게 발급한다. 또한 MAS2(270)는 생성된 액세스 토큰을 NSCL2(260)에게도 전송할 수 있는데, NSCL2(260)는 D/G1(200)이 D/G2(280)에 위치한 리소스에 접근할 때에 요청 메시지를 전달해 줄 클라이언트인지 확인하기 위해 전달받은 액세스 토큰을 사용할 수 있다. 실시예에 따라서 NSCL(260)이 MAS2(270)을 대신하여 자신이 전송받은 액세스 토큰을 허용된 접근범위와 함께 MAS2(270)을 대신하여 D/G1(200)에게 전송할 수 있다. SETP 06이 생략될 경우 MAS2(270)는 권한부여 코드를 체크하지 않고, STEP 05에서 리소스 소유자로부터 권한부여 승인 메시지를 수신한 후 액세스 토큰을 생성한다. D/G2(280)는 수신한 액세스 토큰과 접근권한 리소스를 매핑하여 관리한다. MAS2(270)는 액세스 토큰의 갱신을 위하여 액세스 토큰과 함께 갱신 토큰(Refresh Token)을 발급할 수 있다. 한편, 발급되는 액세스 토큰이 포함된 메시지에는 token_type, expiration_time, access_scope, state, client_id, client_secret, resource_location 등의 파라미터 중 하나 이상의 파라미터가 사용될 수 있다. token_type는 토큰 값을 어떤 방법에 의해 생성했는지를 나타내는 파라미터로서, 가령 어떤 암호화 방식에 의해 토큰 값을 생성했는지 등의 정보를 담고 있다. expiration_time은 access_token의 만료시간에 관한 파라미터이고, access_scope는 리소스 소유자가 가진 전체 리소스에 대한 Create/Retrieve/Update /Delete 중 허용된 접근권한 범위 또는 접근할 수 있는 개별 리소스의 범위에 관한 파라미터이다. state는 클라이언트와 권한부여 서버 간에 메시지 교환시 사용되는 임의의 값에 관한 파라미터이고, client_id 및 client_secret은 클라이언트 크리덴셜 정보를 나타내는 파라미터이다. resource_location은 리소스가 NSCL에 저장되어 있는지 또는 DA 등의 리소스 소유자에 저장되어 있는지에 관한 정보를 담고 있는 파라미터이다.
STEP 08은 보호된 리소스에 접근하는 단계(S380)이다. D/G1(200)는 액세스 토큰을 기초로 D/G2(280)에 위치한 리소스에 접근하여 정보를 조회한다. D/G2(280)는 D/G1(200)로부터 전송받은 액세스 토큰과 자신이 MAS2(270)로부터 수신한 액세스 토큰이 일치하는지 여부를 체크하고, 접근권한 리소스를 확인하여 해당 액세스 토큰과 매칭되는 접근 권한 범위안에서 해당 리소스에 대한 D/G1(200)의 접근을 허용한다.
도 4은 클라이언트와 리소스 소유자가 서로 다른 M2M 서비스 제공자 도메인에 있고, 리소스 소유자가 D/G2인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 4 메커니즘은 클라이언트가 D/G1인 경우에 대하여 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 메커니즘을 설명하고 있으나, 클라이언트가 NA(230), 엔드-유저(240)인 경우에도 동일한 접근 권한 설정 메커니즘이 적용될 수 있음에 유의하여야 한다.
STEP 01(S410), STEP 02(S420), STEP 06(S460), STEP 07(S470), STEP 08(S480)에서는 각각 도 3의 해당 STEP과 동일한 과정이 수행되므로 설명은 생략하고, 이하에서는 STEP 03, STEP 04, STEP 05에 대해서 설명하기로 한다.
STEP 03은 권한부여 요청 단계(S430)이다. 권한부여 요청 단계(S430)에서 클라이언트는 리소스 소유자에게 권한부여 요청(Authorization Request)을 수행한다. D/G1(200)은 권한부여 요청 메시지를 NSCL1(220)을 거쳐 NSCL2(260)에 전송한다. NSCL2(260)는 리소스_URI에 대응하는 리소스 소유자가 누구인지를 SCL 또는 애플리케이션 리소스 레벨에서 검색한다. 검색된 리소스 소유자인 D/G2(280)에게 NSCL2(260)는 권한부여 요청 메시지를 전달한다. 한편, 권한부여 요청 메시지에 포함될 수 있는 파라미터는 도 3의 STEP 03과 동일하므로 설명을 생략한다.
STEP 04는 클라이언트 검증(Verification) 단계(S440)이다. 리소스 소유자는 권한부여 요청 메시지에 대하여 해당 클라이언트에 대한 검증을 수행한다. 클라이언트를 검증하는 방법에는 MAS1(210)에 클라이언트의 검증을 요청하는 방법, 리소스 소유자에 연결된 엔드-유저가 검증을 해주는 방법, M2M 서비스 제공자(NSCL2/NA2, 260/290)에 검증을 요청하고 서비스 제공자의 접근권한 부여 정책에 따라 검증하는 방법이 있을 수 있다. 예시적으로, MAS1(210)에 클라이언트의 검증을 요청하는 방법은 D/G2(280)가 NSCL2(260) 및 NSCL1(220)을 거쳐 D/G1(200)이 등록된 MAS1(210)에 클라이언트의 검증을 요청하는 과정, MAS1(210)이 클라이언트 크리덴셜을 기초로 D/G1(200)이 정상적으로 MAS1(210)에 등록된 장치인지 여부 등을 판단하는 검증 수행 과정 및 검증 수행 결과를 바탕으로 MAS1(210)이 NSCL1(220) 및 NSCL2(260)을 거쳐 D/G2(280)에게 클라이언트 검증 응답 메시지를 전달하는 과정을 포함할 수 있다. 한편, 검증 요청 메시지에는 클라이언트 크리덴셜(클라이언트_식별자, 클라이언트_시크릿) 등의 파라미터가 포함될 수 있으며, 클라이언트 검증 응답 메시지에는 클라이언트 크리덴셜, 인증서(Certificates) 등이 포함될 수 있다.
STEP 05는 권한부여 승인 단계(S450)이다. 클라이언트 인증이 정상적으로 완료되면 D/G2(280)는 D/G1(200)이 해당 리소스에 접근할 수 있도록 해당 리소스에 대한 접근권한 리소스(accessRight resource)를 생성하거나 이미 접근권한 리소스가 존재할 경우에는 그 속성을 갱신(Update)한다. 여기서, 접근권한 리소스는 보호된 리소스에 대한 접근 권한에 대한 정보, 즉 보호된 리소스에 어떠한 개체가 무엇을 할 수 있는지에 관한 정보를 저장하고 있는 리소스이다. D/G2(280)는 D/G1(200)에 대한 접근 권한부여가 승인되었음을 알리는 권한부여 승인 메시지를 NSCL2(260)를 거쳐 MAS2(270)에 전송한다. 권한부여 승인 메시지에는 클라이언트_식별자를 비롯하여 리소스의 저장위치에 관한 정보, 예를 들어 NSCL에 저장되어 있는지 혹은 DA 등의 리소스 소유자에게 저장되어 있는지 등의 정보가 포함될 수 있다.
이하에서는 도 5 내지 도 7을 참조하여 클라이언트가 M2M 서비스에 가입되어 있지 않은 경우에 M2M 서비스 제공자 도메인 상의 리소스에 대한 접근 권한을 설정하는 방법을 설명하기로 한다.
도 5는 클라이언트가 M2M 서비스에 가입되어 있지 않은 경우에 있어서 M2M 서비스 개체들 간의 관계를 개략적으로 나타낸 블록 구성도이다.
도 5에 도시된 바와 같이 어떠한 M2M 서비스 제공자 도메인에도 속하지 않은 엔드-유저(510) 또는 제3 애플리케이션(Third-party Applicaion, 515)이 M2M 서비스 제공자 도메인의 D/G(530)의 SCL상에 위치한 리소스에 접근하고자 하는 경우를 가정하자.
이 경우 엔드-유저(510) 및 제3 애플리케이션이 클라이언트가 되며, 엔드 유저(510) 또는 제3 애플리케이션(515)이 NA(520)에 등록 또는 가입한 뒤 M2M 서비스 중에 필요한 리소스에 대해서만 선별적으로 접근 권한을 얻도록 구성될 필요가 있다.
도 6, 도 7 및 이하의 설명에서 클라이언트가 엔드-유저(510) 애플리케이션인 경우에 대하여 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 메커니즘을 설명하고 있으나, 제3 애플리케이션인 경우에도 동일한 리소스 접근 권한 설정 메커니즘이 적용될 수 있음을 유의해야 한다.
도 6는 클라이언트가 M2M 서비스에 가입되어 있지 않고, 리소스 소유자가 NA인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 6에서 각 개체들간의 관계를 살펴보면, 엔드-유저 애플리케이션(End-user Application: 이하 EUA라고 한다)(510)이 M2M 서비스 제공자 도메인에 가입하지 않은 독립적인 관계에 있으며, EUA(510)가 클라이언트, NA(520)가 리소스 소유자에 해당한다. 여기서 D/G(550)는 리소스 접근 권한 설정 과정에 특별히 관여하지 않는다.
STEP 00은 ETSI M2M 표준에 따른 사전 절차 수행 단계이다. 사전 절차로서 클라이언트는 M2M 서비스 부트스트랩, M2M 서비스 연결, SCL 등록 절차를 완료한다.
STEP 01은 클라이언트 등록 단계(S610)이다. EUA(510)는 NA(520)를 통해 클라이언트 등록 과정을 수행하여 클라이언트 크리덴셜(Client Credentials)로서 클라이언트_식별자(Client_ID) 및 클라이언트_시크릿(Client_Secret)을 할당받게 된다. 즉, M2M 서비스 제공자 도메인 밖의 엔드-유저 애플리케이션이 NSCL(530)이 아닌 NA(520)를 접촉점(Contact Point)로 하여 클라이언트 등록 절차를 수행한다는 점에서 도 3의 STEP 01과 구별된다. NA(520)는 EUA(510)으로부터 클라이언트 등록 메시지를 수신하면 클라이언트 등록 메시지를 MAS(540)에 전달한다. 클라이언트 등록 메시지를 전달받은 MAS(540)는 EUA(510)에 대한 클라이언트_식별자 및 클라이언트_시크릿을 생성하고 이를 NA(520)을 통해 EUA(510)에게 할당한다. 한편, 클라이언트_식별자 및 클라이언트_시크릿의 생성방법은 도 3의 STEP 01과 동일하므로 설명을 생략한다.
STEP 02는 서비스/리소스 검색 단계(S620)이다. 클라이언트가 권한부여 절차를 시작하기 위해서는 클라이언트가 필요로 하는 서비스를 제공하거나 리소스 정보를 가진 리소스 소유자를 찾는 절차가 필요하다. 위 서비스/리소스 검색 단계를 통하여 클라이언트는 리소스 소유자에 대한 정보(ID 또는 URI)와 리소스가 위치한 리소스 서버의 위치를 알게 된다. 이를 위한 수단으로, 리소스가 위치한 NSCL(530)을 통해 리소스 소유자의 위치(ID 또는 URI)와 리소스가 위치한 리소스 서버의 위치 등에 관한 정보를 획득하는 방법을 고려할 수 있다. 예를 들어 서비스/리소스 검색 단계(S520)는 EUA(510)가 NA(520)에 원하는 정보의 종류 등에 관한 검색 필터 기준(Discovery Filter Crieria) 등이 포함된 검색 메시지를 보내는 과정, NA(520)가 검색 리소스(Discovery Resource)를 가지고 있는 NSCL(530)에 검색 메시지를 전달하는 과정, NSCL(530)이 검색 리소스를 이용하여 EUA(510)가 제시한 검색 필터 기준과 매칭되는 리소스_URI 리스트를 검색하고 그 결과를 EUA(510)에 전송하는 과정을 포함할 수 있다. 또한 서비스/리소스 검색 단계(S520)에서는 리소스에 저장된 정보를 수집 또는 생성한 D/G(550) 또는 리소스 소유자인 NA(520)가 클라이언트인 EUA(510)에게 자신의 URI, 리소스_URI 중 적어도 하나 이상을 알려주는 방법도 고려할 수 있을 것이다. 한편 클라이언트가 리소스 소유자 또는 리소스_URI를 이미 알고 있는 경우나 리소스 소유자 및 리소스의 위치가 사전에 설정되어 있는 경우에는 위 서비스/리소스 검색 단계(S620)는 생략될 수 있다. 즉, 클라이언트는 권한부여 요청 단계(S630) 이전에 리소스_URI 정보를 얻을 수 있는데, 이는 서비스/리소스 검색 단계(S620)에서 얻을 수도 있고, 서비스 제공자의 설정 내지 정책이나 다른 절차 등에 의해 사전에 리소스 소유자로부터 전달받을 수 있다.
STEP 03은 권한부여 요청 단계(S630)이다. EUA(510)는 NSCL(530)에게 권한부여 요청을 수행한다. NSCL(530)은 리소스_URI에 대응되는 리소스 소유자가 누구인지를 SCL 또는 애플리케이션 리소스 레벨에서 검색한다. 검색된 리소스 소유자인 NA(520)에게 NSCL(530)은 권한부여 요청 메시지를 전달한다. 한편, 권한부여 요청 메시지의 파라미터는 도 3의 STEP 03에서 사용되는 파라미터와 동일하므로 설명을 생략한다.
STEP 04는 클라이언트 검증(Verification) 단계(S640)이다. 리소스 소유자인 NA(520)는 권한부여 요청 메시지에 대하여 해당 클라이언트에 대한 검증을 수행한다. 클라이언트를 검증하는 방법에는 MAS(540)에 클라이언트의 검증을 요청하는 방법, M2M 서비스 제공자(NSCL)에 검증을 요청하고 서비스 제공자의 접근권한 부여 정책에 따라 검증하는 방법이 있을 수 있다. 예시적으로, MAS(540)에 EUA(510)의 검증을 요청하는 방법은 리소스 소유자인 NA(520)가 NSCL(430)을 거쳐 MAS(540)에 클라이언트의 검증을 요청하는 과정, MAS(540)이 클라이언트 크리덴셜을 기초로 EUA(510)가 정상적으로 MAS(540)에 등록된 장치인지 여부 등을 판단하는 검증 수행 과정 및 검증 수행 결과를 바탕으로 NSCL(530)을 거쳐 NA(520)에게 클라이언트 검증 응답 메시지를 전달하는 과정을 포함할 수 있다. 한편, 검증 요청 메시지에는 클라이언트 크리덴셜(Client_ID 및 Client_Secret) 등의 파라미터가 포함될 수 있으며, 클라이언트 검증 응답 메시지에는 클라이언트 크리덴셜 및 인증서(Certificates) 등이 포함될 수 있다.
STEP 05는 권한부여 승인 단계(S650)이다. 클라이언트 인증이 정상적으로 완료되면 NA(520)는 EUA(510)가 해당 리소스에 접근할 수 있도록 NSCL(530)에 접근 권한을 설정하도록 요청한다. D/G(550)은 NA(520)의 요청에 따라 해당 리소스에 대한 접근권한 리소스(accessRight resource)를 생성하거나 이미 접근권한 리소스가 존재할 경우에는 그 속성을 갱신(Update)한다. 여기서, 접근권한 리소스는 보호된 리소스에 대한 접근 권한에 대한 정보, 즉 보호된 리소스에 어떠한 개체가 무엇을 할 수 있는지에 관한 정보를 저장하고 있는 리소스이다. NA(520)는 EUA(510)에 대한 접근 권한부여가 승인되었음을 알리는 권한부여 승인 메시지를 NSCL(530)를 거쳐 MAS(540)에 전송한다. 한편, 접근 권한 설정을 요청하는 메시지 및 권한부여 승인 메시지에 포함될 수 있는 파라미터는 도 3의 STEP 05와 동일하므로 설명은 생략한다.
STEP 06은 선택적 절차로서, 권한부여 코드 발급 및 액세스 토큰 요청 단계(S660)이다. MAS(540)는 EUA(510)의 권한부여 요청이 승인되었다는 증거로, 권한부여 코드(Authorization Code)를 생성하여 EUA(510)에게 발급한다. EUA(510)는 발급받은 권한부여 코드를 사용하여, 리소스 정보를 조회하기 위해 요구되는 액세스 토큰(Access Token)의 발급을 MAS(540)에 요청한다. 한편, 액세스 토큰 발급 요청 메시지에 포함될 수 있는 파라미터는 도 3의 STEP 06과 동일하므로 설명은 생략한다.
STEP 07은 액세스 토큰 발급 단계(S670)이다. MAS(540)는 EUA(510)의 권한부여 코드를 체크하고, 확인이 되면 액세스 토큰을 생성하여 리소스가 위치한 D/G(550)에 전달하고, 허용된 접근범위와 함께 액세스 토큰을 EUA(510)에게 발급한다. SETP 06이 생략될 경우 MAS(540)는 권한부여 코드를 체크하지 않고, STEP 05에서 리소스 소유자로부터 권한부여 승인 메시지를 수신한 후 액세스 토큰을 생성한다. D/G(550)는 수신한 액세스 토큰과 접근권한 리소스를 매핑하여 관리한다. MAS(540)는 액세스 토큰의 갱신을 위하여 액세스 토큰과 함께 갱신 토큰(Refresh Token)을 발급할 수 있다. 한편, 발급되는 액세스 토큰이 포함된 메시지에 포함될 수 있는 파라미터는 도 3의 STEP 07과 동일하므로 설명을 생략한다.
STEP 08은 보호된 리소스에 접근하는 단계(S680)이다. EUA(510)는 액세스 토큰을 기초로 NSCL(530)에 위치한 리소스에 접근하여 정보를 조회한다. NSCL(530)는 EUA(510)로부터 전송받은 액세스 토큰과 자신이 MAS(540)로부터 발급받은 액세스 토큰이 일치하는지 여부를 체크하고, 접근권한 리소스를 확인하여 해당 액세스 토큰과 매칭되는 접근 권한 범위안에서 해당 리소스에 대한 EUA(510)의 접근을 허용한다.
도 7은 클라이언트가 M2M 서비스에 가입되어 있지 않고, 리소스 소유자가 D/G인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 7에서 각 개체들 간의 관계를 살펴보면, 엔드-유저 애플리케이션(EUA, 510)이 M2M 서비스 제공자 도메인과 독립적인 관계에 있으며, EUA(510)가 클라이언트, D/G(550)가 리소스 소유자에 해당한다.
STEP 01(S710), STEP 02(S720), STEP 06(S760), STEP 07(S770), STEP 08(S780)에서는 각각 도 6의 해당 STEP과 동일한 과정이 수행되므로 설명은 생략하고, 이하에서는 STEP 03, STEP 04, STEP 05에 대해서 설명하기로 한다.
STEP 03은 권한부여 요청 단계(S730)이다. EUA(510)는 NSCL(530)에게 권한부여 요청을 수행한다. NSCL(530)은 리소스_URI에 대응되는 리소스 소유자가 누구인지를 SCL 또는 애플리케이션 리소스 레벨에서 검색한다. 검색된 리소스 소유자인 D/G(550)에게 NSCL(530)은 권한부여 요청 메시지를 전달한다. 한편, 권한부여 요청 메시지의 파라미터는 도 3의 STEP 03에서 사용되는 파라미터와 동일하므로 설명을 생략한다.
STEP 04는 클라이언트 검증(Verification) 단계(S740)이다. D/G(520)는 NSCL(430)으로부터 전달된 권한부여 요청 메시지에 대하여 해당 클라이언트에 대한 검증을 수행한다. 클라이언트를 검증하는 방법에는 MAS(540)에 클라이언트의 검증을 요청하는 방법, M2M 서비스 제공자(NSCL)에 검증을 요청하고 서비스 제공자의 접근권한 부여 정책에 따라 검증하는 방법이 있을 수 있다. 예시적으로, MAS(540)에 EUA(510)의 검증을 요청하는 방법은 D/G(550)가 NSCL(530)을 거쳐 EUA(510)가 등록된 MAS(540)에 클라이언트의 검증을 요청하는 과정, MAS(540)가 클라이언트 크리덴셜을 기초로 EUA(510)가 정상적으로 MAS(540)에 등록된 장치인지 여부 등을 판단하는 검증 수행 과정 및 검증 수행 결과를 바탕으로 MAS(540)가 NSCL(530)을 거쳐 D/G(550)에게 클라이언트 검증 응답 메시지를 전달하는 과정을 포함할 수 있다. 한편, 검증 요청 메시지에는 클라이언트 크리덴셜(Client_ID 및 Client_Secret) 등의 파라미터가 포함될 수 있으며, 클라이언트 검증 응답 메시지에는 클라이언트 크리덴셜 및 인증서(Certificates) 등이 포함될 수 있다.
STEP 05는 권한부여 승인 단계(S750)이다. 클라이언트 인증이 정상적으로 완료되면 D/G(550)는 EUA(510)가 해당 리소스에 접근할 수 있도록 해당 리소스에 대한 접근권한 리소스(accessRight resource)를 생성하거나 이미 접근권한 리소스가 존재할 경우에는 그 속성을 갱신(Update)한다. 여기서, 접근권한 리소스는 보호된 리소스에 대한 접근 권한에 대한 정보, 즉 보호된 리소스에 어떠한 개체가 무엇을 할 수 있는지에 관한 정보를 저장하고 있는 리소스이다. D/G(550)는 EUA(510)에 대한 접근 권한부여가 승인되었음을 알리는 권한부여 승인 메시지를 NSCL(530)를 거쳐 MAS(540)에 전송한다. 한편, 접근 권한 설정을 요청하는 메시지 및 권한부여 승인 메시지에 포함될 수 있는 파라미터는 도 3의 STEP 05와 동일하므로 설명은 생략한다.
이하에서는 도 8 내지 도 10을 참조하여 클라이언트와 리소스 소유자가 동일한 M2M 서비스 제공자 도메인에 속해 있는 경우에 있어서 리소스 접근 권한부여를 설정하는 방법을 설명하기로 한다.
도 8는 클라이언트와 리소스 소유자가 동일한 M2M 서비스 제공자 도메인에 속해 있는 경우에 있어서 M2M 서비스 개체들 간의 관계를 개략적으로 나타낸 블록 구성도이다.
도 8은 어느 하나의 M2M 서비스 제공자 도메인 내에서 동일한 M2M 서비스 제공자 도메인에 가입된 엔드-유저(800)나 어느 한 D/G(810)이 다른 D/G(850)가 생성 또는 수집한 정보를 저장하는 리소스에 접근하고자 하는 경우를 가정하고 있다.
동일한 M2M 서비스 제공자에 가입된 엔드-유저들 사이에서도 엔드-유저마다 가입한 M2M 서비스 제공자 도메인에 속하는 어느 D/G가 생성 또는 수집한 정보를 저장하는 리소스에 접근할 수 있는 권한에 차이를 둘 필요가 있다. 또한 어느 한 D/G가 동일한 M2M 서비스 제공자 도메인 내의 다른 D/G가 생성 또는 수집한 정보를 저장하는 리소스에 접근하고자 하는 경우에도 별도로 접근 권한을 허가받아야 할 필요가 있다.
도 9는 클라이언트와 리소스 소유자가 동일한 M2M 서비스 제공자 도메인에 속해 있고, 리소스 소유자가 NA인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 9에서 각 개체들 간의 관계를 살펴보면, D/G1(810) 및 D/G2(850)가 동일한 M2M 서비스 제공자 도메인 내에 있으며, D/G1(810)이 클라이언트이고, NA(840)가 리소스 소유자에 해당한다. 클라이언트가 접근하고자 하는 리소스는 D/G2(750)의 SCL상에 위치한다.
도 9 및 이하의 설명에서 클라이언트로 D/G1(810)을 표시하였으나, 클라이언트가 엔드-유저(800)인 경우에도 동일한 접근 권한 설정 메커니즘이 적용될 수 있음을 유의해야 한다.
도 9의 절차는 클라이언트, 리소스 소유자가 동일한 M2M 서비스 제공자 도메인에 있다는 점을 제외하고는 도 3의 절차와 유사하다.
STEP 00은 ETSI M2M 표준에 따른 사전 절차 수행 단계이다. 사전 절차로서 클라이언트는 M2M 서비스 부트스트랩, M2M 서비스 연결, SCL 등록 절차를 완료한다. 또한 D/G1(200)이 D/GSCL과의 관계에서 DA, GA1의 등록 절차를 수행하는 것이 전제될 수도 있다.
STEP 01은 클라이언트 등록 단계(S910)이다. D/G1(810)은 NSCL(820)에 클라이언트 등록 과정을 수행하여 클라이언트 크리덴셜(Client Credentials)로서 클라이언트_식별자(Client_ID) 및 클라이언트_시크릿(Client_Secret)을 할당받게 된다. NSCL(820)은 D/G1(810)으로부터 클라이언트 등록 메시지를 수신하면 클라이언트 등록 메시지를 MAS(830)에 전달한다. 클라이언트 등록 메시지를 전달받은 MAS(830)은 D/G1(810)에 대한 클라이언트_식별자 및 클라이언트_시크릿을 생성하고 이를 NSCL(820)을 통해 D/G1(810)에게 할당한다. 한편, 클라이언트_식별자 및 클라이언트_시크릿의 생성방법은 도 3의 STEP 01과 동일하므로 설명을 생략한다.
STEP 02는 서비스/리소스 검색 단계(S920)이다. 클라이언트가 권한부여 절차를 시작하기 위해서는 클라이언트가 필요로 하는 서비스를 제공하거나 리소스 정보를 가진 리소스 소유자를 찾는 절차가 필요하다. 위 서비스/리소스 검색 단계를 통하여 클라이언트는 리소스 소유자에 대한 정보(ID 또는 URI)와 리소스가 위치한 리소스 서버(D/GSCL)의 위치를 알게 된다. 이를 위한 수단으로, 리소스가 위치한 NSCL(820)를 통해 리소스 소유자의 위치(ID 또는 URI)와 리소스가 위치한 리소스 서버(D/GSCL)의 위치 등에 관한 정보를 획득하는 방법을 고려할 수 있다. 예를 들어 서비스/리소스 검색 단계(S920)는 D/G1(810)이 NSCL(820)에 원하는 정보의 종류 등에 관한 검색 필터 기준(Discovery Filter Crieria) 등이 포함된 검색 메시지를 보내는 과정, NSCL(820)이 검색 리소스를 이용하여 D/G1(810)이 제시한 검색 필터 기준과 매칭되는 리소스_URI 리스트를 검색하고 그 결과를 D/G1(810)에 전송하는 과정을 포함할 수 있다. 또한 서비스/리소스 검색 단계(S920)에서는 리소스 소유자인 NA(840)가 클라이언트인 D/G1(810)에게 자신의 URI, 리소스_URI 중 적어도 하나 이상을 알려주는 방법도 고려할 수 있을 것이다. 한편 클라이언트가 리소스 소유자 또는 리소스_URI를 이미 알고 있는 경우나 리소스 소유자 및 리소스의 위치가 사전에 설정되어 있는 경우에는 위 서비스/리소스 검색 단계는 생략될 수 있다. 즉, 클라이언트는 권한부여 요청 단계(S930) 이전에 리소스_URI 정보를 얻을 수 있는데, 이는 서비스/리소스 검색 단계(S920)에서 얻을 수도 있고, 서비스 제공자의 설정 내지 정책이나 다른 절차 등에 의해 사전에 리소스 소유자로부터 전달받을 수 있다.
STEP 03은 권한부여 요청 단계(S930)이다. 권한부여 요청 단계(S930)에서 클라이언트는 리소스 소유자에게 권한부여 요청(Authorization Request)을 수행한다. D/G1(810)은 권한부여 요청 메시지를 NSCL(820)에 전송한다. NSCL(820)은 리소스_URI에 대응하는 리소스 소유자가 누구인지를 SCL 또는 애플리케이션 리소스 레벨에서 검색한다. 검색된 리소스 소유자인 NA(840)에게 NSCL(820)은 권한부여 요청 메시지를 전달한다. 한편, 권한부여 요청 메시지에 포함될 수 있는 파라미터는 도 3의 STEP 03과 동일하므로 설명을 생략한다.
STEP 04는 클라이언트 검증(Verification) 단계(S940)이다. 리소스 소유자는 권한부여 요청 메시지에 대하여 요청한 클라이언트에 대해 검증을 수행한다. 클라이언트를 검증하는 방법에는 MAS(830)에 클라이언트의 검증을 요청하는 방법, 리소스 소유자에 연결된 엔드-유저가 검증을 해주는 방법, M2M 서비스 제공자(NSCL/NA, 820/840)에 검증을 요청하고 서비스 제공자의 접근권한 부여 정책에 따라 검증하는 방법이 있을 수 있다. 예시적으로, MAS(830)에 클라이언트의 검증을 요청하는 방법은 리소스 소유자인 NA(840)가 D/G1(810)이 등록된 MAS(830)에 클라이언트의 검증을 요청하는 과정, MAS(830)이 클라이언트 크리덴셜을 기초로 D/G1(810)이 정상적으로 MAS(830)에 등록된 장치인지 여부 등을 판단하는 검증 수행 과정 및 검증 수행 결과를 바탕으로 NA(840)에게 클라이언트 검증 응답 메시지를 전달하는 과정을 포함할 수 있다. 한편, 검증 요청 메시지에는 클라이언트 크리덴셜(Client_ID 및 Client_Secret) 등의 파라미터가 포함될 수 있으며, 클라이언트 검증 응답 메시지에는 클라이언트 크리덴셜, 인증서(Certificates) 등이 포함될 수 있다.
STEP 05는 권한부여 승인 단계(S950)이다. 클라이언트 인증이 정상적으로 완료되면 NA(840)는 D/G1(810)이 해당 리소스에 접근할 수 있도록 접근 권한을 설정하도록 D/G2(850)에게 요청한다. D/G2(850)는 NA(840)의 요청에 따라 해당 리소스에 대한 접근권한 리소스(accessRight resource)를 생성하거나 이미 접근권한 리소스가 존재할 경우에는 그 속성을 갱신(Update)한다. 접근권한 리소스의 속성은 만료시간(Expiration Time)을 포함할 수 있고, D/G2(850)는 D/G1(810)의 접근권한에 만료시간을 설정할 수 있다. NA(840)는 D/G1(810)의 권한부여 요청이 승인되었음을 알리는 권한부여 승인 메시지를 NSCL(820)를 거쳐 MAS(830)에 전송한다. 접근 권한 설정을 요청하는 메시지 및 권한부여 승인 메시지에 포함될 수 있는 파라미터 내지 정보는 도 3의 STEP 03과 동일하므로 설명은 생략한다.
STEP 06은 선택적 절차로서, 권한부여 코드 발급 및 액세스 토큰 요청 단계(S860)이다. MAS(830)는 D/G1(810)의 권한부여 요청이 승인되었다는 증거로, 권한부여 코드(Authorization Code)를 생성하여 D/G1(810)에게 발급한다. D/G1(810)은 발급받은 권한부여 코드를 사용하여, 리소스 정보를 조회하기 위해 요구되는 액세스 토큰(Access Token)의 발급을 MAS(830)에 요청한다. 한편, 액세스 토큰 발급 요청 메시지에 포함될 수 있는 파라미터는 도 3의 STEP 06과 동일하므로 설명은 생략한다.
STEP 07은 액세스 토큰 발급 단계(S970)이다. MAS(830)는 D/G1(810)의 권한부여 코드를 체크하고, 확인이 되면 액세스 토큰을 생성하여 리소스가 위치한 D/G2(850)에게 전송하고, 허용된 접근범위와 함께 생성된 액세스 토큰을 D/G1(810)에게 발급한다. SETP 06이 생략될 경우 MAS(830)는 권한부여 코드를 체크하지 않고, STEP 05에서 리소스 소유자로부터 권한부여 승인 메시지를 수신한 후 액세스 토큰을 생성한다. D/G1(810)은 수신한 액세스 토큰과 접근권한 리소스를 매핑하여 관리한다. MAS(830)는 액세스 토큰의 갱신을 위하여 액세스 토큰과 함께 갱신 토큰(Refresh Token)을 발급할 수 있다. 한편, 액세스 토큰 발급 메시지에 포함될 수 있는 파라미터는 도 3의 STEP 07과 동일하므로 설명을 생략한다.
STEP 08은 보호된 리소스에 접근하는 단계(S980)이다. D/G1(810)는 액세스 토큰을 기초로 D/G2(850)에 위치한 리소스에 접근하여 정보를 조회한다. D/G2(850)은 D/G1(810)로부터 전송받은 액세스 토큰과 자신이 MAS(830)로부터 수신한 액세스 토큰이 일치하는지 여부를 체크하고, 접근권한 리소스를 확인하여 해당 액세스 토큰과 매칭되는 접근 권한 범위안에서 해당 리소스에 대한 D/G1(810)의 접근을 허용한다.
도 10은 클라이언트와 리소스 소유자가 동일한 M2M 서비스 제공자 도메인에 속해 있고, 리소스 소유자가 D/G2인 경우에 있어서 본 발명의 일 실시예에 따른 리소스 접근 권한 설정 과정의 개략적인 흐름도이다.
도 10에서 각 개체들간의 관계를 살펴보면, D/G1(810) 및 D/G2(850)가 동일한 M2M 서비스 제공자 도메인 내에 있으며, D/G1(810)이 클라이언트이고, D/G2(850)가 리소스 소유자에 해당한다. 클라이언트가 접근하고자 하는 리소스는 D/G2(750)의 SCL상에 위치한다. 도 10의 절차는 클라이언트, 리소스 소유자가 동일한 M2M 서비스 제공자 도메인에 있다는 점을 제외하고는 도 4의 절차와 유사하다.
도 10 및 이하의 설명에서 클라이언트로 D/G1(810)을 표시하였으나, 클라이언트가 엔드-유저(800)인 경우에도 동일한 접근 권한 설정 메커니즘이 적용될 수 있음을 유의해야 한다.
STEP 01(S1010), STEP 02(S1020), STEP 06(S1060), STEP 07(S1070), STEP 08(S1080)에서는 각각 도 9의 해당 STEP과 동일한 과정이 수행되므로 설명은 생략하고, 이하에서는 STEP 03, STEP 04, STEP 05에 대해서 설명하기로 한다.
STEP 03은 권한부여 요청 단계(S1030)이다. 권한부여 요청 단계(S1030)에서 클라이언트는 리소스 소유자에게 권한부여 요청(Authorization Request)을 수행한다. D/G1(810)은 권한부여 요청 메시지를 NSCL(820)에 전송한다. NSCL(820)은 리소스_URI에 대응하는 리소스 소유자가 누구인지를 SCL 또는 애플리케이션 리소스 레벨에서 검색한다. 검색된 리소스 소유자인 D/G2(850)에게 NSCL(820)은 권한부여 요청 메시지를 전달한다. 한편, 권한부여 요청 메시지에 포함될 수 있는 파라미터는 도 3의 STEP 03과 동일하므로 설명을 생략한다.
STEP 04는 클라이언트 검증(Verification) 단계(S1040)이다. D/G2(850)는 NSCL(820)으로부터 전달된 권한부여 요청 메시지에 대하여 해당 클라이언트에 관한 검증을 수행한다. 클라이언트를 검증하는 방법에는 MAS(830)에 클라이언트의 검증을 요청하는 방법, M2M 서비스 제공자(NSCL, NA)에 검증을 요청하고 서비스 제공자의 접근권한 부여 정책에 따라 검증하는 방법이 있을 수 있다. 예시적으로, MAS(830)에 D/G1(810)의 검증을 요청하는 방법은 D/G2(850)가 NSCL(530)을 거쳐 MAS(540)에 클라이언트의 검증을 요청하는 과정, MAS(830)가 클라이언트 크리덴셜을 기초로 D/G1(810)가 정상적으로 MAS(830)에 등록된 장치인지 여부 등을 판단하는 검증 수행 과정 및 검증 수행 결과를 바탕으로 MAS(830)가 NSCL(820)을 거쳐 D/G2(840)에게 클라이언트 검증 응답 메시지를 전달하는 과정을 포함할 수 있다. 한편, 검증 요청 메시지에는 클라이언트 크리덴셜(Client_ID 및 Client_Secret) 등의 파라미터가 포함될 수 있으며, 클라이언트 검증 응답 메시지에는 클라이언트 크리덴셜, 인증서(Certificates) 등이 포함될 수 있다.
STEP 05는 권한부여 승인 단계(S1050)이다. 클라이언트 인증이 정상적으로 완료되면 D/G2(850)는 D/G1(810)이 해당 리소스에 접근할 수 있도록 해당 리소스에 대한 접근권한 리소스(accessRight resource)를 생성하거나 이미 접근권한 리소스가 존재할 경우에는 그 속성을 갱신(Update)한다. 여기서, 접근권한 리소스는 보호된 리소스에 대한 접근 권한에 대한 정보, 즉 보호된 리소스에 어떠한 개체가 무엇을 할 수 있는지에 관한 정보를 저장하고 있는 리소스이다. D/G2(850)는 D/G1(810)에 대한 권한부여가 승인되었음을 알리는 권한부여 승인 메시지를 NSCL(820)를 거쳐 MAS(830)에 전송한다. 접근 권한 설정을 요청하는 메시지 및 권한부여 승인 메시지에 포함될 수 있는 파라미터는 도 4의 STEP 05와 동일하므로 설명은 생략한다.
이상의 설명은 도 3, 도 4, 도 6, 도 7, 도 9 및 도 10에서 각 단계가 순차적으로 실행하는 것으로 기재하고 있으나, 이는 본 발명의 일 실시예의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명의 일 실시예가 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 일 실시예의 본질적인 특성에서 벗어나지 않는 범위에서 도 3, 도 4, 도 6, 도 7, 도 9 및 도 10에 기재된 순서를 변경하여 실행하거나 위 단계들 중 하나 이상의 단계를 병렬적으로 실행하는 것으로 다양하게 수정 및 변형하여 적용 가능할 것이므로, 도 3, 도 4, 도 6, 도 7, 도 9 및 도 10은 시계열적인 순서로 한정되는 것은 아니다.
이상의 설명은 본 실시예의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 실시예가 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 실시예의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 실시예들은 본 실시예의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예에 의하여 본 실시예의 기술 사상의 범위가 한정되는 것은 아니다. 본 실시예의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 실시예의 권리범위에 포함되는 것으로 해석되어야 할 것이다.
200: D/G1
210: MAS1
220: NSCL1
260: NSCL2
270: MAS2
280: D/G2
290: NA2
510: 엔드-유저
520: NA
530: NSCL
540: MAS
550: D/G
810: D/G1
820: NSCL
830: MAS
840: NA
850: D/G2

Claims (57)

  1. 제1 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)가 제2 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스(Resource)에 접근하고자 하는 경우에 있어서,
    상기 클라이언트가 상기 제1 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 제1 M2M 서비스 제공자 도메인의 MAS(M2M Authentication Sever; 이하 'MAS1'이라고 칭함)로부터 클라이언트 크리덴셜(Client Credentials)을 할당받는 클라이언트 등록 과정;
    상기 클라이언트가 상기 리소스의 URI(Universal Resource Identifier) 정보를 기초로 하여 상기 제2 M2M 서비스 제공자 도메인의 NSCL(이하 'NSCL2'라고 칭함)을 통해 상기 리소스의 리소스 소유자에게 상기 리소스에 대한 접근 권한부여(Authorization)를 요청하는 권한부여 요청 과정;
    상기 리소스 소유자가 상기 MAS1을 통해 상기 클라이언트를 검증(Verification)하는 클라이언트 검증 과정;
    상기 리소스 소유자가 상기 클라이언트에 대한 접근 권한부여를 승인하는 권한부여 승인 과정; 및
    상기 제2 M2M 서비스 제공자 도메인의 MAS(이하 'MAS2'라고 칭함)가 상기 클라이언트에게 액세스 토큰(Access Token)을 발급하는 액세스 토큰 발급 과정
    을 포함하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  2. 제1항에 있어서,
    상기 클라이언트가 상기 제2 M2M 서비스 제공자 도메인의 NSCL(이하 'NSCL2'이라고 칭함) 또는 상기 리소스 소유자 중 어느 하나의 개체를 통하여 상기 리소스의 URI 정보를 얻는 리소스 검색 과정을 더 포함하는 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  3. 제1항에 있어서,
    상기 MAS2가 상기 클라이언트에게 권한부여 코드(Authorization Code)를 발급하는 권한부여 코드 발급 과정; 및
    상기 클라이언트가 상기 발급받은 권한부여 코드를 이용하여 상기 MAS2에 액세스 토큰의 발급을 요청하는 액세스 토큰 요청 과정
    을 더 포함하는 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  4. 제1항에 있어서,
    상기 권한부여 요청 과정은,
    상기 클라이언트가 상기 NSCL2에 상기 권한부여 요청 메시지를 전송하고, 상기 NSCL2는 상기 리소스의 URI 정보에 대응되는 리소스 소유자를 검색하여, 검색된 리소스 소유자에게 상기 권한부여 요청 메시지를 전달하는 과정인 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  5. 제4항에 있어서,
    상기 NSCL2는 SCL 또는 애플리케이션 중 어느 하나가 가지는 속성(Attribute)으로부터 상기 리소스 소유자 정보를 획득하는 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  6. 제1항에 있어서,
    상기 권한부여 승인 과정은,
    상기 리소스가 위치한 상기 단말 또는 게이트웨이에 상기 리소스에 대한 접근권한 리소스를 생성 또는 갱신할 것을 요청하고, 상기 MAS2에 상기 클라이언트에 대한 접근권한이 승인되었음을 통지하는 과정인 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  7. 제1항에 있어서,
    상기 MAS1 및 상기 MAS2는,
    인증(Authentication), 권한부여(Authorization) 및 어카운팅(Accounting) 서비스(이하 'AAA 서비스'라고 칭함)를 제공하는 서버 또는 AAA 서비스를 제공하는 제3의 M2M 서비스 제공자 도메인의 서버인 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  8. 제1항에 있어서,
    상기 리소스 소유자는,
    제2 M2M 서비스 제공자 도메인에 속하는 M2M 단말, M2M 게이트웨이 또는 NA 중 어느 하나의 개체인 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  9. 제1항에 있어서,
    상기 액세스 토큰은 유효기간(Life-time)이 설정된 것임을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  10. 제1 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)가 제2 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하는 방법에 있어서,
    상기 제1 M2M 서비스 제공자 도메인의 NSCL(이하 'NSCL1'이라고 칭함)에 클라이언트 등록 절차를 수행하여 상기 제1 M2M 서비스 제공자 도메인의 MAS(이하 'MAS1'이라 칭함)로부터 클라이언트 크리덴셜을 할당받는 과정;
    상기 리소스의 리소스 소유자에게 상기 리소스의 URI 정보를 기초로 하여 상기 리소스에 대한 접근 권한부여를 요청하는 권한부여 요청 과정;
    상기 제 2 M2M 서비스 제공자 도메인에 속하는 MAS(이하 'MAS2'이라 칭함)로부터 액세스 토큰을 발급받는 액세스 토큰 발급 과정; 및
    상기 발급받은 액세스 토큰을 기초로 상기 리소스에 접근하는 과정
    을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  11. 제10항에 있어서,
    상기 제2 M2M 서비스 제공자 도메인의 NSCL(이하 'NSCL2'라고 칭함) 또는 상기 리소스 소유자 중 어느 하나의 개체를 통하여, 상기 리소스에 관한 정보를 취득하는 리소스 검색 과정을 더 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  12. 제10항에 있어서,
    상기 MAS2로부터 권한부여 코드를 발급받는 권한부여코드 발급 과정; 및
    상기 MAS2로부터 상기 발급받은 권한부여 코드를 기초로 상기 액세스 토큰의 발급을 요청하는 과정
    을 더 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  13. 제10항에 있어서,
    상기 클라이언트 크리덴셜은,
    상기 클라이언트의 식별수단으로서 사용되는 클라이언트_식별자(Client_ID) 및 상기 클라이언트_식별자에 대응되는 패스워드로 사용되는 클라이언트_시크릿(Client_Secret)을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  14. 제1 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스를 소유하는 리소스 소유자가, 제2 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 및 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)의 상기 리소스에 대한 접근권한을 부여하는 방법에 있어서,
    상기 클라이언트에 관한 권한부여 요청을 수신하는 과정;
    상기 제2 M2M 서비스 제공자 도메인에 속하는 MAS(이하 'MAS2'이라 칭함)를 통해 상기 클라이언트를 검증하는 과정; 및
    상기 리소스가 위치한 개체 및 상기 제1 M2M 서비스 제공자 도메인에 속하는 MAS(이하 'MAS1'라고 칭함)에 상기 클라이언트에 대한 접근 권한부여를 승인하는 과정
    을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  15. 제14항에 있어서,
    상기 권한부여 요청을 수신하는 과정은,
    상기 제2 M2M 서비스 제공자 도메인의 NSCL(이하 'NSCL2'라고 칭함)를 통해 상기 클라이언트의 권한부여 요청 메시지를 수신하되,
    상기 권한부여 요청 메시지에는 상기 클라이언트의 클라이언트 크리덴셜 정보를 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  16. 제15항에 있어서,
    상기 클라이언트를 검증하는 과정은,
    상기 클라이언트의 클라이언트 크리덴셜 정보를 기초로 상기 클라이언트가 상기 MAS2에 정상적으로 등록된 클라이언트인지 여부를 확인하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  17. 제14항에 있어서,
    상기 접근 권한부여를 승인하는 과정은,
    상기 제1 M2M 서비스 제공자 도메인의 NSCL(이하 'NSCL1'이라고 칭함)에 상기 리소스에 대한 접근권한 리소스를 생성 또는 갱신할 것을 요청하고 상기 MAS1에 상기 클라이언트에 대한 접근권한이 승인되었음을 통지하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  18. 제17항에 있어서,
    상기 리소스 소유자가 상기 리소스가 위치한 개체와 동일한 개체인 경우에, 상기 접근권한 리소스의 생성 또는 갱신을 요청하는 것은 로컬로 수행되는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  19. 어떠한 M2M 서비스 제공자 도메인에도 속하지 않는 개체(이하 '클라이언트'라고 칭함)가 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하고자 하는 경우에 있어서,
    상기 클라이언트가 상기 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 M2M 서비스 제공자 도메인의 MAS로부터 클라이언트 크리덴셜을 할당받는 클라이언트 등록 과정;
    상기 클라이언트가 상기 리소스의 URI 정보를 기초로 하여 상기 M2M 서비스 제공자 도메인의 NSCL을 통해 상기 리소스의 리소스 소유자에게 상기 리소스에 대한 접근 권한부여를 요청하는 권한부여 요청 과정;
    상기 리소스 소유자가 상기 M2M 서비스 제공자 도메인의 MAS를 통해 상기 클라이언트를 검증하는 클라이언트 검증 과정;
    상기 리소스 소유자가 상기 MAS에 상기 클라이언트에 대한 접근 권한부여를 승인하는 권한부여 승인 과정; 및
    상기 MAS가 상기 클라이언트에게 액세스 토큰을 발급하는 액세스 토큰 발급 과정
    을 포함하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  20. 제19항에 있어서,
    상기 클라이언트가 상기 NSCL 또는 상기 리소스 소유자 중 어느 하나의 개체를 통하여 상기 리소스의 URI 정보를 얻는 리소스 검색 과정을 더 포함하는 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  21. 제19항에 있어서,
    상기 MAS가 상기 클라이언트에게 권한부여 코드를 발급하는 권한부여 코드 발급 과정; 및
    상기 클라이언트가 발급받은 코드를 이용하여 상기 MAS에 액세스 토큰을 요청하는 액세스 토큰 요청 과정
    을 더 포함하는 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  22. 제19항에 있어서,
    상기 권한부여 승인 과정은,
    상기 리소스가 위치한 개체에 상기 리소스에 대한 접근권한 리소스를 생성 또는 갱신할 것을 요청하고, 상기 MAS에 상기 클라이언트에 대한 접근권한이 승인되었음을 통지하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  23. 제19항에 있어서,
    상기 MAS는,
    AAA 서비스를 제공하는 서버 또는 AAA 서비스를 제공하는 제3의 M2M 서비스 제공자 도메인의 서버인 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  24. 제19항에 있어서,
    상기 리소스 소유자는,
    상기 M2M 서비스 제공자 도메인에 속하는 M2M 단말, M2M 게이트웨이 또는 NA 중 어느 하나의 개체인 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  25. 제19항에 있어서,
    상기 액세스 토큰은 유효기간(Life-time)이 설정된 것임을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  26. 어떠한 M2M 서비스 제공자 도메인에도 속하지 않는 개체(이하 '클라이언트'라고 칭함)가 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하는 방법에 있어서,
    상기 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 M2M 서비스 제공자 도메인의 MAS로부터 클라이언트 크리덴셜을 할당받는 과정;
    상기 리소스의 리소스 소유자에게 상기 리소스의 URI 정보를 기초로 하여 상기 리소스에 대한 접근 권한부여를 요청하는 과정;
    상기 MAS로부터 액세스 토큰을 발급받는 과정; 및
    상기 발급받은 액세스 토큰을 기초로 상기 리소스에 접근하는 과정
    을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  27. 제26항에 있어서,
    상기 NSCL 또는 상기 리소스 소유자 중 어느 하나의 개체를 통하여, 상기 리소스에 관한 정보를 취득하는 리소스 검색 과정을 더 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  28. 제26항에 있어서,
    상기 MAS로부터 상기 권한부여 요청이 승인되었다는 증거로 권한부여 코드를 발급받고, 상기 발급받은 권한부여 코드를 기초로 상기 MAS에 상기 액세스 토큰의 발급을 요청하는 과정을 더 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  29. 제26항에 있어서,
    상기 클라이언트 크리덴셜은,
    상기 클라이언트의 식별수단으로서 사용되는 클라이언트_식별자 및 상기 클라이언트_식별자에 대응하는 패스워드로 사용되는 클라이언트_시크릿을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  30. M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스를 소유한 리소스 소유자가, 어떠한 M2M 서비스 제공자 도메인에도 속하지 않는 개체(이하 '클라이언트'라고 칭함)의 상기 리소스에 대한 접근권한을 부여하는 방법에 있어서,
    상기 클라이언트에 관한 권한부여 요청을 수신하는 과정;
    상기 M2M 서비스 제공자 도메인에 속하는 MAS(이하 'MAS'이라 칭함)를 통해 상기 클라이언트를 검증하는 과정; 및
    상기 리소스가 위치한 개체 및 상기 MAS에 상기 클라이언트에 대한 접근 권한부여를 승인하는 과정
    을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  31. 제30항에 있어서,
    상기 권한부여 요청을 수신하는 과정은,
    상기 M2M 서비스 제공자 도메인의 NSCL을 통해 상기 클라이언트의 권한부여 요청 메시지를 수신하되, 상기 권한부여 요청 메시지에는 상기 클라이언트의 클라이언트 크리덴셜 및 인증 타입 정보를 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  32. 제31항에 있어서,
    상기 클라이언트를 검증하는 과정은,
    상기 클라이언트의 클라이언트 크리덴셜 정보를 기초로 상기 클라이언트가 상기 MAS에 정상적으로 등록된 클라이언트인지 여부를 확인하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  33. 제30항에 있어서,
    상기 접근 권한부여를 승인하는 과정은,
    상기 리소스가 위치한 개체에 상기 리소스에 대한 접근권한 리소스를 생성 또는 갱신할 것을 요청하고 상기 MAS에 상기 클라이언트에 대한 접근권한이 승인되었음을 통지하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  34. 제31항에 있어서,
    상기 리소스 소유자가 상기 리소스가 위치한 개체와 동일한 개체인 경우에, 상기 접근권한 리소스의 생성 또는 갱신을 요청하는 것은 로컬로 수행되는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  35. 어느 한 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저(이하 '클라이언트'라고 칭함)가 동일한 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하고자 하는 경우에 있어서,
    상기 클라이언트가 상기 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 M2M 서비스 제공자 도메인의 MAS로부터 클라이언트 크리덴셜을 할당받는 클라이언트 등록 과정;
    상기 클라이언트가 상기 리소스의 URI 정보를 기초로 하여 상기 M2M 서비스 제공자 도메인의 NSCL을 통해 상기 리소스의 리소스 소유자에게 상기 리소스에 대한 접근 권한부여를 요청하는 권한부여 요청 과정;
    상기 리소스 소유자가 상기 M2M 서비스 제공자 도메인의 MAS를 통해 상기 클라이언트를 검증하는 클라이언트 검증 과정;
    상기 리소스 소유자가 상기 클라이언트에 대한 접근 권한부여를 승인하는 권한부여 승인 과정; 및
    상기 MAS가 상기 클라이언트에게 액세스 토큰을 발급하는 액세스 토큰 발급 과정
    을 포함하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  36. 제35항에 있어서,
    상기 클라이언트가 상기 NSCL 또는 상기 리소스 소유자 중 어느 하나의 개체를 통하여 상기 리소스의 URI 정보를 얻는 리소스 검색 과정을 더 포함하는 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  37. 제35항에 있어서,
    상기 MAS가 상기 클라이언트에게 권한부여 코드를 발급하는 권한부여 코드 발급 과정; 및
    상기 클라이언트가 발급받은 코드를 이용하여 상기 MAS에 액세스 토큰을 요청하는 액세스 토큰 요청 과정
    을 더 포함하는 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  38. 제35항에 있어서,
    상기 권한부여 승인 과정은,
    상기 리소스가 위치한 개체에 상기 리소스에 대한 접근권한 리소스를 생성 또는 갱신할 것을 요청하고, 상기 MAS에 상기 클라이언트에 대한 접근권한이 승인되었음을 통지하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법
  39. 제35항에 있어서,
    상기 MAS는,
    AAA 서비스를 제공하는 서버 또는 AAA 서비스를 제공하는 제3의 M2M 서비스 제공자 도메인의 서버인 것을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  40. 제35항에 있어서,
    상기 액세스 토큰은 유효기간이 설정된 것임을 특징으로 하는, M2M 통신에서 리소스 접근 권한 설정 방법.
  41. 어느 한 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)가 동일한 M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스에 접근하는 방법에 있어서,
    상기 M2M 서비스 제공자 도메인의 NSCL에 클라이언트 등록 절차를 수행하여 상기 M2M 서비스 제공자 도메인의 MAS로부터 클라이언트 크리덴셜을 할당받는 과정;
    상기 리소스의 리소스 소유자에게 상기 리소스의 URI 정보를 기초로 하여 상기 리소스에 대한 접근 권한부여를 요청하는 과정;
    상기 M2M 서비스 제공자 도메인의 MAS로부터 액세스 토큰을 발급받는 과정; 및
    상기 발급받은 액세스 토큰을 기초로 상기 리소스에 접근하는 과정
    을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  42. 제41항에 있어서,
    상기 NSCL 또는 상기 리소스 소유자 중 어느 하나의 개체를 통하여, 상기 리소스에 관한 정보를 취득하는 리소스 검색 과정을 더 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  43. 제41항에 있어서,
    상기 클라이언트 크리덴셜은,
    상기 클라이언트의 식별수단으로서 사용되는 클라이언트_식별자 및 상기 클라이언트_식별자에 대응되는 패스워드로 사용되는 클라이언트_시크릿을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  44. 제41항에 있어서,
    상기 MAS로부터 상기 권한부여 요청이 승인되었다는 증거로 권한부여 코드를 발급받고, 상기 발급받은 권한부여 코드를 기초로 상기 MAS에 상기 액세스 토큰의 발급을 요청하는 권한부여코드 발급 과정을 더 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스 접근 방법.
  45. M2M 서비스 제공자 도메인의 단말 또는 게이트웨이에 위치한 리소스를 소유한 리소스 소유자가 상기 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체(이하 '클라이언트'라고 칭함)의 상기 리소스에 대한 접근권한을 부여하는 방법에 있어서,
    상기 클라이언트에 관한 권한부여 요청을 수신하는 과정;
    상기 M2M 서비스 제공자 도메인에 속하는 MAS를 통해 상기 클라이언트를 검증하는 과정; 및
    상기 리소스가 위치한 개체 및 상기 MAS에 상기 클라이언트에 대한 접근 권한부여를 승인하는 과정
    을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  46. 제45항에 있어서,
    상기 권한부여 요청을 수신하는 과정은,
    상기 M2M 서비스 제공자 도메인의 NSCL을 통해 상기 클라이언트의 권한부여 요청 메시지를 수신하되,
    상기 권한부여 요청 메시지에는 상기 클라이언트의 클라이언트 크리덴셜 및 인증 타입 정보를 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  47. 제46항에 있어서,
    상기 클라이언트를 검증하는 과정은,
    상기 클라이언트의 클라이언트 크리덴셜 정보를 기초로 상기 클라이언트가 상기 MAS에 정상적으로 등록된 클라이언트인지 여부를 확인하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  48. 제45항에 있어서,
    상기 접근 권한부여를 승인하는 과정은,
    상기 리소스가 위치한 개체에 상기 리소스에 대한 접근권한 리소스를 생성 또는 갱신할 것을 요청하고 상기 MAS에 상기 클라이언트에 대한 접근권한이 승인되었음을 통지하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  49. 제48항에 있어서,
    상기 리소스 소유자가 상기 리소스가 위치한 개체와 동일한 개체인 경우에, 상기 접근권한 리소스의 생성 또는 갱신을 요청하는 것은 로컬로 수행되는 것을 특징으로 하는, M2M 통신에서 클라이언트의 리소스에 대한 접근권한을 부여하는 방법.
  50. DSCL 또는 GSCL상에 리소스를 보유한 단말 또는 게이트웨이가 상기 리소스에 대한 클라이언트의 접근을 허용하는 방법에 있어서,
    상기 리소스의 리소스 소유자로부터 상기 클라이언트에 관한 접근권한 설정 요청을 수신하는 과정;
    상기 클라이언트의 상기 리소스에 관한 접근권한을 설정하는 과정;
    AAA 서비스를 제공하는 서버로부터 상기 클라이언트에게 발급한 액세스 토큰을 전달받는 과정; 및
    상기 AAA 서비스를 제공하는 서버로부터 전달받은 액세스 토큰과 상기 클라이언트가 제시하는 액세스 토큰의 일치 여부를 바탕으로 상기 클라이언트의 상기 리소스에 대한 접근의 허용여부를 판단하는 과정
    을 포함하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 접근을 허용하는 방법.
  51. 제50항에 있어서,
    상기 접근권한 설정 요청을 수신하는 과정은,
    상기 리소스를 보유한 단말 또는 게이트웨이와 상기 리소스 소유자가 동일한 개체인 경우에 로컬(Local)로 수행되는 것을 특징으로 하는, M2M 통신에서 클라이언트의 접근을 허용하는 방법.
  52. 제50항에 있어서,
    상기 AAA 서비스를 제공하는 서버는,
    상기 리소스를 보유한 단말 또는 게이트웨이가 속하는 M2M 서비스 제공자 도메인의 MAS, 상기 리소스를 보유한 단말 또는 게이트웨이가 속하는 M2M 서비스 제공자 도메인의 AAA 서비스를 제공하는 서버 또는 AAA 서비스를 제공하는 별개의 M2M 서비스 제공자 도메인의 서버인 것을 특징으로 하는, M2M 통신에서 클라이언트의 접근을 허용하는 방법.
  53. 제50항에 있어서,
    상기 클라이언트는,
    상기 리소스를 보유한 단말 또는 게이트웨이가 속하는 M2M 서비스 제공자 도메인과 다른 별개의 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체이거나, 어떠한 M2M 서비스 제공자 도메인에도 속하는 않는 개체이거나, 상기 리소스를 보유한 단말 또는 게이트웨이가 속하는 M2M 서비스 제공자 도메인에 속하는 단말, 게이트웨이 또는 엔드-유저 중 어느 하나의 개체인 것을 특징으로 하는, M2M 통신에서 클라이언트의 접근을 허용하는 방법.
  54. 제50항에 있어서,
    상기 접근권한 설정 요청을 수신하는 과정은,
    상기 클라이언트의 클라이언트 크리덴셜, 접근 범위 또는 리소스 위치 중 적어도 어느 하나의 정보를 포함하는 접근권한 설정 요청 메시지를 수신하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 접근을 허용하는 방법.
  55. 제54항에 있어서,
    상기 접근권한을 설정하는 과정은,
    상기 접근권한 설정 요청 메시지에 포함된 정보를 기초로 상기 리소스로의 접근권한에 관한 정보를 가지는 접근권한 리소스(accessRight Resource)를 생성하거나 갱신하는 과정인 것을 특징으로 하는, M2M 통신에서 클라이언트의 접근을 허용하는 방법.
  56. 제55항에 있어서,
    상기 액세스 토큰을 전달받는 과정은,
    상기 전달받은 액세스 토큰을 상기 접근권한 리소스과 매핑하여 관리하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 접근을 허용하는 방법.
  57. 제55항에 있어서,
    상기 접근의 허용여부를 판단하는 과정은,
    상기 접근권한 리소스에서 상기 클라이언트에 대해 허용된 접근 권한 범위를 확인하는 것을 특징으로 하는, M2M 통신에서 클라이언트의 접근을 허용하는 방법.
KR1020120057167A 2012-05-30 2012-05-30 Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법 KR101453155B1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR1020120057167A KR101453155B1 (ko) 2012-05-30 2012-05-30 Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법
PCT/KR2012/009879 WO2013180357A1 (ko) 2012-05-30 2012-11-21 Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법
US14/403,977 US9319413B2 (en) 2012-05-30 2012-11-21 Method for establishing resource access authorization in M2M communication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020120057167A KR101453155B1 (ko) 2012-05-30 2012-05-30 Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020130162703A Division KR20140006755A (ko) 2013-12-24 2013-12-24 Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법

Publications (2)

Publication Number Publication Date
KR20130133988A KR20130133988A (ko) 2013-12-10
KR101453155B1 true KR101453155B1 (ko) 2014-10-23

Family

ID=49673521

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020120057167A KR101453155B1 (ko) 2012-05-30 2012-05-30 Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법

Country Status (3)

Country Link
US (1) US9319413B2 (ko)
KR (1) KR101453155B1 (ko)
WO (1) WO2013180357A1 (ko)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8346095B2 (en) * 2009-12-07 2013-01-01 Centurylink Intellectual Property Llc System and method for providing multi-provider telecommunications services over a passive optical network
WO2014123884A1 (en) * 2013-02-07 2014-08-14 Interdigital Patent Holdings, Inc. Methods and apparatuses for restful batch services
WO2014195905A2 (en) * 2013-06-07 2014-12-11 Telefonaktiebolaget L M Ericsson (Publ) Optimization of resource urls in machine-to-machine networks
JP6354132B2 (ja) * 2013-10-09 2018-07-11 富士ゼロックス株式会社 中継装置、中継システム及びプログラム
DE102013022029A1 (de) * 2013-12-19 2015-06-25 Giesecke & Devrient Gmbh Verfahren und Vorrichtungen zum Verwalten von Subskriptionen auf einem Sicherheitselement
WO2015123785A1 (en) * 2014-02-24 2015-08-27 Sierra Wireless, Inc. Wireless device customization resources
US9609674B2 (en) 2014-03-31 2017-03-28 Telefonaktiebolaget Lm Ericsson (Publ) Machine-to-machine domain proxy
CN106471465B (zh) 2014-04-09 2019-10-22 康维达无线有限责任公司 服务启用器功能
WO2016014079A1 (en) * 2014-07-25 2016-01-28 Hewlett-Packard Development Company, L.P. Constraining authorization tokens via filtering
JP2017538209A (ja) * 2014-11-14 2017-12-21 コンヴィーダ ワイヤレス， エルエルシー 許可ベースのリソースおよびサービス発見
US10051561B2 (en) * 2014-12-02 2018-08-14 Telefonaktiebolaget Lm Ericsson (Publ) Methods and nodes for M2M communication
CN107683599A (zh) * 2015-06-11 2018-02-09 西门子公司 用于设备的认证令牌的授权发布的授权装置和方法
EP4037360A1 (en) * 2015-08-28 2022-08-03 Convida Wireless, LLC Service layer dynamic authorization
CN106656942B (zh) * 2015-11-03 2019-12-13 电信科学技术研究院 角色令牌颁发方法、访问控制方法及相关设备
US11019490B2 (en) 2016-07-01 2021-05-25 Intel Corporation Group management in reconfigurable machine-to-machine systems
CN110730063B (zh) * 2018-07-16 2022-11-11 中国电信股份有限公司 安全验证方法、系统、物联网平台、终端和可读存储介质
US11170118B2 (en) * 2019-10-21 2021-11-09 Saudi Arabian Oil Company Network system and method for access management authentication and authorization
CN111654476B (zh) * 2020-05-20 2022-07-29 中国工商银行股份有限公司 一种用户授权访问处理方法及装置
KR102247132B1 (ko) * 2020-07-24 2021-05-03 한국전자기술연구원 다수의 엣지 서버들로 구성된 클라우드 환경에서 리소스별 접근 권한 제어를 위한 확장된 인증 방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100011142A (ko) * 2008-07-24 2010-02-03 에스케이 텔레콤주식회사 리소스 보안 시스템 및 리소스 보안 방법

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6460141B1 (en) * 1998-10-28 2002-10-01 Rsa Security Inc. Security and access management system for web-enabled and non-web-enabled applications and content on a computer network
US20060021004A1 (en) * 2004-07-21 2006-01-26 International Business Machines Corporation Method and system for externalized HTTP authentication
US8464317B2 (en) * 2005-05-06 2013-06-11 International Business Machines Corporation Method and system for creating a protected object namespace from a WSDL resource description
US7796578B2 (en) * 2005-10-05 2010-09-14 Cingular Wireless Ii, Llc Resolution of IP addresses associated with a telephone number utilizing query flags
US8006289B2 (en) * 2005-12-16 2011-08-23 International Business Machines Corporation Method and system for extending authentication methods
JP2008034039A (ja) 2006-07-28 2008-02-14 Sony Corp 光ディスクドライブ装置及び光ディスクドライブ装置のサーボ制御方法
GB0621684D0 (en) * 2006-10-31 2006-12-06 British Telecomm Secure access
US8205246B2 (en) * 2007-05-10 2012-06-19 Cisco Technology, Inc. User sensitive filtering of network application layer resources
KR101861607B1 (ko) 2008-01-18 2018-05-29 인터디지탈 패튼 홀딩스, 인크 Ｍ2ｍ 통신을 인에이블하는 방법 및 장치
JP5042063B2 (ja) * 2008-02-21 2012-10-03 三洋電機株式会社 被制御装置、制御システムおよび管理装置
WO2009139869A1 (en) * 2008-05-13 2009-11-19 Tirk Eric E Device and method for distributing and monetizing host applications
KR101029366B1 (ko) 2009-03-03 2011-04-13 주식회사 케이티 Ｍ２ｍ 장치에서의 가입자 인증 정보 저장 방법 및 이를 위한 구조
JP5523054B2 (ja) * 2009-10-19 2014-06-18 キヤノン株式会社 印刷仲介サーバ及び印刷仲介方法
US8880026B2 (en) * 2009-12-22 2014-11-04 Alcatel Lucent Method and apparatus for providing network services to a mobile user equipment
CN102907068A (zh) * 2010-03-09 2013-01-30 交互数字专利控股公司 支持机器对机器通信的方法和设备
KR20110117030A (ko) * 2010-04-20 2011-10-26 삼성전자주식회사 장치 대 장치 서비스를 제공하는 디바이스 관리 방법 및 시스템과 그 장치
US8626893B2 (en) * 2010-06-17 2014-01-07 Interdigital Patent Holdings, Inc. Application layer protocol support for sleeping nodes in constrained networks
KR101908756B1 (ko) * 2010-11-19 2018-10-16 아이오티 홀딩스, 인크. 자원의 공지 및 비공지를 위한 기계대 기계(m2m) 인터페이스 절차
JP5775174B2 (ja) * 2010-12-30 2015-09-09 インターデイジタル パテント ホールディングス インコーポレイテッド 通信ハンドオフのシナリオのための認証およびセキュアチャネルの設定
MY162193A (en) * 2011-02-11 2017-05-31 Interdigital Patent Holdings Inc Systems, methods and apparatus for managing machine-to-machine (m2m) entities
KR101549765B1 (ko) * 2011-03-03 2015-09-02 인터디지탈 패튼 홀딩스, 인크 발견된 서비스 공급자와 제휴된 서비스들에 접근하는 방법 및 장치
US9338306B2 (en) * 2011-10-28 2016-05-10 Telefonaktiebolaget Lm Ericsson (Publ) Processing usage information for machine-to-machine communication
US8667579B2 (en) * 2011-11-29 2014-03-04 Genband Us Llc Methods, systems, and computer readable media for bridging user authentication, authorization, and access between web-based and telecom domains

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100011142A (ko) * 2008-07-24 2010-02-03 에스케이 텔레콤주식회사 리소스 보안 시스템 및 리소스 보안 방법

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ETSI TS 102 690 V1.1.1, (2011.10) *
ETSI TS 102 690 V1.1.1, (2011.10)*

Also Published As

Publication number Publication date
US20150143472A1 (en) 2015-05-21
WO2013180357A1 (ko) 2013-12-05
KR20130133988A (ko) 2013-12-10
US9319413B2 (en) 2016-04-19

Similar Documents

Publication Publication Date Title
KR101453155B1 (ko) Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법
KR101453154B1 (ko) Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법
US11522865B2 (en) Automated IoT device configuration using user profile
CN108141446B (zh) 服务层动态授权
KR101274966B1 (ko) Ｍ２ｍ 통신에서 장치의 데이터 공유 방법 및 그 시스템
US10182351B2 (en) Method for service subscription resource-based authentication in wireless communication system
EP2656265B1 (en) Allocation of application identifiers
JP7421771B2 (ja) Ｉｏｔサービスを実施するための方法、アプリケーションサーバ、ｉｏｔ装置および媒体
KR20180022999A (ko) 권한부여 처리 방법 및 장치
WO2014042446A2 (ko) 무선 통신 시스템에서 특정 리소스에 대한 특정 권한 획득을 요청하기 위한 방법 및 장치
KR20200044833A (ko) 기기간 통신 네트워크에서의 자동화된 서비스 등록
WO2007079698A1 (fr) Procédé et système d'authentification d'entité, procédé et système d'authentification de bout en bout et centre d'authentification
WO2019056971A1 (zh) 一种鉴权方法及设备
JP2021507577A (ja) ＩｏＴ／Ｍ２Ｍサービス層のデータまたはサービスに対するコンテキストアウェア認証
CN114221959A (zh) 服务共享方法、装置和系统
KR20140019275A (ko) Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법
KR102558821B1 (ko) 사용자 및 디바이스 통합 인증 시스템 및 그 방법
WO2010089952A1 (ja) 情報管理システム
KR20140006755A (ko) Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법
KR20080109470A (ko) 단말 인증서를 이용한 단말 인식형 서비스 제공 방법 및과금 방법
JP6920614B2 (ja) 本人認証装置、本人認証システム、本人認証プログラム、および、本人認証方法
JP2003087332A (ja) 中継接続方式およびネットワークレベル認証サーバおよびゲートウェイ装置および情報サーバおよびプログラム
KR20150067043A (ko) 자원 정보를 송수신하는 방법 및 이를 위한 장치
KR102025521B1 (ko) 가입자 인증 모듈을 관리하는 개체를 변경하는 방법 및 이를 이용하는 장치
CN116193441A (zh) 一种通信方法、通信装置和通信系统

Legal Events

Date Code Title Description
A201 Request for examination
A107 Divisional application of patent
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20181115

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20190917

Year of fee payment: 6