티스토리 뷰
(19) 대한민국특허청(KR)
(12) 등록특허공보(B1)
(45) 공고일자 2015년01월27일
(11) 등록번호 10-1486613
(24) 등록일자 2015년01월20일
(51) 국제특허분류(Int. Cl.)
H04L 9/32 (2006.01) G06Q 20/40 (2012.01)
G06Q 30/02 (2012.01)
(21) 출원번호 10-2010-7001623
(22) 출원일자(국제) 2008년08월17일
심사청구일자 2013년07월16일
(85) 번역문제출일자 2010년01월22일
(65) 공개번호 10-2010-0045442
(43) 공개일자 2010년05월03일
(86) 국제출원번호 PCT/US2008/073411
(87) 국제공개번호 WO 2009/032511
국제공개일자 2009년03월12일
(30) 우선권주장
11/848,464 2007년08월31일 미국(US)
(56) 선행기술조사문헌
US20040073621 A1
US20040196981 A1
US20030163693 A1
US0713663 B2
(73) 특허권자
마이크로소프트 코포레이션
미국 워싱턴주 (우편번호 : 98052) 레드몬드 원
마이크로소프트 웨이
(72) 발명자
딕킨슨, 리차드 엘.
미국 98052-6399 워싱턴주 레드몬드 원 마이크로
소프트 웨이 마이크로소프트 코포레이션 국제 특
허부 내
마르티네즈, 에드워드 에이.
미국 98052-6399 워싱턴주 레드몬드 원 마이크로
소프트 웨이 마이크로소프트 코포레이션 국제 특
허부 내
(뒷면에 계속)
(74) 대리인
제일특허법인
전체 청구항 수 : 총 15 항 심사관 : 양종필
(54) 발명의 명칭 전송 가능한 제한된 보안 토큰
(57) 요 약
웹 기반 서비스 환경에서, 제3자 제공자는 그들의 보완 서비스를 위해 사용자 데이터로의 다양한 액세스 레벨을
가질 필요가 있다. 제3자 제공자가 필요한 것보다 넓은 액세스 또는 적당한 액세스 레벨이 아닌 액세스를 갖지
않게 하기 위해, 전송 가능한 제한된 보안 티켓은 제3자에 대한 적합한 액세스 레벨을 판정하기 위해 이용된다.
만료 및 제한 역할이 있는 티켓은 제3자에 대한 액세스의 기간 및 레벨을 정의한다. 제한은 권한을 부여한 사용
자의 보안 역할과 시스템 내에 정의된 제한 역할의 교차를 통해 판정된다.
대 표 도 - 도1
등록특허 10-1486613
- 1 -
(72) 발명자
푸진, 도미닉 제이.
미국 98052-6399 워싱턴주 레드몬드 원 마이크로소
프트 웨이 마이크로소프트 코포레이션 국제 특허부
내
그레왈, 자스지트 에스.
미국 98052-6399 워싱턴주 레드몬드 원 마이크로소
프트 웨이 마이크로소프트 코포레이션 국제 특허부
내
오트, 마이클 제이.
미국 98052-6399 워싱턴주 레드몬드 원 마이크로소
프트 웨이 마이크로소프트 코포레이션 국제 특허부
내
등록특허 10-1486613
- 2 -
특허청구의 범위
청구항 1
웹 기반 서비스 환경에서 사용자 데이터로의 액세스에 대한 제3자 제공자의 요청들을 안전하게 처리하기 위해
컴퓨팅 장치에 의해 실행되는 방법으로서,
제3자 제공자로부터 액세스에 대한 요청을 수신하는 단계- 상기 요청은 상기 웹 기반 서비스의 프로세스를 보완
(complement)하는 서브 프로세스와 연관됨 -;
상기 요청으로부터 티켓 및 요구(claim)를 추출하는 단계- 상기 티켓은 만료 파라미터, 상기 제3자 제공자의 제
한 역할(restriction role) 및 키 표시기(key indicator)를 포함하고, 상기 제한 역할은 로컬 범위(local
scope) 및 현재의 비즈니스 유닛의 범위를 지정하는 허가를 승인하도록 정의되고, 상기 키 표시기는 복수의 순
환 키 중 상기 티켓에 사용할 순환 키를 나타내고, 상기 복수의 순환 키 각각은 소정의 기간 이후 만료됨 -;
상기 티켓이 만료되지 않았음을 확인하는 단계;
상기 티켓과 연관된 적어도 하나의 사용자 역할을 로드(load)하는 단계;
HMAC(Hash Message Authentication Code)를 이용하여 상기 티켓을 인증하는 단계;
상기 티켓의 HMAC에 비트를 추가하는 단계;
상기 티켓의 HMAC에 비트를 추가하는 단계에 응답하여, 상기 티켓을 판독 전용 동작으로 제한하도록 상기 웹 기
반 서비스와 연관된 플랫폼 내에서 쓰기 동작을 차단하는 단계;
접속하는 사용자가 상기 로컬 범위를 지정하는 적어도 하나의 허가를 가지지만 상기 현재의 비즈니스 유닛의 범
위를 지정하는 적어도 하나의 허가를 가지지 않는 경우 상기 접속하는 사용자에 대한 상기 제3자 제공자의 상기
제한 역할의 상승(elevation)을 방지하기 위해, 상기 제한 역할과 상기 적어도 하나의 사용자 역할의 교차 부분
에 기초하여 상기 요청에 대한 액세스 제한을 판정하는 단계- 상기 제한 역할은 이미 승인된 티켓들과는 무관하
게 추가, 변경 및 제거됨 -; 및
상기 판정된 액세스 제한에 기초하여 상기 제3자 제공자가 상기 사용자 데이터를 액세스할 수 있게 하는 단계
를 포함하는 방법.
청구항 2
제1항에 있어서,
상기 티켓은 상기 제3자 제공자의 도메인 이름과 연관되는 방법.
청구항 3
제1항에 있어서,
상기 티켓은 디지털 서명을 이용하여 인증되는 방법.
청구항 4
제3항에 있어서,
상기 요구는 상기 디지털 서명을 사용하여 확인되는 방법.
청구항 5
제1항에 있어서,
상기 티켓은 조직 식별자(organization identifier)를 더 포함하고, 상기 조직 식별자는 상기 HMAC에서 동일한
사용자 식별이 재사용되는 적어도 하나의 조직상호간 공격을 방지하기 위해 사용되는 방법.
등록특허 10-1486613
- 3 -
청구항 6
제1항에 있어서,
상기 티켓은 상기 사용자 데이터를 액세스하는데 상기 티켓이 사용될 수 있는 횟수를 정의하는 반복 파라미터를
더 포함하는 방법.
청구항 7
제1항에 있어서,
상기 제한 역할과 상기 적어도 하나의 사용자 역할의 교차 부분은 상기 역할들에 정의된 제한들 중 더 제한적인
것을 나타내는 방법.
청구항 8
제1항에 있어서,
상기 역할들에 정의된 제한들 중 더 제한적인 것을 선택하는 단계와 미리 정의된 규칙을 적용하는 단계를 더 포
함하는 방법.
청구항 9
웹 기반 CRM 서비스 환경에서 사용자 데이터로의 액세스에 대한 제3자 제공자의 요청들을 안전하게 처리하는 시
스템으로서,
적어도 하나의 CRM 웹 서버를 포함하고,
상기 적어도 하나의 CRM 웹 서버는
제3자 제공자로부터 액세스에 대한 요청을 수신하고- 상기 요청은 상기 웹 기반 CRM 서비스의 프로세스를 보완
하는 서브 프로세스와 연관됨 -;
상기 요청으로부터 티켓을 추출하고- 상기 티켓은 상기 제3자 제공자의 도메인 이름과 연관되고, 만료
파라미터, 제한 역할 파라미터 및 키 표시기를 포함하고, 상기 키 표시기는 복수의 순환 키 중 상기 티켓에 사
용할 순환 키를 나타내고, 상기 복수의 순환 키 각각은 소정의 기간 이후 만료됨-;
상기 티켓이 만료되지 않았음을 확인하고;
상기 티켓으로부터 상기 제3자 제공자의 제한 역할들의 목록을 검색하고- 상기 제한 역할들은 로컬 범위(local
scope) 및 현재의 비즈니스 유닛의 범위를 지정하는 허가를 승인하도록 정의됨 -;
상기 서브 프로세스와 연관된 사용자 역할을 로드(load)하고;
HMAC(Hash Message Authentication Code)를 이용하여 상기 티켓을 인증하고;
상기 티켓의 HMAC에 비트를 추가하고;
상기 티켓의 HMAC에 비트를 추가하는 것에 응답하여, 상기 티켓을 판독 전용 동작으로 제한하도록 상기 웹 기반
CRM 서비스와 연관된 플랫폼 내에서 쓰기 동작을 차단하고;
접속하는 사용자가 상기 로컬 범위를 지정하는 적어도 하나의 허가를 가지지만 상기 현재의 비즈니스 유닛의 범
위를 지정하는 적어도 하나의 허가를 가지지 않는 경우 상기 접속하는 사용자에 대한 상기 제한 역할들의 상승
을 방지하기 위해, 상기 제한 역할들과 상기 사용자 역할의 교차 부분에 기초하여 상기 요청에 대한 액세스 제
한을 판정하며- 상기 제한 역할들은 이미 승인된 티켓들과는 무관하게 추가, 변경 및 제거됨 -; 및
상기 판정된 액세스 제한에 기초하여 상기 제3자 제공자가 상기 사용자 데이터를 액세스할 수 있게 하도록 구성
되는 시스템.
청구항 10
제9항에 있어서,
각각의 제한 역할 및 상기 사용자 역할은 상기 사용자 데이터에 대한 액세스 허가 레벨을 정의하는 권한 깊이
등록특허 10-1486613
- 4 -
(privilege depth)를 포함하고, 상기 액세스 제한은 교차된 역할들의 상기 권한 깊이들 중 더 제한적인 것을 선
택함으로써 판정되는 시스템.
청구항 11
제10항에 있어서,
상기 CRM 웹 서버는 상기 제한 역할들 및 상기 사용자 역할의 상기 권한 깊이들을 구성하기 위한 그래픽 사용자
인터페이스(GUI)를 제공하도록 더 구성되는 시스템.
청구항 12
제9항에 있어서,
상기 서브 프로세스와 연관된 사용자 역할에 할당된 제한들은 상기 웹 기반 CRM 서비스의 클라이언트 조직의 계
층적 구조에 기초하여 정의되는 시스템.
청구항 13
컴퓨팅 장치에 의해 실행되는 경우, 웹 기반 서비스 환경에서 사용자 데이터로의 액세스에 대한 제3자 제공자의
요청들을 안전하게 처리하는 방법을 수행하기 위한 명령어들이 저장되어 있는 컴퓨터 판독가능 저장 장치로서,
상기 방법은,
제3자 제공자로부터 액세스에 대한 요청을 수신하는 단계- 상기 요청은 상기 웹 기반 서비스의 프로세스를 보완
하는 서브 프로세스와 연관됨 -;
상기 요청으로부터 티켓 및 요구(claim)를 추출하는 단계- 상기 티켓은 상기 제3자 제공자의 도메인 이름과 연
관되고, 만료 파라미터, 상기 제3자 제공자의 제한 역할(restriction role), HMAC(Hash Message
Authentication Code), 반복 파라미터, 키 표시기(key indicator) 및 조직 식별자를 포함하고, 상기 제한 역할
은 로컬 범위(local scope) 및 현재의 비즈니스 유닛의 범위를 지정하는 허가를 승인하도록 정의되고, 상기 키
표시기는 복수의 순환 키 중 상기 티켓에 사용할 순환 키를 나타내고, 상기 복수의 순환 키 각각은 소정의 기간
이후 만료되며, 상기 조직 식별자는 상기 HMAC에서 동일한 사용자 식별이 재사용되는 적어도 하나의 조직상호간
공격을 방지하기 위해 사용됨 -;
상기 HMAC를 이용하여 상기 티켓을 인증하는 단계;
상기 티켓의 HMAC에 비트를 추가하는 단계;
상기 티켓의 HMAC에 비트를 추가하는 단계에 응답하여, 상기 티켓을 판독 전용 동작으로 제한하도록 상기 웹 기
반 서비스와 연관된 플랫폼 내에서 쓰기 동작을 차단하는 단계;
상기 티켓이 만료되지 않았음을 확인하는 단계;
상기 티켓과 연관된 적어도 하나의 사용자 역할을 로드하는 단계;
접속하는 사용자가 상기 로컬 범위를 지정하는 적어도 하나의 허가를 가지지만 상기 현재의 비즈니스 유닛의 범
위를 지정하는 적어도 하나의 허가를 가지지 않는 경우 상기 접속하는 사용자에 대한 상기 제한 역할의 상승을
방지하기 위해, 상기 제한 역할과 상기 적어도 하나의 사용자 역할의 교차 부분에 기초하여 상기 요청에 대한
액세스 제한을 판정하는 단계- 상기 제한 역할은 이미 승인된 티켓들과는 무관하게 추가, 변경 및 제거됨 -; 및
상기 판정된 액세스 제한에 기초하여 상기 제3자 제공자가 상기 사용자 데이터를 액세스할 수 있게 하는 단계
를 포함하는 컴퓨터 판독가능 저장 장치.
청구항 14
제13항에 있어서,
상기 제한 역할과 상기 적어도 하나의 사용자 역할의 교차 부분은 상기 제한 역할과 상기 적어도 하나의 사용자
역할 중 더 제한적인 것을 나타내며, 미리 정의된 규칙을 적용하는 것인 컴퓨터 판독가능 저장 장치.
등록특허 10-1486613
- 5 -
청구항 15
제13항에 있어서,
상기 액세스는, 새로운 레코드의 작성, 기존의 레코드의 삭제, 기존의 레코드의 수정, 기존의 레코드의 갱신,
상기 서브 프로세스의 실행과 연관된 동작 파라미터들의 검색, 및 상기 사용자 데이터와 연관된 스키마의 수정
으로 구성된 집합으로부터의 적어도 하나를 포함하는 컴퓨터 판독가능 저장 장치.
청구항 16
삭제
청구항 17
삭제
청구항 18
삭제
청구항 19
삭제
청구항 20
삭제
명 세 서
기 술 분 야
본 발명은 전송 가능한 제한된 보안 토큰에 관한 것이다.[0001]
배 경 기 술
웹 기반 서비스는 서비스 제공자, 그 사용자 및 제3자 사이의 상호작용을 포함하는데, 제3자는 특정 서비스의[0002]
제공을 위해 통합 콘텐츠와 같은 보완적인 서비스를 제공할 수 있다. 이러한 통합 콘텐츠는 내장형 프레임, 폼
(form) 또는 스크립트의 형태를 취할 수 있다. 예를 들어, 비즈니스 레코드 서비스는 사용자의 비즈니스 연락
처에 기초하여 사용자를 위한 각종 프로세스를 실행할 수 있다(예를 들어, 이력 데이터 수집, 통계 분석, 이벤
트 일정 잡기 등). 한편, 사용자 및/또는 서비스 제공자가 지정한 제3자는 레코드 상의 주소에 기초하여 비즈
니스 연락처에 대한 맵을 제공하는 것과 같이, 제공된 서비스를 보완하는 서브 프로세스를 실행할 수 있다.
고객 관계 관리(Customer Relationship Management: CRM) 솔루션은 통상적으로 호스팅된 컴퓨터 애플리케이션[0003]
환경에서, 구매 및 사후 판매를 통한 첫 번째 접촉으로부터 고객에 관해 명확하게 작성하고 유지하는데 필요한
도구 및 능력을 제공하는 웹 기반 비즈니스 서비스의 한 예이다. 복잡한 조직의 경우에, CRM 시스템은 판매 및
마케팅 조직이 새로운 고객을 대상으로 하고, 마케팅 캠페인을 관리하며, 판매 활동을 해나가는 방식을 개선하
는 것을 돕는 기능 및 능력을 제공할 수 있다. CRM 시스템은 다수의 컴포넌트, 하드웨어 및 소프트웨어를 포함
할 수 있는데, 이들은 제3자 제공자뿐만 아니라 조직의 내부 또는 외부 사용자에 의해 개별적으로 또는 공유 방
식으로 이용된다.
서브 프로세스를 실행하기 위해, 제3자는 통상적으로 서비스 제공자 측에 있는 사용자의 레코드로 액세스할 필[0004]
요가 있다. 상기 예에서, 제3자는 맵을 생성하고 그 맵을 서비스 제공자의 웹페이지(들) 내로 통합하기 위해
비즈니스 연락처의 주소를 액세스할 필요가 있을 것이다. 데이터를 읽고, 수정하며, 작성하고, 삭제하기 위해
사용자 데이터로의 액세스를 제공하는 것은 특히 제3자 제공자가 신뢰성 있는 엔티티가 아닌 경우에 보안 문제
를 일으킬 수 있다.
발명의 내용
등록특허 10-1486613
- 6 -
과제의 해결 수단
<요약>[0005]
이 요약은 아래의 상세한 설명에서 더욱 설명되는 개념들의 선택된 개념을 단순화된 형태로 소개하기 위해 제공[0006]
된다. 이 요약은 청구된 주제의 중요한 특징이나 본질적인 특징을 식별하고자 하는 것도 아니고, 청구된 주제
의 범위를 판정하는데 보조적으로 사용되고자 하는 것도 아니다.
실시예는 사용자 데이터로의 제3자 제공자의 액세스를 전송 가능한 제한된 보안 토큰으로 제어함으로써 웹 기반[0007]
서비스 제공자 측의 사용자 레코드의 향상된 보안을 제공하는 것에 관한 것이다. 전송 가능한 제한된 보안 토
큰은 사용자에게 할당된 것 이외의 보안 제한 및 티켓 만료를 갖는 티켓의 형태로 생성된다.
이들 및 다른 특징 및 장점은 다음의 상세한 설명을 읽어보고 관련된 도면을 검토해보면 명백할 것이다. 상기[0008]
일반적인 설명 및 다음의 상세한 설명은 단지 설명을 위한 것일 뿐이고, 실시양상을 주장대로 제한하고자 하는
것이 아니라는 것을 이해할 것이다.
도면의 간단한 설명
도 1은 웹 기반 서비스의 사용자, 서비스 제공자 및 제3자 제공자 사이의 통상적인 데이터 액세스 상호작용을[0009]
도시한 도면.
도 2는 실시예에 따른 웹 기반 서비스의 사용자, 서비스 제공자 및 제3자 제공자 사이의 예시적인 상호작용을
도시한 도면.
도 3은 웹 기반 서비스의 제3자 제공자에게 할당될 보안 제한 판정시의 사용자 및 제한 역할의 사용을 도시한
개념도.
도 4는 웹 기반 서비스의 사용자에게 액세스 제한을 할당하는 소프트웨어 프로그램의 스크린 샷.
도 5는 웹 기반 서비스의 제3자 제공자에게 액세스 제한을 할당하는 소프트웨어 프로그램의 스크린 샷.
도 6은 실시예에 따른 3가지 예시적인 제한된 보안 티켓을 도시한 도면.
도 7은 실시예가 구현될 수 있는 예시적인 네트워크 환경의 도면.
도 8은 실시예가 구현될 수 있는 예시적인 컴퓨팅 운영 환경의 블록도.
도 9는 웹 기반 서비스에서 제3자 제공자에 의한 사용자 데이터로의 액세스를 허용하기 위해 제한된 보안 티켓
을 사용하는 프로세스의 논리 흐름도를 도시한 도면.
발명을 실시하기 위한 구체적인 내용
위에서 간략하게 설명한 바와 같이, 웹 기반 서비스에서의 사용자 데이터 보안은 제3자 제공자에 의한 데이터로[0010]
의 액세스를 허용하기 위해 제한된 보안 티켓을 사용함으로써 향상될 수 있다. 다음의 상세한 설명에서, 이 문
서의 일부를 이루고, 특정 실시예 또는 예가 예시적으로 도시된 첨부 도면이 참조된다. 본 발명의 정신 또는
범위를 벗어나지 않고서, 이들 실시양상이 결합될 수 있고, 그외 다른 실시양상이 이용될 수 있으며, 구조적 변
경이 행해질 수 있다. 그러므로, 다음의 상세한 설명은 제한적인 의미로 해석되어서는 안 되고, 본 발명의 범
위는 첨부된 청구범위 및 그 등가물에 의해 정의된다.
실시예가 퍼스널 컴퓨터의 운영 체제에서 실행되는 애플리케이션 프로그램과 함께 실행되는 프로그램 모듈과 일[0011]
반적으로 관련하여 설명되지만, 본 분야에 숙련된 기술자들은 실시양상이 또한 그외 다른 프로그램 모듈과 결합
하여 구현될 수 있다는 것을 인식할 것이다.
일반적으로, 프로그램 모듈은 특정 작업을 수행하고 및/또는 특정 추상 데이터 유형을 구현하는 루틴,[0012]
프로그램, 컴포넌트, 데이터 구조 및 그외 다른 유형의 구조를 포함한다. 더구나, 본 분야에 숙련된 기술자들
은 실시예가 핸드헬드 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 또는 프로그램가능 소비자 전자제품,
미니 컴퓨터, 메인프레임 컴퓨터 등을 포함하는 기타 컴퓨터 시스템 구성으로 실시될 수 있다는 것을 이해할 것
이다. 실시예는 또한 통신 네트워크를 통해 연결되는 원격 처리 장치에 의해 작업이 수행되는 분산 컴퓨팅 환
경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치 둘 다에 위치
할 수 있다.
등록특허 10-1486613
- 7 -
실시예는 컴퓨터 프로세스(방법)나 컴퓨팅 시스템으로서, 또는 컴퓨터 프로그램 제품 또는 컴퓨터 판독가능 매[0013]
체와 같은 제조품으로서 구현될 수 있다. 컴퓨터 프로그램 제품은 컴퓨터 시스템에 의해 판독 가능하고, 컴퓨
터 프로세스를 실행하는 명령어의 컴퓨터 프로그램을 인코딩한 컴퓨터 저장 매체일 수 있다. 컴퓨터 프로그램
제품은 또한 컴퓨터 시스템에 의해 판독 가능하고, 컴퓨터 프로세스를 실행하는 명령어의 컴퓨터 프로그램을 인
코딩한 반송파 상의 전파 신호일 수 있다.
도 1을 참조하면, 웹 기반 서비스의 사용자, 서비스 제공자 및 제3자 제공자 사이의 통상적인 데이터 액세스 상[0014]
호작용의 도면이 도시된다.
앞에서 설명된 바와 같이, 제3자 제공자는 사용자를 위한 서비스의 웹 서비스 보완 프로세스 내의 서브 프로세[0015]
스를 실행할 수 있다. 앞에서 설명된 한 예는 사용자를 위한 연락처를 처리하는 연락처 맵을 웹 기반 서비스에
제공하는 제3자이다. 다른 예는 CRM 시스템 내의 신용 점수를 계산하는 제3자 서비스이다. CRM 연락처 폼은
제3자를 불러들여 연락처 식별자를 전달하는 스크립트를 실행하도록 사용자 지정될 수 있다. 그 다음, 제3자는
선택된 연락처에 대한 신용 점수를 계산하고자 다양한 연락처 및 주문 정보를 검색하기 위해 CRM 서비스를 다시
불러들일 수 있다. 제3자는 연락처 폼의 필드에 표시될 수 있는 신용 등급 점수를 되돌려 보낼 수 있다. 제3
자는 또한 연락처 레코드를 기타 유용한 통계치로 직접 갱신할 수 있다.
그러므로, 제3자 제공자는 수집, 수정, 삭제 또는 작성 동작을 위해 웹 기반 시스템 내의 사용자 데이터에 액세[0016]
스할 필요가 있을 수 있다. 이러한 제3자 동작을 수용하는데 있어서의 도전과제는 어떤 제3자가 어떤 허가 레
벨에서 얼마의 기간 동안 등등 이들 동작에 대해 허용될 것인지 제어하는 방법을 포함한다.
종래의 웹 기반 서비스 환경에서, 도 1의 도면(100)에 도시된 바와 같이, 각 사용자(102)는 웹 기반 서비스[0017]
(104) 내에서 할당된 보안 역할을 가질 수 있고, 그 역할에 의해 허용된 서비스를 액세스한다. 사용자(102)는
어떤 시점에서, 예를 들어 제3자 서비스(106)에 자신의 보안 티켓을 제공함으로써 제3자 서비스(106)에 동작을
실행하도록 권한을 부여할 수 있다. 그 경우에, 제3자 서비스(106)는 그 사용자의 보안 역할에 의해 허용된 것
과 같은 사용자(102)와 관련된 모든 데이터로 완전히 액세스하여 그 동작을 실행할 수 있다. 이러한 설정의 단
점은 사용자가 사용자 자신이 갖고 있는 모든 데이터로의 완전한 액세스 능력을 제3자가 갖기를 바랄 수 없다는
것이다.
일을 더욱 복잡하게 하기 위해, 조직은 다양한 보안 역할을 갖는 다수의 내부 사용자를 가질 수 있다. 그들 중[0018]
의 한 명이 제3자에게 권한을 부여할 경우에, 그 사용자의 보안 역할은 필요한 동작을 실행하기에 적당하지 않
을 수 있고, 또는 오히려 원하는 것보다 더 넓어질 수 있다. 예를 들어, 회사의 접수계원은 비즈니스 연락처
정보로의 "읽기" 전용과 같은 제한된 액세스를 가질 수 있다. 그 접수계원이 신용 점수를 계산하는 제3자 서비
스를 활성화하려고 하는 경우에, 제3자는 접수계원의 제한된 보안 역할로 인해 웹 서비스에서 데이터를 갱신하
지 못할 수 있다.
한편, 넓은 액세스 권한을 가진 고위급 매니저는 통상적으로 제3자에게 제한된 액세스 권한을 요구할 수 있는[0019]
비즈니스 연락처에 대한 맵 서비스를 활성화하고 싶어할 수 있다. 그러나, 매니저가 넓은 액세스 권한을 갖기
때문에, 제3자는 필요하든 안 하든 매니저의 보안 티켓을 통해 동일한 권한을 얻을 수 있다.
사용자 데이터로의 제3자 액세스를 제어하는 다른 방법은 제3자 서비스 제공자에게 웹 서비스에서의 제한된 보[0020]
안 역할을 할당하는 것일 수 있지만, 그것은 사용자가 자신이 선택한 제3자 서비스를 사용할 수 있게 하기 위한
웹 기반 서비스의 유연성을 심하게 제한하여, 사용자 서비스의 사용자 지정을 매우 어려운 작업이 되게 할 수
있다.
도 2는 실시예에 따른 웹 기반 서비스의 사용자, 서비스 제공자 및 제3자 제공자 사이의 예시적인 상호작용을[0021]
도시한 것이다.
위에서 설명된 바와 같이, 웹 기반 서비스 제공자에 대한 도전과제는 어떤 제3자가 어떤 허가 레벨로 어떤 정확[0022]
한 기간 동안 서비스를 다시 불러들이도록 허용될 것인지 제어하는 방법이다. 예를 들어, 서비스 관리자가 CRM
서비스 내의 연락처 폼을 보고 있는 경우에, 접속하는 사용자의 전체 보안 컨텍스트를 중간 정도 신뢰할 수 있
는 제3자에게 전송하는 것은 제3자가 의도한 서비스를 실행하기 위해 실제로 필요한 것 이상으로 레코드를 이제
액세스할 수 있다는 것을 의미할 수 있다. 관리자는 임의 유형의 레코드를 삭제하거나, 임의 유형의 레코드를
작성하거나, 또는 스키마 변경을 하도록(예를 들어, 새로운 엔티티, 특성 등을 작성하도록) 권한이 부여될 수
있다. 접속하는 사용자의 전체 보안 컨텍스트를, 단지 좁은 특정 서비스 집합을 제공하리라고 예상된 중간 정
도 신뢰할 수 있는 제3자에게 전송하는 것은 심각한 위험을 초래할 수 있다.
등록특허 10-1486613
- 8 -
실시예에 따르면, 티켓은 제3자 제공자를 위해 생성될 수 있다. 티켓은 추가 보안 제한 및 티켓 만료를 지정할[0023]
수 있다. 추가 보안 제한은 웹 기반 서비스 역할 인프라를 사용하여 정의될 수 있다. 이때, 제3자 제공자의
특정 도메인 이름은 제한 역할과 관련될 수 있다. 예를 들어, 제한 역할은 제3자 도메인
"http://accuratecreditinfo.com"에 [로컬 범위를 갖는 활동 읽기 권한] [현재의 비즈니스 유닛의 범위를 갖
는 리드(lead) 작성 및 읽기 권한]을 부여하기 위해 정의될 수 있다. 그러나, 접속하는 사용자가 리드를 작성
하는 권한이 없는 경우에, 보안은 권한 상승을 확실하게 없게 하기 위해, 접속하는 사용자(및 그 역할)에 대한
권한을 제한 역할에 의해 정의된 권한과 교차시킴으로써 평가될 수 있다. 제한 역할은 또한 현재의 비즈니스
유닛의 범위를 지정할 수 있다.
도면(200)에서, 웹 기반 서비스는 사용자(202)를 위한 사용자 특정 프로세스(들)(210)를 실행하는 서버(204)로[0024]
표시된다. 티켓 확인 프로세스(208)는 사용자를 인증하고 그 액세스 권한을 판정하기 위해 이용될 수 있다.
인증 정보는 티켓 내에 포함될 수 있다. 실시예에 따른 서비스에서, 제3자 서비스(206)는 사용자 특정 프로세
스(210)를 보완하기 위한 서브 프로세스(212)를 실행할 수 있다. 웹 기반 서비스에서의 사용자 데이터 및 주문
을 액세스하기 위해, 제3자 서비스(206)는 제한된 보안 티켓(218)을 웹 기반 서비스(204)에 제공할 수 있다.
제3자 서비스(206)는 또한 기타 시스템(214)과 상호작용할 수 있다.
제한된 보안 티켓(218)은 또한 웹 기반 서비스에 의해 인증될 수 있다. 인증은 다수의 방식을 통해 실행될 수[0025]
있다. 한가지 이러한 방법은 해시 메시지 인증 코드(HMAC)이다. "MAC 태그"는 공격자가 유효 쌍(메시지,
태그)을 생성하기 곤란하도록, 메시지(이 경우에 티켓) 내에 포함된 비밀 키에 기초하여 생성된다.
HMAC 대신에, 디지털 서명이 또한 다른 실시예에 따라 사용될 수 있다. 디지털 서명으로, 컴포넌트는 요구를[0026]
확인할 수는 있지만, 유효 티켓을 생성하는 능력은 없을 수 있다(검증 키만이 컴포넌트에 사용가능할 수 있다).
HMAC로, 컴포넌트는 요구를 확인할 수 있지만, 이때, 이 컴포넌트들은 요구된 대칭 키로의 액세스를 갖기 때문
에 유효 티켓을 생성하는 능력도 갖는다. 디지털 서명의 사용은 추가 위임을 허용하는데 유용할 수 있다. 예
를 들어, 제3자는 웹 기반 서비스 티켓을 다른 제3자에게 전송할 수 있는데, 다른 제3자는 특정 동작을 취하기
전에 웹 기반 서비스로의 액세스를 확인할 수 있다. 그외 다른 인증 방법이 또한 여기에 설명된 원리를 사용하
여 이용될 수 있다.
그러므로, 예시적인 티켓은 다음과 같은 형태로 된다: {UserId Expiration RestrictionRoleIds [0027]
HMAC(UserId Expiration RestrictionRoleIds)}. 티켓은 또한 (각각이 소정 시간 후에 만료되는 순환 키가
사용되는 경우에, 어떤 키를 사용하는지 알기 위한) 키 표시기 및 (동일한 UserId가 재사용될 수 있는 경우에
조직상호간의 공격을 방지하기 위한) 조직 Id를 포함할 수 있다.
다른 실시예에 따르면, 웹 기반 서비스 관리자는 티켓이 읽기 전용 동작과 같은 특정 동작에 제한되어야 한다는[0028]
것을 지정할 수 있게 될 수 있다. 이것은, 예를 들어 티켓의 HMAC에 한 비트를 추가한 다음에 플랫폼 내의 쓰
기 동작을 차단함으로써 달성될 수 있다.
다른 실시예에 따르면, 제한된 사용자/도메인은 티켓 내에 제한된 역할의 목록을 포함하는 대신에 시스템 내에[0029]
작성될 수 있다. 제한된 사용자/도메인은 그들에게 관련된 역할을 가질 수 있고, 이들 역할은 제한된 역할로서
사용될 수 있다. 사용자 역할과 제한된 역할의 교차는 위에서 설명된 바와 같이 판정될 수 있다. 이 시나리오
에서, 티켓은 {UserId Expiration RestrictedUserId HMAC(UserId Expiration RestrictedUserId)}의
형태로 될 수 있다.
제한된 티켓이 역할 목록을 포함하는 버전에서, 도메인에 관련된 역할은 바뀌었을 수 있지만, 보안 제한은 역할[0030]
내의 권한이 독립적으로 변경될 수 있을지라도, 티켓 내의 역할 집합에 기초한다. 제한된 사용자/도메인 방법
에서, 서버는 제한된 역할의 제어를 유지한다. 그러므로, 단지 제한된 도메인/사용자를 갖는 버전에서의 역할
은 이미 부여된 티켓에 무관하게 추가/변경/제거될 수 있다.
변경될 가능성이 있는 사용자 권한을 동적으로 다시 평가하고, 제3자에 의해 사용된 적이 없는 티켓을 처리하지[0031]
않는(시스템 자원을 절약하는) 장점을 갖는 하나의 실시예에 따라 티켓이 웹 서비스(예를 들어, CRM 서비스)로
부터 돌아오지 않을 때 권한 교차가 실행될 수 있지만, 이와 동일한 교차는 또한 여기에 설명된 원리를 사용하
여 티켓이 처음 발급될 때 실행될 수 있다.
도 3은 웹 기반 서비스의 제3자 제공자에게 할당될 보안 제한을 판정할 때의 사용자 및 제한 역할의 사용을 도[0032]
시한 개념도이다.
등록특허 10-1486613
- 9 -
역할 기반의 액세스 권한 시스템에서, 권한 깊이는 레코드에 대한 사용자의 관계에 기초하여 다양한 레벨에서[0033]
정의될 수 있다. 예를 들어, "기본" 깊이는 사용자에 의해 소유된 레코드에 대해 정의될 수 있고; "로컬" 깊이
는 사용자가 속하는 비즈니스 유닛의 레코드에 대해 정의될 수 있으며; "깊은" 깊이는 사용자의 비즈니스 유닛
또는 임의의 자식 비즈니스 유닛의 레코드에 대해 정의될 수 있고; "글로벌" 깊이는 포괄적인 조직의 임의의 비
즈니스 유닛 내의 레코드에 대해 정의될 수 있다.
이러한 예시적인 권한 깊이에 기초하여, 사용자는 기본 깊이를 갖는 "활동 읽기"; 깊은 깊이를 갖는 "리드[0034]
쓰기"; 및 깊은 깊이를 갖는 "연락처 작성"으로서 정의된 단일 역할이 할당될 있다. 제3자 제공자는 로컬 깊이
를 갖는 "리드 쓰기" 및 글로벌 깊이를 갖는 "연락처 작성"으로서 정의된 단일 역할이 할당될 수 있다.
실시예에 따른 서비스에서, 이들 역할(예를 들어, 제한 역할(324) 및 제한 역할(326)과 사용자 역할(322))의 교[0035]
차부분(320)은 로컬 깊이를 갖는 "리드 쓰기" 역할 및 깊은 깊이를 갖는 "연락처 작성" 역할을 초래할 수 있다
(좀 더 작은 깊이가 이 경우에 선택된다).
위의 제한 역할, 권한 깊이 및 교차 시나리오는 단지 예시적으로 제공된 것일 뿐이고, 실시예를 제한하는 것이[0036]
아니다. 실시예는 임의의 정의된 권한 깊이, 조직적 구조 및 제한 역할을 사용하여 구현될 수 있다. 더욱이,
추가 역할은 2개의 제한 중의 더 작은 제한을 초과하는 제한 역할과 사용자 역할의 교차를 판정하기 위해 정의
될 수 있다. 더구나, CRM 서비스는 예시적인 웹 기반 서비스로서 여기에서 사용된다. 실시예는 여기에 설명된
원리를 사용하여 임의의 애플리케이션 보안 제한으로 구현될 수 있다.
도 4는 웹 기반 서비스의 사용자에게 액세스 제한을 할당하는 소프트웨어 프로그램의 스크린 샷(400)이다.[0037]
위에서 설명된 바와 같이, 보안 역할은 다양한 액세스 허가 레벨을 갖는 조직의 각 사용자에게 할당될 수 있다.[0038]
예를 들어, 웹 서비스 프로그램의 액세스 관리 모듈은 스크린 샷에 나타낸 바와 같이 관리자가 각 사용자에 대
한 보안 역할을 정의할 수 있게 할 수 있다. 예시적인 역할은 접수계원(432)에 대해 작성되고 있다. 계정, 연
락처, 이메일 템플릿 등과 같은 상이한 유형의 레코드는 열(434)에 열거된다. 작성, 판독, 기입, 삭제 등과 같
은 액세스 동작(438)은 대응하는 열에 열거되어, 관리자가 매트릭스(430) 내의 각 유형의 레코드 상에 각 동작
에 대한 허가 레벨을 설정할 수 있게 한다.
사용자 인터페이스는 레코드가 탭(436)에 의해 표시된 바와 같이 조직적 세분화를 위해 그룹화되도록 설정될 수[0039]
있다. 보안 역할은 사용자에 의해 할당되어 웹 기반 서비스에 전송되거나, 웹 기반 서비스에 의해 생성된 기본
역할의 템플릿 상에서 사용자에 의해 수정되거나, 또는 웹 기반 서비스의 관리 프로그램의 구성 모드에서 사용
자에 의해 할당될 수 있다.
도 5는 웹 기반 서비스의 제3자 제공자에게 액세스 제한을 할당하는 소프트웨어 프로그램의 스크린 샷이다. 제[0040]
3자 제공자는 웹 기반 서비스를 보완하는 여러 가지 작업을 실행할 수 있다. 스크린 샷(500)에 도시된 예시적
인 프로세스는 연락처 분석이다.
스크린 샷(500) 내의 구성 사용자 인터페이스는 도 4의 것과 유사한데, 레코드 유형(544)은 매트릭스의 제1 열[0041]
에 열거되고, 액세스 유형은 제1 행(548)에 열거된다. 각 레코드 유형 및 액세스 유형에 대한 액세스의 제한은
사용자 인터페이스 매트릭스(500)의 요소로서 도시된다. 실시예에 따른 사용자 인터페이스는 중요하게, 파트너
액세스 제한을 가능하게 하는 컨트롤을 포함하는데, 파트너는 제3자 제공자와 관련된 URL에 의해 정의된다.
더욱이, 제한은 또한 조직 계층 구조에 기초하여 판정될 수 있다. 예를 들어, 제한 역할은 제3자 서비스가 개[0042]
별 사용자, 비즈니스 유닛, 비즈니스 서브 유닛 또는 전체 조직에 대해 실행되고 있는지의 여부에 기초하여 정
의될 수 있다.
도 6은 실시예에 따른 3가지 예시적인 제한된 보안 티켓을 도시한 것이다. 실시예에 따른 제한된 보안 티켓은[0043]
도면에 도시된 것들 이외의 요소를 포함할 수 있다. 만료 및 제한은 또한 도시된 예에 제한되지 않는다.
앞에서 설명된 바와 같이, 제3자에 대한 역할 제한은 웹 기반 서비스 내의 특정 도메인 이름과 관련될 수 있다.[0044]
제1의 예시적인 티켓(652)은 도메인 이름 http://accuratecreditinfo.com(허구적 도메인 이름)과 관련된다.
티켓은 60초의 만료 및 연락처 분석 역할 전용의 제한을 갖는다. 그러므로, 티켓(652)이 할당된 제3자는 일단
티켓이 수락되면 그 프로세스를 실행하기 위해 60초를 갖고, 단지 연락처 분석을 실행하기 위해 웹 기반 서비스
에서의 사용자 데이터를 액세스할 수 있다.
제2 티켓(654)은 특정 비즈니스의 제품 이미지를 처리하는 제3자 제공자 서비스일 수 있는 도메인 이름[0045]
http://productimages.com과 관련된다. 티켓은 10초의 만료 기간을 갖고, 제한은 제한된 제품 액세스
등록특허 10-1486613
- 10 -
역할이다. 이 역할은 웹 기반 서비스의 액세스 관리 부분에서 정의될 수 있다. 만료 및 제한 이외에, 티켓
(654)은 선택적으로 반복 파라미터를 포함할 수 있다. 반복 파라미터는 제3자 제공자가 반복 파라미터의 값에
기초하여 그들의 보안 티켓을 반복적으로 사용할 수 있게 할 수 있다. 도 6의 예에서, 반복 파라미터는 "없
음"으로 설정되는데, 이것은 티켓이 단일 사용 티켓이라는 것을 의미한다.
예시적인 티켓(656)은 CRM 서비스에 비즈니스 리드의 분석을 제공할 수 있는 도메인 이름[0046]
http://analyzeleads.com과 관련된다. 티켓의 만료는 60분으로 설정되고, 제한은 "모든 리드 읽기"이다. 그러
므로, 이 티켓을 가진 제3자는 CRM 서비스 내의 모든 비즈니스 리드 데이터를 읽을 수 있지만, 임의의 추가 액
세스 동작을 실행할 수는 없다. 선택적인 반복 파라미터는 이 경우에 10회로 설정되는데, 이것은 제3자 제공자
가 사용자 데이터를 액세스하기 위해 동일한 티켓을 10회까지 사용할 수 있다는 것을 의미한다.
몇몇 실시예에 따르면, 타임 스탬프 만료는 유효 기간(날짜 및 시간)의 범위를 정하는 만료 기간을 대신하는 것[0047]
과 같은 그외 다른 방식으로 구현될 수 있다. 더욱이, 더욱 복잡한 만료는 비교적 더 유연성 있는 제한을 표현
하기 위해 티켓에 포함될 수 있다. 예를 들어,