KR20160005111A - 기업 시스템들에서 사용자 및 디바이스 인증 - Google Patents

Abstract

기업 시스템들의 자원들 및 서비스들에 대한 액세스를 허용하기 위하여 클라이언트 디바이스들의 사용자들을 인증하기 위한 방법들 및 시스템들이 본원에서 설명된다. 인증 디바이스는 클라이언트 디바이스로부터 수신된 인증 크리덴셜들에 기초하여 사용자를 검증할 수 있다. 인증 디바이스에 의해 저장된 검증 데이터 및 클라이언트 디바이스에 전송되는 대응하는 액세스 토큰은 미래의 자원 액세스 요청들에 대해 사용자를 인증하기 위하여 사용될 수 있다. 사용자 시크릿은 또한 인증 디바이스에 의해 저장될 수 있고, 미래의 자원 액세스 요청들에 대하여 사용자를 검증하기 위하여 사용될 수 있다. 부가적으로, 인증 크리덴셜들의 제 1 세트를 사용하여 사용자를 검증한 이후에, 사용자에 대한 크리덴셜들의 추가 세트들은 리트리브될 수 있으며, 미래의 요청들이 기업 시스템의 다른 서비스들 또는 자원들에 액세스하도록 액세스 게이트웨이에 저장될 수 있다.

Description

기업 시스템들에서 사용자 및 디바이스 인증{USER AND DEVICE AUTHENTICATION IN ENTERPRISE SYSTEMS}

[1] 본 출원은 "USER AND DEVICE AUTHENTICATION IN ENTERPRISE SYSTEMS"라는 명칭으로 2013년 5월 3일에 출원된 미국 출원번호 제13/886,518호의 우선권을 주장한다.

[2] 본원에서 설명된 양상들은 일반적으로 기업 시스템들내에서 사용자들의 인증에 관한 것이다. 특히, 본원의 특정 양상들은 기업 시스템들내의 다양한 자원들 및 서비스들에 대해 모바일 디바이스들 및 다른 클라이언트 디바이스들로 사용자들을 보안 인증하는 접근법들을 제공한다.

[3] 모바일 디바이스들, 예컨대 스마트폰들, 개인 휴대 단말들, 태블릿 컴퓨터들, 다른 타입들의 모바일 컴퓨팅 디바이스들은 인기가 점점 더 증가하고 있다. 모바일 디바이스들은 다양한 목적들로 인해 개인 세팅 및 비지니스 세팅에서 사용된다. 부가적으로, 많은 사람들은 하나 이상의 모바일 디바이스들을 비롯하여 다수의 컴퓨팅 디바이스들을 가진다. 사용자의 상이한 디바이스들은 상이한 위치들에 있을 수 있으며, 상이한 물리적 디바이스 능력들을 가질 수 있다. 예컨대, 사용자는 표준 키보드 및 마우스 인터페이스를 가진 데스크탑 컴퓨터, 터치 스크린 인터페이스 및 음성 인식 능력들을 가진 모바일 디바이스, 지문 스캐너 인터페이스를 가진 랩탑 컴퓨터 등을 가질 수 있다.

[4] 다수의 컴퓨팅 디바이스들을 가진 사용자들은 자신들의 디바이스들 중 임의의 디바이스를 사용하여 동일한 데이터, 애플리케이션들 및 다른 정보에 액세스하기를 원할 수 있다. 클라이언트 디바이스를 통해 데이터 및 애플리케이션들에 원격적으로 액세스하기 위하여, 사용자는 인증 서비스 및/또는 데이터 및 애플리케이션들을 제공하는 원격 자원 또는 서비스에 의해 먼저 인증될 수 있다. 통상적으로, 사용자는 자신들의 아이덴티티를 검증하여 기업 시스템의 원격 자원들 또는 서비스들에 액세스하기 위하여 인증 크리덴셜들, 예컨대 사용자 이름 및 패스워드를 자신들의 디바이스에 입력한다. 예컨대 통신 세션들 동안 또는 새로운 세션의 시작시에 주기적으로 재인증하는 것이 사용자들에게 요구될 수 있다. 부가적으로, 단일 사용자는 상이한 원격 자원들 또는 서비스들에 대한 인증 크리덴셜들의 상이한 세트들을 가질 수 있다.

[5] 하기의 설명은 본원에 설명된 다양한 양상들의 간략화된 요약을 제시한다. 이러한 요약은 포괄적인 개요가 아니며, 중요하거나 핵심적인 엘리먼트들을 식별하거나, 청구항들의 범위를 서술하고자 할 의도도 아니다. 하기의 요약은 단순히 아래에서 제공되는 상세한 설명에 대한 도입부로서 간략화된 형태로 일부 개념들을 제시한다.

[6] 앞서 설명된 종래기술의 한계들을 극복하고 본 명세서를 읽고 이해할 때 명백하게 될 다른 한계들을 극복하기 위하여, 본원에서 설명된 양상들은 모바일 디바이스들 및 다른 클라이언트 디바이스들로 사용자들을 보안 인증하고 기업 시스템들의 다양한 자원들 및 서비스들에 대한 액세스를 허용하는 것에 관한 것이다. 특정 양상들에 따르면, 인증 디바이스는 클라이언트 디바이스로부터 패스워드(또는 토큰)를 포함하는 사용자 인증 크리덴셜들을 수신할 수 있다. 사용자는 인증 크리덴셜들로 검증될 수 있으며, 인증 디바이스는 패스워드를 암호화하기 위하여 사용되는 암호 키를 포함하는 액세스 토큰 및 암호화된 사용자 패스워드를 포함하는 검증 데이터를 생성할 수 있다. 검증 데이터는 인증 디바이스에 의해 저장될 수 있으며, 액세스 토큰은 클라이언트 디바이스에 전송될 수 있다. 클라이언트 디바이스로부터의 미래의 자원 액세스 요청들에 대하여, 클라이언트 디바이스는 액세스 토큰을 전송할 수 있으며, 인증 디바이스는 클라이언트 디바이스로부터 수신된 액세스 토큰을 사용하여 검증 데이터를 리트리브하여 암호해독할 수 있다.

[7] 추가 양상들에 따르면, 사용자는 클라이언트 디바이스의 입력 인터페이스를 통해 사용자 시크릿, 예컨대 개인 식별 번호, 터치 스크린 제스처 또는 생체인증 데이터를 입력할 수 있다. 사용자 시크릿은 인증 디바이스에 의해 저장되고 클라이언트 디바이스로부터의 미래의 요청들을 검증하기 위하여 사용될 수 있다. 예컨대, 사용자는 미래의 요청들에 대하여 사용자 시크릿을 재입력할 수 있으며, 인증 디바이스는 동일한 사용자, 디바이스에 대응하는 이전에 저장된 사용자 시크릿 및/또는 요청된 자원들 또는 서비스들과 요청에서의 사용자 시크릿을 비교할 수 있다.

[8] 추가 양상들에 따르면, 인증 크리덴셜들의 제 1 세트로 사용자를 검증한 이후에, 인증 크리덴셜들의 하나 이상의 추가 세트들은 제 1 사용자에 대하여 리트리브될 수 있으며 기업 시스템의 액세스 게이트웨이 또는 다른 스토리지에 저장될 수 있다. 인증 크리덴셜들의 추가 세트들은 기업 시스템의 다양한 서비스들 또는 자원들에 액세스하기 위한 동일한 사용자의 상이한 크리덴셜들에 대응할 수 있다. 클라이언트 디바이스로부터의 미래의 요청들에서, 사용자는 인증 크리덴셜들의 제 1 세트에 기초하여 검증될 수 있고, 이후 인증 크리덴셜들의 추가 세트는 요청된 서비스 또는 자원에 따라 요청에 대해 리트리브되고 삽입될 수 있다.

[9] 이들 및 추가 양상들은 이하에서 더 상세히 논의되는 개시내용들의 장점과 함께 인식될 것이다.

[10] 본원에서 설명된 양상들 및 이의 장점들은 유사한 참조 부호들이 유사한 특징들을 표시하는 첨부 도면들을 고려하여 이하의 상세한 설명을 참조함으로써 더 완전하게 이해될 수 있다.
[11] 도 1은 본원에서 설명된 하나 이상의 예시적인 양상들에 따라 사용될 수 있는 예시적인 컴퓨터 시스템 아키텍처를 도시한다.
[12] 도 2는 본원에서 설명된 하나 이상의 예시적인 양상들에 따라 사용될 수 있는 예시적인 원격-액세스 시스템 아키텍처를 도시한다.
[13] 도 3는 본원에서 설명된 하나 이상의 예시적인 양상들에 따른 예시적인 기업 모빌리티 관리 시스템을 도시한다.
[14] 도 4는 본원에서 설명된 하나 이상의 예시적인 양상들에 따른 다른 예시적인 기업 모빌리티 관리 시스템을 도시한다.
[15] 도 5는 본원에서 설명된 하나 이상의 예시적인 양상들에 따라 클라이언트 디바이스와 인증 디바이스 사이에서 예시적인 사용자 인증 프로세스를 예시하는 흐름도이다.
[16] 도 6은 본원에서 설명된 하나 이상의 예시적인 양상들에 따라, 클라이언트 디바이스와 기업 시스템의 다양한 컴포넌트들 간의 예시적인 사용자 인증과 자원 액세스 요청을 예시하는 흐름도이다.
[17] 도 7a 및 도 7b는 본원에서 설명된 하나 이상의 예시적인 양상들에 따라, 클라이언트 디바이스와 인증 디바이스 간의 인증 프로세스에서 검증 데이터 및 액세스 토큰들을 생성하여 사용하기 위한 예시적인 기술들을 예시하는 다이어그램들이다.

[18] 다양한 실시예들의 이하의 설명에서는 실시예의 일부분을 형성하며, 본원에서 설명된 양상들이 실시될 수 있는 예시적인 다양한 실시예들이 도시되는 앞서 식별된 첨부 도면들을 참조한다. 본원에서 설명된 범위로부터 벗어나지 않고, 다른 실시예들이 활용될 수 있고 구성 및 기능이 수정될 수 있다는 것이 이해되어야 한다. 다양한 양상들은 다른 실시예들을 가능하게 하며 다양한 상이한 방식들로 실시되거나 또는 수행될 수 있다.

[19] 이하에서 상세히 설명된 요지에 대한 총론으로서, 본원에서 설명된 양상들은 모바일 컴퓨팅 디바이스들의 관리 모바일 애플리이션(managed mobile application)들을 사용하여 기업 컴퓨팅 시스템의 자원들에 대한 원격 액세스를 제어하는 것에 관한 것이다. 액세스 관리자는 기업 자원들에 대한 액세스를 요청하는 모바일 애플리케이션이 자체적으로 정확하게 식별되었고 모바일 컴퓨팅 디바이스에 설치된 이후 나중에 변경되지 않았는지의 여부를 결정하는 검증 프로세스(validation process)를 수행할 수 있다. 이러한 방식으로, 액세스 관리자는 기업 자원에 대한 액세스를 요청하는 모바일 애플리케이션이 신뢰성이 있을 수 있고 그 기업 자원들을 보호하기 위하여 사용되는 보안 메커니즘들을 회피하는 것을 시도하지 않음을 보장할 수 있다. 결과적으로, 기업과 연관된 개인들은 자신들의 개인 모바일 디바이스들로 기업 자원들을 유리하게 활용할 수 있다.

[20] 본원에서 사용되는 어법 및 전문용어가 설명을 위한 것이며 제한으로서 간주되지 않아야 한다는 것이 이해되어야 한다. 오히려, 본원에서 사용되는 문구들 및 용어들은 그들의 가장 넓은 해석 및 의미가 부여되어야 한다. "포함하는" 및 "구성하는" 및 이의 변형들의 사용은 이후에 리스트되는 항목들 및 이의 균등물들 뿐만아니라 추가 항목들 및 이의 균등물들을 포함하는 것으로 의미된다. "장착되는", "연결되는", "커플링되는", "포지셔닝되는", "연동되는"이라는 용어들 및 유사한 용어들의 사용은 직접적으로 및 간접적으로 장착하는, 연결하는, 커플링하는, 포지셔닝하는 및 연동하는 것을 포함하는 것으로 의도된다.

[21] 컴퓨팅 아키텍처

[22] 컴퓨터 소프트웨어, 하드웨어 및 네트워크들은 특히 스탠드얼론(standalone), 네트워크화, 원격-액세스(원격 데이크탑으로도 알려짐), 가상화 및/또는 클라우드-기반 환경들을 비롯하여 다양한 상이한 시스템 환경들에서 활용될 수 있다. 도 1은 스탠드얼론 및/또는 네트워크화 환경에서, 본원에서 설명된 하나 이상의 예시적인 양상들을 구현하기 위하여 사용될 수 있는 시스템 아키텍처 및 데이터 프로세싱 디바이스의 일례를 예시한다. 다양한 네트워크 노드들(103, 105, 107 및 109)은 광역 통신망(WAN)(101), 예컨대 인터넷을 통해 상호 연결될 수 있다. 사설 인트라넷들, 기업 네트워크들, LAN들, 도시권 통신망(MAN), 무선 네트워크들, 개인 네트워크(PAN)들 등을 포함하는 다른 네트워크들이 또한 또는 대안적으로 사용될 수 있다. 네트워크(101)는 예시적 목적이며, 더 적은 수의 컴퓨터 네트워크들로 또는 더 많은 수의 컴퓨터 네트워크들로 대체될 수 있다. 근거리 통신망(LAN)은 임의의 공지된 LAN 토폴로지 중 하나 이상을 가질 수 있으며, 이더넷과 같은 다양한 상이한 프로토콜들 중 하나 이상을 사용할 수 있다. 디바이스들(103, 105, 107, 109) 및 다른 디바이스들(도시안됨)은 트위스트 페어 와이어들, 동축 케이블, 광섬유들, 라디오 파들 또는 다른 통신 매체를 통해 네트워크들 중 하나 이상의 네트워크에 연결될 수 있다.

[23] 본원에서 사용되고 도면들에 도시된 바와같은 "네트워크"란 용어는 원격 저장 디바이스들이 하나 이상의 통신 경로들을 통해 함께 커플링되는 시스템들 뿐만아니라 가끔씩 저장 능력을 가지는 이러한 시스템들에 커플링될 수 있는 스탠드-얼론 디바이스들을 지칭한다. 결과적으로, 용어 "네트워크"는 "물리적 네트워크" 뿐만아니라 "콘텐츠 네트워크"를 포함하며, "콘텐츠 네트워크"는 모든 물리적 네트워크들에 걸쳐 상주하는 데이터로 구성되며, 단일 엔티티로 여겨질 수 있다.

[24] 컴포넌트들은 데이터 서버(103), 웹 서버(105) 및 클라이언트 컴퓨터들(107, 109)을 포함할 수 있다. 데이터 서버(103)는 본원에서 설명된 하나 이상의 예시적인 양상들을 수행하기 위한 제어 소프트웨어 및 데이터베이스들의 전체 액세스, 제어 및 관리를 제공한다. 데이터 서버(103)는 웹 서버(105)에 연결될 수 있으며, 웹 서버(105)를 통해 사용자들은 요청된 데이터와 상호작용하여 이 데이터를 획득한다. 대안적으로, 데이터 서버(103)는 그 자체적으로 웹 서버로서 작용할 수 있고 인터넷에 직접 연결될 수 있다. 데이터 서버(103)는 네트워크(101)(예컨대, 인터넷)를 통해, 직접 또는 간접 연결을 통해 또는 일부 다른 네트워크를 통해 웹 서버(105)에 연결될 수 있다. 사용자들은 웹 서버(105)에 의해 호스팅되는 하나 이상의 외부적으로 노출된 웹 사이트들을 통해 데이터 서버(103)에 연결하기 하여 원격 컴퓨터들(107, 109)을 사용하여, 예컨대 웹 브라우저들을 사용하여 데이터 서버(103)와 상호작용할 수 있다. 클라이언트 컴퓨터들(107, 109)은 데이터 서버(103)에 저장된 데이터에 액세스하기 위하여 데이터 서버(103)와 협력하여 사용될 수 있거나 또는 다른 목적들을 위해 사용될 수 있다. 예컨대, 클라이언트 디바이스(107)로부터, 사용자는 기술분야에서 공지된 인터넷 브라우저를 사용하여 또는 컴퓨터 네트워크(예컨대, 인터넷)를 통해 웹 서버(105) 및/또는 데이터 서버(103)와 통신하는 소프트웨어 애플리케이션을 실행함으로써 웹 서버(105)에 액세스할 수 있다.

[25] 서버들 및 애플리케이션들은 동일한 물리적 머신들상에서 결합될 수 있고, 개별적인 가상 또는 논리 어드레스들을 보유할 수 있거나 또는 개별 물리 머신들상에 상주할 수 있다. 도 1은 사용될 수 있는 네트워크 아키텍처의 단지 하나의 예를 예시하며, 당업자는, 본원에서 추가로 설명되는 바와같이, 사용된 특정 네트워크 아키텍처 및 데이터 프로세싱 디바이스들이 변경될 수 있으며, 이들이 제공하는 기능이 부차적이라는 것을 인식할 것이다. 예컨대, 웹 서버(105) 및 데이터 서버(103)에 의해 제공되는 서비스들은 단일 서버상에서 결합될 수 있다.

[26] 각각의 컴포넌트(103, 105, 107, 109)는 임의의 타입의 공지된 컴퓨터, 서버 또는 데이터 프로세싱 디바이스일 수 있다. 데이터 서버(103)는 예컨대 레이트 서버(rate server)(103)의 전체 동작을 제어하는 프로세서(111)를 포함할 수 있다. 데이터 서버(103)는 RAM(113), ROM(115), 네트워크 인터페이스(117), 입력/출력 인터페이스들(119)(예컨대, 키보드, 마우스, 디스플레이, 프린터 등) 및 메모리(121)를 더 포함할 수 있다. I/O(119)는 데이터 또는 파일들을 판독하고, 기록하며, 디스플레이하며 그리고/또는 프린트하기 위한 다양한 인터페이스 유닛들 및 드라이브들을 포함할 수 있다. 메모리(121)는 데이터 프로세싱 디바이스(103)의 전체 동작을 제어하기 위한 운영체제 소프트웨어(123), 본원에서 설명된 양상들을 수행하도록 데이터 서버(103)에 명령하기 위한 제어 로직(125), 및 본원에서 설명된 양상들과 함께 사용될 수 있거나 또는 본원에서 설명된 양상들과 함께 사용되지 않을 수 있는 2차 기능, 지원 기능 및/또는 다른 기능을 제공하는 다른 애플리케이션 소프트웨어(127)를 추가로 저장할 수 있다. 제어 로직은 또한 데이터 서버 소프트웨어(125)로서 본원에서 지칭될 수 있다. 데이터 서버 소프트웨어의 기능은 제어 로직으로 코딩된 규칙들에 기초하여 자동적으로 만들어지거나 또는 사용자가 시스템내에 입력을 제공함으로써 수동적으로 만들어지거나 또는 사용자 입력(예컨대, 질의들, 데이터 업데이트들 등)에 기초한 자동 프로세싱의 조합으로 만들어진 동작들 또는 결정들을 지칭할 수 있다.

[27] 제 1 데이터베이스(129) 및 제 2 데이터베이스(131)를 포함하는 메모리(121)는 또한 본원에서 설명된 하나 이상의 양상들의 수행시에 사용되는 데이터를 저장할 수 있다. 일부 실시예들에서, 제 1 데이터베이스는 (예컨대, 개별 테이블, 보고 등으로서) 제 2 데이터베이스를 포함할 수 있다. 즉, 시스템 설계에 따라, 정보는 단일 데이터베이스에 저장될 수 있거나 또는 상이한 논리적, 가상적 또는 물리적 데이터베이스들로 분리될 수 있다. 디바이스들(105, 107, 109)은 디바이스(103)와 관련하여 설명된 것과 유사한 또는 상이한 아키텍처를 가질 수 있다. 당업자는 본원에서 설명된 데이터 프로세싱 디바이스(103)(또는 디바이스들(105, 107, 109))의 기능이 예컨대 다수의 컴퓨터들에 걸쳐 프로세싱 로드를 분배하기 위하여, 즉 지리적 위치, 사용자 액세스 레벨, 서비스 품질(QoS) 등에 기초하여 트랜잭션(transaction)들을 분리하기 위하여, 다수의 데이터 프로세싱 디바이스들에 걸쳐 분산될 수 있다는 것을 인식할 것이다.

[26] 하나 이상의 양상들은 본원에서 설명되는 바와같이 컴퓨터-사용가능 또는 판독가능 데이터 및/또는 컴퓨터-실행가능 명령들로, 예컨대 하나 이상의 컴퓨터들 또는 다른 디바이스들에 의해 실행되는 하나 이상의 프로그램 모듈들로 구현될 수 있다. 일반적으로, 프로그램 모듈들은 컴퓨터 또는 다른 디바이스의 프로세서에 의해 실행될 때 특정 태스크(task)들을 수행하거나 또는 특정 추상 데이터 타입들을 구현하는 루틴들, 프로그램들, 객체들, 컴포넌트들, 데이터 구조들 등을 포함한다. 모듈들은 실행을 위해 나중에 컴파일링되는 소스 코드 프로그래밍 언어로 쓰여질 수 있거나 또는 HTML 또는 XML와 같은 (그러나, 이에 제한되지 않음) 스크립팅 언어(scripting language)로 쓰여질 수 있다. 컴퓨터 실행가능 명령들은 비휘발성 저장 디바이스와 같은 컴퓨터 판독가능 매체상에 저장될 수 있다. 하드 디스크들, CD-ROM들, 광 저장 디바이스들, 자기 저장 디바이스들 및/또는 이들의 임의의 조합을 포함하는 임의의 적절한 컴퓨터 판독가능 저장 매체가 활용될 수 있다. 더욱이, 본원에서 설명된 바와 같은 데이터 또는 이벤트들을 나타내는 다양한 전송(비-저장) 매체는 금속 와이어들, 광섬유들, 및/또는 무선 전송 매체(예컨대, 에어(air) 및/또는 공간)와 같은 신호-전도 매체(signal-conducting media)를 통해 이동하는 전자기 파들의 형태로 소스와 목적지사이에서 이동될 수 있다. 본원에서 설명된 다양한 양상들은 방법, 데이터 프로세싱 시스템 또는 컴퓨터 프로그램 제품으로서 구현될 수 있다. 따라서, 다양한 기능들은 소프트웨어, 펌웨어 및/또는 하드웨어 또는 하드웨어 균등물들, 예컨대 집적회로들, 필드 프로그램가능 게이트 어레이(FPGA)들 등으로 전체적으로 또는 부분적으로 구현될 수 있다. 특정 데이터 구조들이 본원에서 설명된 하나 이상의 양상들을 더 효과적으로 구현하기 위하여 사용될 수 있으며, 이러한 데이터 구조들은 본원에서 설명된 컴퓨터 실행가능 명령들 및 컴퓨터-사용가능 데이터의 범위내에 있는 것으로 고려된다.

[29] 도 2를 추가로 참조하면, 본원에서 설명된 하나 이상의 양상들은 원격-액세스 환경에서 구현될 수 있다. 도 2는 본원에서 설명된 하나 이상의 예시적인 양상들에 따라 사용될 수 있는 예시적인 컴퓨팅 환경(200)의 범용 컴퓨팅 디바이스(201)를 포함하는 예시적인 시스템 아키텍처를 도시한다. 예컨대, 범용 컴퓨팅 디바이스(201)는 클라이언트 액세스 디바이스들에 가상 머신들을 제공하도록 구성된 단일-서버 또는 멀티-서버 데스크탑 가상화 시스템(예컨대, 원격 액세스 또는 클라우드 시스템)에서 서버(206a)로서 사용될 수 있다. 범용 컴퓨팅 디바이스(201)는 랜덤 액세스 메모리(RAM)(205), 판독-전용 메모리(ROM)(207), 입력/출력(I/O) 모듈(209) 및 메모리(215)를 비롯하여 서버 및 이와 연관된 컴포넌트들의 전체 동작을 제어하기 위한 프로세서(203)를 가질 수 있다.

[30] I/O 모듈(209)은 마우스, 키패드, 터치 스크린, 스캐너, 광 판독기, 및/또는 스타일러스(또는 다른 입력 디바이스(들)) ― 이를 통해 범용 컴퓨팅 디바이스(201)의 사용자는 입력을 제공할 수 있음 ―를 포함할 수 있으며, 또한 오디오 출력을 제공하기 위한 스피커 및 문자, 시청각 및/또는 그래픽 출력을 제공하기 위한 비디오 디스플레이 디바이스 중 하나 이상을 포함할 수 있다. 소프트웨어는 본원에서 설명된 바와 같은 다양한 기능들을 수행하기 위하여 범용 컴퓨팅 디바이스(201)를 특수 목적 컴퓨팅 디바이스로 구성하기 위한 명령들을 프로세서(203)에 제공하도록 메모리(215) 및/또는 다른 스토리지내에 저장될 수 있다. 예컨대, 메모리(215)는 컴퓨팅 디바이스(201)에 의해 사용된 소프트웨어, 예컨대 운영체제(217), 애플리케이션 프로그램들(219) 및 연관된 데이터베이스(221)를 저장할 수 있다.

[31] 컴퓨팅 디바이스(201)는 단말들(240)(또한 클라이언트 디바이스들로 지칭됨)과 같은 하나 이상의 원격 컴퓨터들에의 연결들을 지원하는 네트워크화 환경에서 동작할 수 있다. 단말들(240)은 범용 컴퓨팅 디바이스(103 또는 201)와 관련하여 앞서 설명된 엘리먼트들 모두 또는 많은 엘리먼트들을 포함하는, 퍼스널 컴퓨터들, 모바일 디바이스들, 랩탑 컴퓨터들, 태블릿들 또는 서버들일 수 있다. 도 2에 도시된 네트워크 연결들은 근거리 통신망(LAN)(225) 및 광역 통신망(WAN)(229)을 포함하나, 또한 다른 네트워크들을 포함할 수 있다. LAN 네트워킹 환경에서 사용될 때, 컴퓨팅 디바이스(201)는 네트워크 인터페이스 또는 어댑터(223)를 통해 LAN(225)에 연결될 수 있다. WAN 네트워킹 환경에서 사용될 때, 컴퓨팅 디바이스(201)는 모뎀(227), 또는 컴퓨터 네트워크(230)(예컨대, 인터넷)와 같이 WAN(229)를 통해 통신들을 설정하기 위한 다른 광역 네트워크 인터페이스를 포함할 수 있다. 도시된 네트워크 연결들이 예시적이며 컴퓨터들 사이에 통신 링크를 설정하는 다른 수단이 사용될 수 있다는 것이 인식될 것이다. 컴퓨팅 디바이스(201) 및/또는 단말들(240)은 또한 배터리, 스피커, 및 안테나들(도시안됨)과 같은 다양한 다른 컴포넌트들을 포함하는 모바일 단말들(예컨대, 모바일 폰들, 스마트폰들, PDA들, 노트북들 등)일 수 있다.

[32] 본원에서 설명된 양상들은 또한 다수의 다른 범용 또는 특수 목적 컴퓨팅 시스템 환경들 또는 구성들로 운용가능할 수 있다. 본원에서 설명된 양상들과 함께 사용하기에 적합할 수 있는 다른 컴퓨팅 시스템들, 환경들 및/또는 구성들의 예들은 퍼스널 컴퓨터들, 서버 컴퓨터들, 핸드-헬드 또는 랩탑 디바이스들, 멀티프로세서 시스템들, 마이크로프로세서-기반 시스템들, 셋톱 박스들, 프로그램가능 가전제품들, 네트워크 PC들, 미니컴퓨터들, 메인프레임 컴퓨터들, 앞의 시스템들 또는 디바이스들 중 임의의 것을 포함하는 분산형 컴퓨팅 환경들 등을 포함하나 이들에 제한되지 않는다.

[33] 도 2에 도시된 바와같이, 하나 이상의 클라이언트 디바이스들(240)은 하나 이상의 서버들(206a-206n)(일반적으로 본원에서 "서버(들)(206)"로 지칭됨)과 통신할 수 있다. 일 실시예에서, 컴퓨팅 환경(200)은 서버(들)(206)와 클라이언트 머신(들)(240) 사이에 설치된 네트워크 어플라이언스(appliance)를 포함할 수 있다. 네트워크 어플라이언스는 클라이언트/서버 연결들을 관리할 수 있으며, 일부 경우들에서 복수의 백엔드 서버들(206) 사이의 클라이언트 연결들을 로드 밸런싱할 수 있다.

[34] 클라이언트 머신(들)(240)은 일부 실시예들에서 단일 클라이언트 머신(240) 또는 클라이언트 머신들(240)의 단일 그룹으로 지칭될 수 있는 반면에, 서버(들)(206)는 단일 서버(206) 또는 서버들(206)의 단일 그룹으로 지칭될 수 있다. 일 실시예에서, 단일 클라이언트 머신(240)은 2개 이상의 서버(206)와 통신하는 반면에, 다른 실시예에서 단일 서버(206)는 2개 이상의 클라이언트 머신(240)과 통신한다. 또 다른 실시예에서, 단일 클라이언트 머신(240)은 단일 서버(206)와 통신한다.

[35] 일부 실시예들에서, 클라이언트 머신(240)은 이하의 비-포괄적인 용어들, 즉 클라이언트 머신(들); 클라이언트(들); 클라이언트 컴퓨터(들); 클라이언트 디바이스(들); 클라이언트 컴퓨팅 디바이스(들); 로컬 머신; 원격 머신; 클라이언트 노드(들); 엔드포인트(들) 또는 엔드포인트 노드(들) 중 어느 하나로 참조될 수 있다. 일부 실시예들에서, 서버(206)는 이하의 비-포괄적인 용어들, 즉 서버(들); 로컬 머신; 원격 머신; 서버 팜(들) 또는 호스트 컴퓨팅 디바이스(들) 중 어느 하나로 참조될 수 있다.

[36] 일 실시예에서, 클라이언트 머신(240)은 가상 머신일 수 있다. 가상 머신은 임의의 가상 머신일 수 있는 반면에, 일부 실시예들에서, 가상 머신은 타입 1 또는 타입 2 하이퍼바이저(hypervisor), 예컨대 Citrix Systems, IBM, VMware에 의해 개발된 하이퍼바이저 또는 임의의 다른 하이퍼바이저에 의해 관리되는 임의의 가상 머신일 수 있다. 일부 양상들에서, 가상 머신은 하이퍼바이저에 의해 관리될 수 있는 반면에, 양상들에서 가상 머신은 서버(206)상에서 실행되는 하이퍼바이저 또는 클라이언트(240)상에서 실행되는 하이퍼바이저에 의해 관리될 수 있다.

[37] 일부 실시예들은 서버(206)상에서 원격적으로 실행되는 애플리케이션 또는 다른 원격적으로 위치한 머신에 의해 생성되는 애플리케이션 출력을 디스플레이하는 클라이언트 디바이스(240)를 포함한다. 이들 실시예들에서, 클라이언트 디바이스(240)는 애플리케이션 윈도우, 브라우저 또는 다른 출력 윈도우의 출력을 디스플레이하기 위하여 가상 머신 수신기 프로그램 또는 애플리케이션을 실행할 수 있다. 일례에서 애플리케이션은 데스크탑인 반면에, 다른 예들에서 애플리케이션은 데스크탑을 생성하거나 또는 제시하는 애플리케이션이다. 데스크탑은 로컬 및/또는 원격 애플리케이션들이 통합될 수 있는 운영체제의 인스턴스(instance)에 대한 사용자 인터페이스를 제공하는 그래픽 쉘(graphical shell)을 포함할 수 있다. 본원에서 설명된 바와같은 애플리케이션들은 운영체제(그리고, 또한 선택적으로 데스크탑)의 인스턴스가 로드된 후 실행되는 프로그램들이다.

[38] 일부 실시예들에서, 서버(206)는 서버(206)상에서 실행되는 애플리케이션에 의해 생성되는 디스플레이 출력을 제시하기 위하여 클라이언트상에서 실행되는 씬-클라이언트(thin-client) 또는 원격-디스플레이 애플리케이션에 데이터를 송신하기 위하여 원격 프리젠테이션 프로토콜 또는 다른 프로그램을 사용한다. 씬-클라이언트 또는 원격-디스플레이 프로토콜은 프로토콜들의 이하의 비-포괄적인 리스트, 즉 플로리다, 포트 로더데일에 위치한 Citrix Systems, Inc.에 의해 개발된 ICA(Independent Computing Architecture) 프로토콜 또는 워싱턴 레드몬드에 위치한 Microsoft Corporation에 의해 제조된 RDP(Remote Desktop Protocol) 중 어느 하나일 수 있다.

[39] 원격 컴퓨팅 환경은 예컨대 클라우드 컴퓨팅 환경에서 서버들(206a-206n)이 서버 팜(206)으로 논리적으로 함께 그룹핑되도록 2개 이상의 서버(206a-206n)를 포함할 수 있다. 서버 팜(206)은 지리적으로 분산된 반면에 함께 논리적으로 그룹핑되는 서버들(206) 또는 서로 근접하게 배치되는 반면에 함께 논리적으로 그룹핑되는 서버들(206)을 포함할 수 있다. 일부 실시예들에서, 서버 팜(206) 내의 지리적으로 분산된 서버들(206a-206n)은 WAN(광역), MAN(대도시) 또는 LAN(지역)을 사용하여 통신할 수 있으며, 여기서 상이한 지리적 지역들은 상이한 대륙들; 상이한 대륙 지역들; 상이한 국가들; 상이한 주들; 상이한 도시들; 상이한 캠퍼스들; 상이한 방들; 또는 전술한 지리적 위치들의 임의의 조합으로 특징지워질 수 있다. 일부 실시예들에서 서버 팜(206)은 단일 엔티티로서 관리될 수 있는 반면에, 다른 실시예들에서 서버 팜(206)은 다수의 서버 팜들을 포함할 수 있다.

[40] 일부 실시예들에서, 서버 팜은 실질적으로 유사한 타입의 운영체제 플랫폼(예컨대, WINDOWS, UNIX, LINUX, iOS, ANDROID, SYMBIAN 등)을 실행하는 서버들(206)을 포함할 수 있다. 다른 실시예들에서, 서버 팜(206)은 제 1 타입의 운영체제 플랫폼을 실행하는 하나 이상의 서버들의 제 1 그룹 및 제 2 타입의 운영체제 플랫폼을 실행하는 하나 이상의 서버들의 제 2 그룹을 포함할 수 있다.

[41] 서버(206)는 필요에 따라 임의의 타입의 서버로서, 예컨대 파일 서버, 애플리케이션 서버, 웹 서버, 프록시 서버, 어플라이언스, 네트워크 어플라이언스, 게이트웨이, 애플리케이션 게이트웨이, 게이트웨이 서버, 가상화 서버, 전개 서버, SSL VPN 서버, 방화벽, 웹 서버, 애플리케이션 서버로서, 또는 마스터 애플리케이션 서버, 액티브 디렉토리를 실행하는 서버, 또는 방화벽 기능, 애플리케이션 기능 또는 로드 밸런싱 기능을 제공하는 애플리케이션 가속 프로그램을 실행하는 서버로서 구성될 수 있다. 다른 서버 타입들이 또한 사용될 수 있다.

[42] 일부 실시예들은 클라이언트 머신(240)으로부터의 요청들을 수신하며, 제 2 서버(206b)에 요청을 포워드하며 그리고 제 2 서버(206b)로부터의 응답으로 클라이언트 머신(240)에 의해 생성되는 요청에 응답하는 제 1 서버(206a)를 포함한다. 제 1 서버(206a)는 클라이언트 머신(240)이 이용할 수 있는 애플리케이션들의 목록 뿐만아니라 애플리케이션들의 목록내에서 식별되는 애플리케이션을 호스팅하는 애플리케이션 서버(206)와 연관된 어드레스 정보를 획득할 수 있다. 이후, 제 1 서버(206a)는 웹 인터페이스를 사용하여 클라이언트의 요청에 대한 응답을 제시할 수 있으며, 식별된 애플리케이션에 대한 액세스를 클라이언트(240)에 제공하기 위하여 클라이언트(240)와 직접 통신할 수 있다. 하나 이상의 클라이언트들(240) 및/또는 하나 이상의 서버들(206)은 네트워크(230), 예컨대 네트워크(101)를 통해 데이터를 전송할 수 있다.

[43] 도 2는 예시적인 데스크탑 가상화 시스템일 수 있는 고레벨 아키텍처를 도시한다. 도시된 바와같이, 데스크탑 가상화 시스템은 하나 이상의 클라이언트 액세스 디바이스들(240)에 가상 데스크탑들 및/또는 가상 애플리케이션들을 제공하도록 구성된 적어도 하나의 가상화 서버(206)를 포함하는, 단일-서버 또는 멀티-서버 시스템 또는 클라우드 시스템일 수 있다. 본원에서 사용되는 바와같이, 데스크탑은 하나 이상의 애플리케이션들이 호스팅되고 그리고/또는 실행되는 그래픽 환경 또는 공간을 지칭한다. 데스크탑은 로컬 및/또는 원격 애플리케이션들이 통합될 수 있는 운영체제의 인스턴스에 대한 사용자 인터페이스를 제공하는 그래픽 쉘을 포함할 수 있다. 애플리케이션들은 운영체제(그리고 선택적으로 또한 데스크탑)의 인스턴스가 로드된 이후에 실행되는 프로그램들을 포함할 수 있다. 운영체제의 각각의 인스턴스는 물리적(예컨대, 디바이스당 하나의 운영체제) 또는 가상적(예컨대, 단일 디바이스상에서 실행되는 OS의 많은 인스턴스들)일 수 있다. 각각의 애플리케이션은 로컬 디바이스상에서 실행될 수 있거나 또는 원격적으로 위치한 디바이스(예컨대 원격 디바이스)상에서 실행될 수 있다.

[44] 데스크탑 가상화 시스템에서 활용될 때, 서버(206)는 가상화 환경, 예컨대 싱글-서버, 멀티-서버 또는 클라우드 컴퓨팅 환경에서 가상화 서버로서 구성될 수 있다. 이러한 실시예들에서, 가상화 서버(206)는 하나 이상의 물리 디스크들, 물리 디바이스들, 물리 프로세서들 및 물리 메모리들을 비롯하여 하드웨어 계층을 포함할 수 있다. 가상화 서버(206)의 메모리(215)는 임의의 수의 가상 머신들을 생성하여 관리하도록 구성된 펌웨어, 운영체제 및 하이퍼바이저(예컨대, 타입 1 또는 타입 2 하이퍼바이저)를 포함할 수 있다. 가상 머신은 프로세서에 의해 실행될 때 가상 머신이 물리 컴퓨팅 디바이스와 매우 유사한 프로그램들 및 프로세스들을 실행할 수 있도록 물리 컴퓨터의 동작을 개시하는 실행가능 명령들의 세트이다. 하이퍼바이저는 가상 머신에게 이용가능한 물리 하드웨어, 메모리, 프로세서 및 다른 시스템 자원들의 가상 뷰를 각각의 가상 머신에 제공할 수 있다.

[45] 본원에서 설명된 일부 양상들은 클라우드-기반 환경에서 구현될 수 있다. 이러한 환경들에서, 클라이언트 디바이스들(240)는 클라우드 시스템의 컴퓨팅 자원들(예컨대, 호스트 서버들, 저장 자원들 및 네트워크 자원들)에 액세스하기 위하여 하나 이상의 클라우드 관리 서버들(206)과 통신할 수 있다. 클라우드 관리 서버들(206)는 클라우드 하드웨어 및 소프트웨어 자원들을 포함하는 다양한 컴퓨팅 자원들을 관리할 수 있으며, 사용자 인터페이스들을 제공할 수 있으며, 사용자 인터페이스들을 통해, 클라우드 운영자들 및 클라우드 고객들은 클라우드 시스템과 상호작용할 수 있다. 예컨대, 관리 서버들(206)은 클라우드 운영자들이 클라우드 자원들을 관리하고, 가상화 계층을 구성하며, 고객 계정들을 관리하며 그리고 다른 클라우드 관리 태스크들을 수행하도록 하는 사용자 인터페이스들을 API들의 세트 및/또는 하나 이상의 클라우드 운영자 콘솔 애플리케이션들(예컨대, 웹-기반 또는 스탠드얼론 애플리케이션들)에 제공할 수 있다. 관리 서버들(206)는 또한 최종 사용자들로부터 클라이언트 컴퓨터들(240)을 통해 클라우드 컴퓨팅 요청들, 예컨대 을 클라우드 내의 가상 머신들을 생성하거나 또는 수정하거나 또는 파괴하는 요청들을 수신하도록 구성된 사용자 인터페이스들과 함께 API들의 세트 및/또는 하나 이상의 고객 콘솔 애플리케이션들을 포함할 수 있다. 클라이언트 컴퓨터들(240)은 인터넷 또는 다른 통신 네트워크를 통해 관리 서버(206)에 연결될 수 있으며, 관리 서버(206)에 의해 관리되는 컴퓨팅 자원들 중 하나 이상의 자원에 대한 액세스를 요청할 수 있다. 클라이언트 요청들에 응답하여, 관리 서버(206)는 클라이언트 요청들에 기초하여 클라우드 시스템의 하드웨어 계층에서 물리적 자원들을 선택하여 제공하도록 구성된 자원 관리자를 포함할 수 있다. 예컨대, 관리 서버(206) 및 클라우드 시스템의 추가 컴포넌트들은 네트워크(예컨대, 인터넷)를 통해 클라이언트 컴퓨터들(240)에서 고객들에 대한 가상 머신들 및 이들의 동작 환경들 (예컨대, 하이퍼바이저들, 저장 자원들, 네트워크 엘리먼트들에 의해 제공된 서비스들 등)을 제공하고, 생성하여 관리하여, 고객들에게 계산 자원들, 데이터 저장 서비스들, 네트워킹 능력들 및 컴퓨터 플랫폼과 애플리케이션 지원을 제공하도록 구성될 수 있다. 클라우드 시스템들은 또한 보안 시스템들, 개발 환경들, 사용자 인터페이스들 등을 비롯하여 다양한 특정 서비스들을 제공하도록 구성될 수 있다.

[46] 클라우드 컴퓨팅 환경들은 또한 가상 머신들을 생성하고 관리하며 클라우드의 물리 자원들을 사용하여 다른 서비스들을 고객들에게 제공하도록 구성된 추가 하드웨어 및/또는 소프트웨어 자원들을 가진 가상화 계층을 포함할 수 있다. 가상화 계층은 네트워크 가상화들, 저장 가상화들 등을 제공하기 위한 다른 컴포넌트들과 함께 앞서 설명된 바와같은 하이퍼바이저들을 포함할 수 있다. 가상화 계층은 물리 자원 계층으로부터의 개별 계층일 수 있거나 또는 물리 자원 계층과 동일한 하드웨어 및/또는 소프트웨어 자원들 중 일부 또는 모두와 공유할 수 있다.

[47] 기업 모빌리티 관리 아키텍처

[48] 도 3은 BYOD 환경에서 사용하기 위한 기업 모빌리티 기술 아키텍처(300)를 나타낸다. 아키텍처는 모바일 디바이스(302)의 사용자가 모바일 디바이스(302)를 사용하여 기업 자원 또는 개인 자원에 액세스하고, 모바일 디바이스(302)를 개인적 용도로 사용하도록 한다. 사용자는 기업에 의해 사용자에게 제공된 모바일 디바이스(302) 또는 사용자에 의해 구매된 모바일 디바이스(302)를 이용하여 이와 같은 기업 서비스들(308) 또는 기업 자원들(304)에 액세스할 수 있다. 사용자는 단지 비지니스용으로 또는 비지니스 및 개인용으로 모바일 디바이스(302)를 활용할 수 있다. 모바일 디바이스는 iOS 운영체제, 및 안드로이드 운영체제 등을 실행할 수 있다. 기업은 모바일 디바이스(304)를 관리하기 위한 정책들을 구현하는 것을 선택할 수 있다. 이 정책들은 모바일 디바이스가 식별되거나, 보안 또는 보안 검증되고 기업 자원들에 대해 선택적으로 또는 전체적으로 액세스할 수 있도록 방화벽 또는 게이트웨이를 통해 주입될 수 있다. 정책들은 모바일 디바이스 관리 정책들, 모바일 애플리케이션 관리 정책들, 모바일 데이터 관리 정책들, 또는 모바일 디바이스, 애플리케이션 및 데이터 관리 정책들의 일부 조합일 수 있다. 모바일 디바이스 관리 정책들의 애플리케이션을 통해 관리되는 모바일 디바이스(304)는 등록 디바이스로서 지칭될 수 있다.

[49] 모바일 디바이스의 운영체제는 관리 파티션(managed partition)(310) 및 비관리 파티션(unmanaged partition)(312)으로 분리될 수 있다. 관리 파티션(310)은 관리 파티션 상에서 실행되는 애플리케이션들 및 관리 파티션에 저장되는 데이터를 보안하기 위한 정책들이 자신에 적용되게 할 수 있다. 관리 파티션상에서 실행되는 애플리케이션들은 보안 애플리케이션들일 수 있다. 보안 애플리케이션들은 이메일 애플리케이션들, 웹 브라우징 애플리케이션들, SaaS(software-as-a-service) 액세스 애플리케이션들, 윈도우즈 애플리케이션 액세스 애플리케이션들 등일 수 있다. 보안 애플리케이션들은 보안 네이티브 애플리케이션들(314), 보안 애플리케이션 런처(318)에 의해 실행되는 보안 원격 애플리케이션들(322), 보안 애플리케이션 런처(318)에 의해 실행되는 가상화 애플리케이션들(326) 등일 수 있다. 보안 네이티브 애플리케이션들(314)은 보안 애플리케이션 래퍼(wrapper)(320)에 의해 래핑될 수 있다. 보안 애플리케이션 래퍼(320)는 보안 네이티브 애플리케이션이 디바이스상에서 실행될 때 모바일 디바이스(302)상에서 실행되는 통합 정책들을 포함할 수 있다. 보안 애플리케이션 래퍼(320)는 보안 네이티브 애플리케이션(314)의 실행시 요청된 태스크를 완료하기 위하여 보안 네이티브 애플리케이션(314)이 요구할 수 있는, 기업에서 호스팅되는 자원들을 모바일 디바이스(302)상에서 실행되는 보안 네이티브 애플리케이션(314)에게 알려주는 메타-데이터를 포함할 수 있다. 보안 애플리케이션 런처(318)에 의해 실행되는 보안 원격 애플리케이션들(322)은 보안 애플리케이션 런처 애플리케이션(318) 내에서 실행될 수 있다. 보안 애플리케이션 런처(318)에 의해 실행되는 가상화 애플리케이션(326)은 모바일 디바이스(302)상의 자원들, 기업 자원들(304) 등을 활용할 수 있다. 보안 애플리케이션 런처(318)에 의해 실행되는 가상화 애플리케이션들(326)에 의해 모바일 디바이스(302)상에서 사용되는 자원들은 사용자 상호작용 자원들, 프로세싱 자원들 등을 포함할 수 있다. 사용자 상호작용 자원들은 키보드 입력, 마우스 입력, 카메라 입력, 촉각 입력, 오디오 입력, 시각 입력, 제스처 입력 등을 수집하여 전송하기 위하여 사용될 수 있다. 프로세싱 자원들은 사용자 인터페이스를 제시하고, 기업 자원들(304)로부터 수신된 데이터를 프로세싱하는 것 등을 수행하기 위하여 사용될 수 있다. 보안 애플리케이션 런처(318)에 의해 실행되는 가상화 애플리케이션들(326)에 의해 기업 자원들(304)에서 사용되는 자원들은 사용자 인터페이스 생성 자원들, 프로세싱 자원들 등을 포함할 수 있다. 사용자 인터페이스 생성 자원들은 사용자 인터페이스를 어셈블리하고, 사용자 인터페이스를 수정하며, 사용자 인터페이스를 리프레시하는 것 등을 수행하기 위하여 사용될 수 있다. 프로세싱 자원들은 정보를 생성하고, 정보를 판독하며, 정보를 업데이트하며, 정보를 삭제하는 것 등을 수행하기 위하여 사용될 수 있다. 예컨대, 가상화 애플리케이션은 GUI와 연관된 사용자 상호작용들을 기록하고, 이들을 서버 애플리케이션에 통신할 수 있으며, 여기서 서버 애플리케이션은 서버상에서 동작하는 애플리케이션에 대한 입력으로서 사용자 상호작용 데이터를 사용할 것이다. 이러한 어레인지먼트에서, 기업은 서버측상의 애플리케이션 뿐만아니라 애플리케이션과 연관된 데이터, 파일들 등을 유지하는 것을 선택할 수 있다. 기업이 모바일 디바이스상에서 전개하기 위하여 일부 애플리케이션들을 보안함으로써 본원의 원리들에 따라 그 일부 애플리케이션들을 "결집(mobilize)시키는" 것을 선택할 수 있는 반면에, 이러한 어레인지먼트는 또한 특정 애플리케이션들을 위해 선택될 수 있다. 예컨대, 일부 애플리케이션들이 모바일 디바이스상에서 사용하기 위하여 보안될 수 있는 반면에, 다른 애플리케이션들은 모바일 디바이스상에서 전개하기 위하여 준비되거나 또는 전용될 수 없으며, 따라서 기업은 가상화 기술들을 통해 준비되지 않은 애플리케이션들에의 모바일 사용자 액세스를 제공하는 것을 선택할 수 있다. 다른 예로서, 기업은 모바일 디바이스에 대한 애플리케이션을 커스터마이징(customizing)하는 것이 매우 어렵거나 또는 그렇지 않은 경우에 바람직하지 않을 대량 및 복합 데이터 세트들을 가진 대규모 복합 애플리케이션들(예컨대, 자료 자원 계획 애플리케이션들)을 가질 수 있으며, 따라서, 기업은 가상화 기술들을 통해 애플리케이션에의 액세스를 제공하는 것을 선택할 수 있다. 또 다른 예로서, 기업은 심지어 보안된 모바일 환경에서 조차 기업이 너무 민감하게 생각할 수 있는 고보안 데이터(예컨대, 인적 자원 데이터, 고객 데이터, 엔지니어링 데이터)를 유지하는 애플리케이션을 가질 수 있으며, 따라서 기업은 이러한 애플리케이션들 및 데이터에 대한 모바일 액세스를 허용하기 위하여 가상화 기술들을 사용하는 것을 선택할 수 있다. 기업은 서버측에서 동작하는 것이 더 적절한 것으로 여겨지는 애플리케이션들에 대한 액세스를 허용하기 위하여, 가상화 애플리케이션 뿐만아니라 모바일 디바이스상의 완전하게 보안된 그리고 완전하게 기능적인 애플리케이션들을 제공하는 것을 선택할 수 있다. 일 실시예에서, 가상화 애플리케이션은 보안 저장 위치들 중 하나의 위치에 있는 모바일 폰상에 일부 데이터, 파일들 등을 저장할 수 있다. 기업은 예컨대 다른 정보를 허용하지 않으면서 특정 정보가 폰상에 저장되도록 하는 것을 선택할 수 있다.

[50] 본원에서 설명된 바와같은 가상화 애플리케이션와 관련하여, 모바일 디바이스는 GUI들을 제시하고 이후 GUI와의 사용자 상호작용들을 기록하도록 설계되는 가상화 애플리케이션을 가질 수 있다. 애플리케이션은 애플리케이션과의 사용자 상호작용들로서 서버측 애플리케이션에 의해 사용될 사용자 상호작용들을 서버에 통신할 수 있다. 이에 응답하여, 서버측상의 애플리케이션은 새로운 GUI를 모바일 디바이스에 다시 전송할 수 있다. 예컨대, 새로운 GUI는 정적 페이지, 동적 페이지, 애니메이션 등일 수 있다.

[51] 관리 파티션상에서 실행되는 애플리케이션들은 안정화된 애플리케이션들일 수 있다. 안정화된 애플리케이션들은 디바이스 관리자(324)에 의해 관리될 수 있다. 디바이스 관리자(324)는 안정화된 애플리케이션들을 모니터링하고 문제점들을 검출하여 제거하기 위한 기술들을 활용할 수 있는데, 이러한 문제점들은 그 문제점들을 검출하여 제거하는데 상기 기술들이 활용되지 않았다면 불안정한 애플리케이션을 유발하였을 것이다.

[52] 보안 애플리케이션들은 모바일 디바이스의 관리 파티션(310)의 보안 데이터 컨테이너(328)에 저장된 데이터에 액세스할 수 있다. 보안 데이터 컨테이너에서 보안된 데이터는 보안 래핑된 애플리케이션들(314), 보안 애플리케이션 런처(322)에 의해 실행되는 애플리케이션들, 보안 애플리케이션 런처(322)에 의해 실행되는 가상화 애플리케이션들(326) 등에 의해 액세스될 수 있다. 보안 데이터 컨테이너(328)에 저장된 데이터는 파일들, 데이터베이스들 등을 포함할 수 있다. 보안 데이터 컨테이너(328)에 저장된 데이터는 보안 애플리케이션들(332) 사이에서 공유되는 특정 보안 애플리케이션(330)에 한정된 데이터 등을 포함할 수 있다. 보안 애플리케이션에 한정된 데이터는 보안 범용 데이터(334) 및 고보안 데이터(338)를 포함할 수 있다. 보안 범용 데이터는 AES 128-비트 암호화 등과 같은 고강화 암호화를 사용할 수 있는 반면에, 고보안 데이터(338)는 AES 254-비트 암호화와 같은 초고강화 암호화를 사용할 수 있다. 보안 데이터 컨테이너(328)에 저장된 데이터는 디바이스 관리자(324)로부터의 커맨드의 수신시에 디바이스로부터 제거될 수 있다. 보안 애플리케이션들은 듀얼-모드 옵션(340)을 가질 수 있다. 듀얼 모드 옵션(340)은 비보안 모드에서 보안 애플리케이션을 동작하기 위한 옵션을 사용자에게 제시할 수 있다. 비보안 모드에서, 보안 애플리케이션들은 모바일 디바이스(302)의 비관리 파티션(312)상의 비보안 데이터 컨테이너(342)에 저장된 데이터에 액세스할 수 있다. 비보안 데이터 컨테이너에 저장된 데이터는 개인 데이터(344)일 수 있다. 비보안 데이터 컨테이너(342)에 저장된 데이터는 또한 모바일 디바이스(302)의 비관리 파티션(312)상에서 실행되는 비보안 애플리케이션들(348)에 의해 액세스될 수 있다. 비보안 데이터 컨테이너(342)에 저장된 데이터는 보안 데이터 컨테이너(328)에 저장된 데이터가 모바일 디바이스(302)로부터 제거될 때 모바일 디바이스(302)상에서 유지될 수 있다. 기업은 사용자에 의해 소유되거나 또는 라이센싱되거나 또는 제어되는 개인 데이터, 파일들 및/또는 애플리케이션들(개인 데이터)을 남기거나 또는 그렇지 않은 경우에 보존하면서 기업에 의해 소유되거나 라이센싱되거나 또는 제어되는 선택된 또는 모든 데이터, 파일들 및/또는 애플리케이션들(기업 데이터)을 모바일 디바이스로부터 제거하는 것을 원할 수 있다. 이러한 동작은 선택적 지움(selective wipe)으로서 지칭될 수 있다. 본원에서 설명된 양상들에 따라 기업 및 개인 데이터가 배열되는 경우에, 기업은 선택적 지움을 수행할 수 있다.

[53] 모바일 디바이스는 기업의 기업 자원들(304) 및 기업 서비스들(308)에, 공중 인터넷(348) 등에 연결할 수 있다. 모바일 디바이스는 가상 사설 네트워크 연결들을 통해 기업 자원들(304) 및 기업 서비스들(308)에 연결할 수 있다. 가상 사설 네트워크 연결들은 특정 애플리케이션들(350), 특정 디바이스들, 모바일 디바이스상의 특정 보안 영역들 등(352)에 특정적일 수 있다. 예컨대, 폰의 보안 영역에 래핑된 애플리케이션들 각각은 애플리케이션 특정 VPN에의 액세스가 가능한 경우에 사용자 또는 디바이스 속성 정보와 함께 애플리케이션과 연관된 속성들에 기초하여 승인될 수 있도록 애플리케이션 특정 VPN를 통해 기업 자원들에 액세스할 수 있다. 가상 사설 네트워크 연결들은 마이크로소프트 교환 트래픽, 마이크로소프트 액티브 디렉토리 트래픽, HTTP 트래픽, HTTPS 트래픽, 애플리케이션 관리 트래픽 등을 전달할 수 있다. 가상 사설 네트워크 연결들은 싱글-사인-온 인증 프로세스(single-sign-on authentication process)들(354)을 지원하고 인에이블할 수 있다. 싱글-사인-온 프로세스들은 사용자로 하여금 인증 크리덴셜들의 단일 세트를 제공하도록 할 수 있으며, 이후 인증 크리덴셜들은 인증 서비스(358)에 의해 검증된다. 이후, 인증 서비스(358)는 사용자가 각각의 개별 기업 자원(304)에 인증 크리덴셜들을 제공하는 것을 필요로 하지 않고 다수의 기업 자원들(304)에 대한 사용자 액세스를 승인할 수 있다.

[54] 가상 사설 네트워크 연결들은 액세스 게이트웨이(360)에 의해 설정 및 관리될 수 있다. 액세스 게이트웨이(360)는 모바일 디바이스(302)에 기업 자원들(304)을 전달하는 것을 관리하고, 가속시키며 그리고 개선하는 성능 강화 특징들을 포함할 수 있다. 액세스 게이트웨이는 또한 모바일 디바이스(302)로부터 공중 인터넷(348)으로 트래픽을 재-라우팅할 수 있으며, 따라서 모바일 디바이스(302)가 공중 인터넷(348)상에서 실행되는 공개적으로 이용가능한 비보안 애플리케이션들에 액세스하도록 할 수 있다. 모바일 디바이스는 트랜스포트 네트워크(362)를 통해 액세스 게이트웨이에 연결할 수 있다. 트랜스포트 네트워크(362)는 유선 네트워크, 무선 네트워크, 클라우드 네트워크, 근거리 통신망, 도시권 통신망, 광역 통신망, 공중 네트워크, 사설 네트워크 등일 수 있다.

[55] 기업 자원들(304)은 이메일 서버들, 파일 공유 서버들, SaaS 애플리케이션들, 웹 애플리케이션 서버들, 윈도우즈 애플리케이션 서버들 등을 포함할 수 있다. 이메일 서비스들은 교환 서버들, Lotus Notes 서버들 등을 포함할 수 있다. 파일 공유 서버들은 ShareFile 서버들 등을 포함할 수 있다. SaaS 애플리케이션들은 Salesforce 등을 포함할 수 있다. 윈도우즈 애플리케이션 서버들은 로컬 윈도우즈 운영체제 등 상에서 실행되는 것으로 의도된 애플리케이션들을 제공하도록 구축된 일부 애플리케이션 서버를 포함할 수 있다. 기업 자원들(304)은 전제-기반 자원(premise-based resource)들, 클라우드 기반 자원들 등일 수 있다. 기업 자원들(304)은 직접적으로 또는 액세스 게이트웨이(360)를 통해 모바일 디바이스(302)에 의해 액세스될 수 있다. 기업 자원들(304)은 트랜스포트 네트워크(362)를 통해 모바일 디바이스(302)에 의해 액세스될 수 있다. 트랜스포트 네트워크(362)는 유선 네트워크, 무선 네트워크, 클라우드 네트워크, 근거리 통신망, 도시권 통신망, 광역 네트워크, 공중 네트워크, 사설 네트워크 등일 수 있다.

[56] 기업 서비스들(308)은 인증 서비스들(358), 위협 검출 서비스(364), 디바이스 관리 서비스들(324), 파일 공유 서비스들(368), 정책 관리자 서비스들(370), 소셜 통합 서비스들(372), 애플리케이션 제어기 서비스(374) 등을 포함할 수 있다. 인증 서비스들(358)은 사용자 인증 서비스들, 디바이스 인증 서비스들, 애플리케이션 인증 서비스들, 데이터 인증 서비스들 등을 포함할 수 있다. 인증 서비스들(358)은 인증서들을 사용할 수 있다. 인증서들은 기업 자원들(304) 등에 의해 모바일 디바이스(302)상에 저장될 수 있다. 모바일 디바이스(302)상에 저장된 인증서들은 모바일 디바이스상의 암호화된 위치에 저장될 수 있으며, 인증서는 인증할 때 등에 사용하기 위해 모바일 디바이스(302)상에 일시적으로 저장될 수 있다. 위협 검출 서비스들(364)은 침입 검출 서비스들, 비허가 액세스 시도 검출 서비스들 등을 포함할 수 있다. 비허가 액세스 시도 검출 서비스들은 디바이스들, 애플리케이션들, 데이터 등에 액세스하기 위한 비허가 시도들을 포함할 수 있다. 디바이스 관리 서비스들(324)은 구성, 프로비저닝, 보안, 지원, 모니터링, 보고 및 해체 서비스들을 포함할 수 있다. 파일 공유 서비스들(368)은 파일 관리 서비스들, 파일 저장 서비스들, 파일 컬래버레이션 서비스들 등을 포함할 수 있다. 정책 관리 서비스들(370)은 디바이스 정책 관리자 서비스들, 애플리케이션 정책 관리자 서비스들, 데이터 정책 관리자 서비스들 등을 포함할 수 있다. 소셜 통합 서비스들(372)은 접촉 통합 서비스들, 컬래버레이션 서비스들, 페이스북, 트위터 및 LinkedIn 등과 같은 소셜 네트워크와의 통합 등을 포함할 수 있다. 애플리케이션 제어기 서비스들(374)은 관리 서비스들, 프로비저닝 서비스들, 전개 서비스들, 할당 서비스들, 철회 서비스들, 래핑 서비스들 등을 포함할 수 있다.

[57] 기업 모빌리티 기술 아키텍처(300)는 애플리케이션 스토어(378)를 포함할 수 있다. 애플리케이션 스토어(378)는 비-래핑된 애플리케이션들(380), 사전-래핑된 애플리케이션들(382) 등을 포함할 수 있다. 애플리케이션들은 애플리케이션 제어기(374)로부터 애플리케이션 스토어(378)에 파퓰레이트될 수 있다. 애플리케이션 스토어(378)는 액세스 게이트웨이(360), 공중 네트워크(348) 등을 통해 모바일 디바이스(302)에 의해 액세스될 수 있다. 애플리케이션 스토어는 사용자 인터페이스를 사용할 때 이해하기 쉽고 용이하도록 제공될 수 있다. 애플리케이션 스토어(378)는 소프트웨어 전개 키트(384)에 대한 액세스를 제공할 수 있다. 소프트웨어 전개 키트(384)는 본 상세한 설명에서 이전에 설명된 바와같이 애플리케이션을 래핑함으로써 사용자에 의해 선택된 애플리케이션들을 보안하는 능력을 사용자에게 제공할 수 있다. 이후, 소프트웨어 전개 키트(384)를 사용하여 래핑된 애플리케이션은 애플리케이션 제어기(374)를 사용하여 애플리케이션 스토어(378)에서 파퓰레이트함으로써 모바일 디바이스(302)에게 이용가능하게 만들어질 수 있다.

[58] 기업 모빌리티 기술 아키텍처(300)는 관리 및 분석 능력(388)을 포함할 수 있다. 관리 및 분석 능력(388)은 자원들이 어떻게 사용되는지, 자원들이 얼마나 자주 사용되는지 등에 관한 정보를 제공할 수 있다. 자원들은 디바이스들, 애플리케이션들, 데이터 등을 포함할 수 있다. 자원들이 어떻게 사용되는지는 어떤 디바이스들이 어떤 애플리케이션들을 다운로드하는지, 어떤 애플리케이션들이 어떤 데이터에 액세스하는지 등을 포함할 수 있다. 자원들이 얼마나 자주 사용되는지는 애플리케이션들이 얼마나 자주 다운로드되었는지, 데이터의 특정 세트가 애플리케이션에 의해 얼마나 많은 횟수로 액세스되었는지 등을 포함할 수 있다.

[59] 도 4는 다른 예시적인 기업 모빌리티 관리 시스템(400)이다. 도 3를 참조하여 앞서 설명된 모빌리티 관리 시스템(300)의 일부 컴포넌트들은 간략화를 위해 생략되었다. 도 4에 도시된 시스템(400)의 아키텍처는 도 3를 참조로 하여 앞서 설명된 시스템(300)의 아키텍처와 많은 측면에서 유사하고, 앞서 언급되지 않은 추가적인 특징들을 포함할 수 있다.

[60] 이 경우, 좌측은 수신기(404)를 가진 등록 모바일 디바이스(402)를 나타내는데, 이는 (액세스 게이트웨이(Access Gateway) 및 애플리케이션 제어기 기능을 포함하는) 클라우드 게이트웨이(406)와 상호 작용을 하여, 우측 위쪽에 도시된 것과 같은 다양한 기업 자원들(408) 및 서비스들(409), 예컨대 익스체인지(Exchange), 쉐어포인트(Sharepoint), PKI 자원들, 케베로스(Kerberos) 자원들, 인증서 발행 서비스에 액세스한다. 상세히 도시되지는 않았지만, 모바일 디바이스(402)는 또한 애플리케이션들을 선택하여 다운로드하기 위한 기업 애플리케이션 스토어(예컨대, StoreFront)와 상호 작용할 수 있다.

[61] 수신기(404)는, HDX/ICA 디스플레이 원격 프로토콜을 이용하여 액세스되는, 기업 데이터 센터에서 호스팅되는 윈도우즈 애플리케이션들/데스크탑들에 대한 UI(사용자 인터페이스) 매개자(intermediary)로서 동작할 수 있다. 수신기(404)는 또한 모바일 디바이스(402) 상의 네이티브 애플리케이션들, 예컨대 네이티브 iOS 또는 안드로이드 애플리케이션들의 설치 및 관리를 지원한다. 예컨대, 도 4에 도시된 관리 애플리케이션(410)(메일, 브라우저, 래핑 애플리케이션)은 모두 디바이스 상에서 국부적으로 실행되는 네이티브 애플리케이션들이다. 수신기(404) 및 본 아키텍처의 MDX (mobile experience technology)는 기업 자원들/서비스들(408)에 대한 연결 및 SSO(single sign on)와 같은 정책 기반 관리 능력들 및 사양들을 제공하기 위해 동작한다. 수신기(404)는 기업에 대한, 보통 다른 클라우드 게이트웨이 컴포넌트들에 대해 SSO을 가진 액세스 게이트웨이(AG)에 대한 주된 사용자 인증을 처리한다. 수신기(404)는 모바일 디바이스(402) 상의 MDX 관리 애플리케이션(410)의 행위를 제어하기 위해 클라우드 게이트웨이(406)로부터 정책들을 획득한다.

[62] 네이티브 애플리케이션들(410)과 수신기(404) 사이의 보안 IPC 링크들(412)은 수신기가 각각의 애플리케이션을 "래핑"하는 DMX 프레임워크(414)에 의해 시행될 정책들을 적용하도록 하는 관리 채널을 나타낸다. IPC 채널(412)은 또한 기업 자원들(408)에 대한 연결 및 SSO를 인에이블하는 크리덴셜 및 인증 정보를 수신기(404)가 적용하도록 한다. 마지막으로, IPC 채널(412)은 MDX 프레임워크(414)가 수신기(404)에 의해 구현되는 사용자 인터페이스 기능들, 예컨대 온라인 및 오프라인 인증을 인보크하도록 한다.

[63] 수신기(404)와 클라우드 게이트웨이(406) 사이의 통신들은 근본적으로 각각의 네이티브 관리 애플리케이션(410)을 래핑하는 MDX 프레임워크(414)로부터 관리 채널을 확장한다. MDX 프레임워크(414)는 수신기(404)로부터 정책 정보를 요청하며, 수신기(404)는 차례로 클라우드 게이트웨이(406)로부터 정책 정보를 요청한다. MDX 프레임워크(414)는 인증을 요청하며, 수신기(404)는 클라우드 게이트웨이(406)(이는 또한 NetScaler Access Gateway로서 공지됨)의 게이트웨이 서비스 부분에 로그인한다. 이하에서 더 완전히 설명되는 바와같이, 수신기(404)는 또한 로컬 데이터 볼트(vault)들(416)에 대한 암호화 키들을 유도하기 위한 입력 자료를 생성하거나 또는 PKI 보호 자원들에 직접 인증을 인에이블할 수 있는 클라이언트 인증서들을 제공할 수 있는 서비스들을 클라우드 게이트웨이(406)상에서 지원할 것을 호출할 수 있다.

[64] 더 상세히, MDX 프레임워크(414)는 각각의 관리 애플리케이션(410)을 래핑한다. 이는 명시적 구축 단계를 통해 또는 구축후 프로세싱 단계를 통해 통합될 수 있다. MDX 프레임워크(414)는 애플리케이션(410)의 제 1 론치시 수신기(404)와 "페어링"하여, 보안 IPC 채널을 초기화하고 그 애플리케이션에 대한 정책을 획득할 수 있다. MDX 프레임워크(414)는 국부적으로 적용하는 정책의 관련 부분들, 예컨대 로컬 OS 서비스들이 어떻게 사용될 수 있는지 또는 로컬 OS 서비스들이 애플리케이션(410)과 어떻게 상호작용할 수 있는지를 한정하는 억제 정책들 중 일부 및 수신기 로그인 종속성들을 시행할 수 있다.

[65] MDX 프레임워크(414)는 인증 및 내부 네트워크 액세스를 용이하게 하기 위하여 보안 IPC 채널(412)을 통해 수신기(404)에 의해 제공된 서비스들을 사용할 수 있다. 사설 및 공유 데이터 볼트들(416)(컨테이너들)의 키 관리는 또한 관리 애플리케이션들(410)과 수신기(404) 간의 적절한 상호작용들에 의해 관리될 수 있다. 볼트들(416)은 온라인 인증 이후에만 이용가능하게 만들어질 수 있거나 또는 정책에 의해 허용되는 경우에 오프라인 인증 이후에 이용가능하게 만들어질 수 있다. 볼트들(416)의 첫번째 사용은 온라인 인증을 요구할 수 있으며, 오프라인 액세스는 온라인 인증이 다시 요구되기 전에 최대 정책 리프레시 기간으로 제한될 수 있다.

[66] 내부 자원들에의 네트워크 액세스는 액세스 게이트웨이(406)를 통해 개별 관리 애플리케이션들(410)로부터 직접 발생할 수 있다. MDX 프레임워크(414)는 각각의 애플리케이션(410) 대신에 네트워크 액세스를 조정하는 것을 담당한다. 수신기(404)는 온라인 인증 이후에 획득된 적절한 시간 제한된 2차 크리덴셜들을 제공함으로써 이들 네트워크 연결들을 용이하게 할 수 있다. 리버스 웹 프록시 연결들 및 엔드-투-엔드 VPN-스타일 터널들(418)과 같은 다수의 네트워크 연결 모드들이 사용될 수 있다.

[67] 메일 및 브라우저 관리 애플리케이션들(410)은 특별한 상태를 가지며, 임의적 래핑된 애플리케이션들이 일반적으로 이용가능하지 않을 수 있는 시설들을 사용할 수 있다. 예컨대, 메일 애플리케이션은 전체 AG 로그온을 요구하지 않고 연장된 시간 기간 동안 그 메일 애플리케이션이 익스체인지에 액세스하도록 하는 특별한 백그라운드 네트워크 액세스 메커니즘을 사용할 수 있다. 브라우저 애플리케이션은 상이한 종류의 데이터를 분리하기 위하여 다수의 사설 데이터 볼트들을 사용할 수 있다.

[68] 이러한 아키텍처는 다양한 다른 보안 특징들의 통합을 지원한다. 예컨대, 일부 경우들에서, 클라우드 게이트웨이(406)(자신의 게이트웨이 서비스들을 포함함)는 AD 패스워드들을 검증할 필요가 없을 것이다. 일부 상황들에서 AD 패스워드가 일부 사용자들에 대한 인증 인자로서 사용될 수 있는지는 기업의 재량으로 맡겨질 수 있다. 상이한 인증 방법들은 사용자가 온라인인 경우 또는 오프라인인 경우에 (즉, 네트워크에 연결되거나 또는 연결되지 않는 경우에) 사용될 수 있다.

[69] 스텝 업(step up) 인증은 클라우드 게이트웨이(406)가 강한 인증을 요구하는 높게 분류된 데이터에 대해 액세스하도록 허용되는 관리 네이티브 애플리케이션들(410)을 식별할 수 있고 비록 이것이, 재인증이 이전의 약한 로그인 레벨 이후에 사용자에 의해 요구되는 것을 의미할지라도, 적절한 인증을 수행한 이후에만 이들 애플리케이션들에 대한 액세스가 허용되도록 하는 것이 특징이다.

[70] 이러한 솔루션의 다른 보안 특징은 모바일 디바이스(402)상의 데이터 볼트들(416)(컨테이너들)의 암호화이다. 볼트들(416)은 파일들, 데이터베이스들, 및 구성들을 포함하는 모든 온-디바이스 데이터가 보호되도록 암호화될 수 있다. 온라인 볼트들의 경우에 키들이 서버(클라우드 게이트웨이(406))에 저장될 수 있으며, 오프-라인 볼트들의 경우에 키들의 로컬 복사본이 사용자 패스워드에 의해 보호될 수 있다. 데이터가 보안 컨테이너(416)에서 디바이스(402)상에 국부적으로 저장될 때, AES 256 암호화 알고리즘이 최소로 활용되는 것이 바람직하다.

[71] 다른 보안 컨테이너 특징들이 또한 구현될 수 있다. 예컨대, 애플리케이션(410)내에서 발생하는 모든 보안 이벤트들이 로깅되어 백엔드에 보고되는 로깅 특징이 포함될 수 있다. 데이터 지움이 지원될 수 있고, 예컨대 애플리케션(410)이 탬퍼링(tampering)을 검출하면 연관된 암호화 키들이 랜덤 데이터로 쓰여질 수 있으며, 따라서 사용자 데이터가 파괴된 파일 시스템상에는 힌트가 남겨지지 않는다. 스크린샷 보호(screenshot protection )는 임의의 데이터가 스크린샷들에 저장되는 것을 애플리케이션이 방지할 수 있는 다른 특징이다. 예컨대, 키 윈도우의 은폐 특성은 YES로 세팅될 수 있다. 이는 스크린상에 현재 디스플레이되고 있는 모든 콘텐츠가 은폐되도록 할 수 있으며, 따라서 임의의 콘텐츠가 정상적으로 상주할 블랭크 스크린샷을 초래한다.

[72] 로컬 데이터 전달은 예컨대 임의의 데이터가 애플리케이션 컨테이너 외부로 국부적으로 전달되는 것을 방지함으로써, 예컨대 임의의 데이터를 복사하거나 또는 이를 외부 애플리케이션에 송신함으로써 방지될 수 있다. 키보드 캐시 특징은 민감한 텍스트 필드들에 대한 자동보정 기능을 디스에이블하도록 동작할 수 있다. SSL 인증 검증은 동작가능할 수 있으며, 따라서 애플리케이션은 그것이 키체인에 저장되는 대신에 서버 SSL 인증서를 상세하게 검증한다. 암호화 키 생성 특징은 (오프라인 액세스가 요구되는 경우에) 디바이스상의 데이터를 암호화하기 위하여 사용되는 키가 사용자에 의해 공급되는 패스프레이즈(passphrase)를 사용하여 생성되도록 사용될 수 있다. 이는 오프라인 액세스가 요구되지 않는 경우에 서버측에서 랜덤하게 생성되어 저장되는 다른 키들과 XOR 연산될 수 있다. 키 유도 함수들은 사용자 패스워드로부터 생성된 키들이 키의 암호 해시를 생성하는 것보다 오히려 KDF들(키 유도 함수들, 특히 PBKDF2)을 사용하도록 동작할 수 있다. 후자는 무차별 대입 공격(brute force attack) 또는 디렉토리 공격에 취약한 키를 만든다.

[73] 추가로, 하나 이상의 초기화 벡터들이 암호화 방법들에서 사용될 수 있다. 초기화 벡터는 동일한 암호화된 데이터의 다수의 복사본들이 상이한 암호 텍스트 출력을 초래하도록 할 것이며, 따라서 리플레이 및 암호해독 공격들이 방지된다. 이는 또한 데이터를 암호화하기 위하여 사용되는 특정 초기화 벡터가 알려지지 않은 경우에 암호화 키가 도난당했을지라도 공격자가 임의의 데이터를 암호해독하는 것을 방지할 것이다. 추가로, 인증 및 이후 암호해독이 사용될 수 있으며, 여기서 사용자가 애플리케이션 내에서 인증된 이후에만 애플리케이션 데이터가 암호해독된다. 다른 특징은 필요할 때만 (디스크가 아니라) 메모리에서 유지될 수 있는, 메모리내의 민감 데이터와 관련될 수 있다. 예컨대, 로그인 크리덴션들은 로그인 이후에 메모리로부터 지워질 수 있으며, 암호화 키들 및 목적-C 인스턴스 변수들 내의 다른 데이터가 저장되지 않는데, 왜냐하면 이들 데이터는 용이하게 참조될 수 있기 때문이다. 대신에, 메모리는 이들을 위해 수동으로 할당받을 수 있다.

[74] 인액티비티 타임아웃(inactivity timeout)이 구현될 수 있으며, 여기서 인액티비티의 정책-정의된 기간 이후에 사용자 세션이 종료된다.

[75] MDX 프레임워크(414)로부터의 데이터 누출은 다른 방식들로 방지될 수 있다. 예컨대, 애플리케이션(410)이 배경으로 될 때, 메모리는 미리 결정된(구성가능) 시간 기간 이후에 클리어(clear)될 수 있다. 배경화 될 때, 전경화 프로세스(foregrounding process)를 고정시키기 위하여 애플리케이션의 마지막으로 디스플레이된 스크린에서 스탭샵이 취해질 수 있다. 스크린샵은 컨피덴셜 데이터를 포함할 수 있고 따라서 클리어되어야 한다.

[76] 다른 보안 특징은 하나 이상의 애플리케이션들에 액세스하기 위해 AD(active directory)(422) 패스워드를 사용하지 않고 OTP(one time password)(420)를 사용하는 것과 관련된다. 일부 경우들에서, 일부 사용자들은 그들의 AD 패스워드를 알지못하며(또는 그들의 AD 패스워드를 알도록 허용되지 않으며) 따라서 이들 사용자들은 OTP(420)를 사용하여, 예컨대 SecurID와 같은 하드웨어 OTP 시스템을 사용하여 인증할 수 있다(OTP들은 또한 Entrust 또는 Gemalto와 같은 상이한 벤더들에 의해 제공될 수 있다). 일부 경우들에서, 사용자가 사용자 ID로 인증한 이후에, 텍스트가 OTP(420)와 함께 사용자에게 송신된다. 일부 경우들에서, 이는 프롬프트가 단일 필드인 경우에 단지 온라인 사용을 위해서만 구현될 수 있다.

[77] 오프라인 패스워드는 기업 정책을 통해 오프라인 사용이 허락되는 애플리케이션들(410)에 대한 오프라인 인증을 위하여 구현될 수 있다. 예컨대, 기업은 기업 애플리케이션 스토어가 이러한 방식으로 액세스되는 것을 원할 수 있다. 이러한 경우에, 수신기(404)는 사용자가 맞춤형 오프라인 패스워드를 세팅할 것을 요구할 수 있으며, AD 패스워드는 사용되지 않는다. 클라우드 게이트웨이(406)는 표준 윈도우즈 서버 패스워드 복잡성 요건들이 수정될 수 있을 지라도 이 요건들에 의해 기술되는 것과 같은 최소 길이, 캐릭터 클래스 구성(character class composition) 및 패스워드들의 수명에 대해 패스워드 표준들을 제어하고 시행하기 위한 정책들을 제공할 수 있다.

[78] 다른 특징은 (MDX 마이크로 VPN 특징을 통해 PKI 보호 웹 자원들에 액세스하기 위한) 2차 크리덴셜들로서 특정 애플리케이션들(410)에 대한 클라이언트측 인증서를 인에이블하는 것과 관련된다. 예컨대, @WorkMail 와 같은 애플리케이션은 이러한 인증서를 활용할 수 있다. 이러한 경우에, ActiveSync 프로토콜를 사용한 인증서-기반 인증이 지원될 수 있으며, 여기서 수신기(404)로부터의 인증서는 클라우드 게이트웨이(406)에 의해 리트리브되고 키체인으로 사용될 수 있다. 각각의 관리 애플리케이션은 클라우드 게이트웨이(406)에서 정의되는 라벨에 의해 식별되는 하나의 연관된 클라이언트 인증서를 가질 수 있다.

[79] 클라우드 게이트웨이(406)는 관련된 관리 애플리케이션들이 내부 PKI 보호 자원들을 인증하도록 클라이언트 인증서들을 발행하는 것을 지원하기 위하여 기업 특수 목적 웹 서비스와 상호작용할 수 있다.

[80] 수신기(404) 및 MDX 프레임워크(414)는 내부 PKI 보호 네트워크 자원들을 인증하기 위한 클라이언트 인증서들을 획득하여 사용하는 것을 지원하도록 시행될 수 있다. 예컨대 보안 및/또는 분리 요건들의 다양한 레벨들을 매칭시키기 위하여 2개 이상의 인증서가 지원될 수 있다. 인증서들은 메일 및 브라우저 관리 애플리케이션들에 의해, 궁극적으로 임의적 래핑된 애플리케이션들에 의해 사용될 수 있다 (MDX 프레임워크가 HTTPS 요청들을 중재하는 것이 타당한 웹 서비스 스타일 통신 패턴들을 이들 애플리케이션들이 사용하는 경우에).

[81] iOS상에서의 MDX 클라이언트 인증서 지원은 각각의 사용 기간 동안 각각의 관리 애플리케이션에서 PKCS 12 BLOB (Binary Large Object)를 iOS 키체인에 임포트(import)하는 것에 의존할 수 있다. MDX 클라이언트 인증서 지원은 사설 인-메모리 키 스토리지(private in-memory key storage)를 가진 HTTPS 구현을 사용할 수 있다. 클라이언트 인증서는 iOS 키체인에서 결코 제시되지 않을 것이며 그리고 강하게 보호되는 "온라인-전용" 데이터 값을 잠재적으로 제외하고 지속되지 않을 것이다.

[82] 상호 SSL은 또한 모바일 디바이스(402)가 기업에게 인증될 것을 요구함으로써 추가 보안을 제공하도록 구현될 수 있으며, 이와 반대의 경우도 마찬가지다. 클라우드 게이트웨이(406)에 인증하기 위한 가상 스마트 카드들이 또한 구현될 수 있다.

[83] 제한된 그리고 전체 케베로스 지원 둘다가 추가 특징들일 수 있다. 전체 지원 특징은 AD 패스워드 또는 신뢰성 있는 클라이언트 인증서를 사용하여 AD(422)에 대해 전체 케베로스 로그인을 수행하고 HTTP 교섭 인증 챌린지(challenge)들에 응답하기 위하여 케베로스 서비스 티켓들을 획득하는 능력과 관련된다. 제한된 지원 특징은 AFEE에서의 강제 위임(constrained delegation)과 관련되며, 여기서 AFEE는 케베로스 프로토콜 전환을 인보크하는 것을 지원하며, 따라서 이는 HTTP 교섭 인증 챌린지들에 응답하여 (강제 위임 대상인) 케베로스 서비스 티켓들을 획득하여 사용할 수 있다. 이러한 메커니즘은 리버스 웹 프록시(CVPN으로도 지칭됨) 모드에서 그리고 HTTP(HTTPS가 아님) 연결들이 VPN 및 마이크로 VPN 모드에서 프록시될 때 작동한다.

[84] 다른 특징은 애플리케이션 컨테이너 로킹 및 지움과 관련되며, 이는 자일-브레이크(jail-break) 또는 루팅 검출시 자동적으로 발생하며 관리 콘솔로부터의 푸시 커맨드(pushed command)로서 발생할 수 있으며 그리고 애플리케이션(410)이 실행되지 않을 때 조차 원격 지움 기능을 포함할 수 있다.

[85] 기업 애플리케이션 스토어 및 애플리케이션 제어기의 멀티-사이트 아키텍처 또는 구성이 지원될 수 있으며, 이는 사용자들로 하여금 실패의 경우에 여러 상이한 위치들 중 하나의 위치로부터 서비스받도록 한다.

[86] 일부 경우들에서, 관리 애플리케이션들(410)은 API(예시적인 OpenSSL)를 통해 인증서 및 개인 키에 액세스하도록 허용될 수 있다. 기업의 신뢰성 있는 관리 애플리케이션들(410)은 애플리케이션의 클라이언트 인증서 및 개인 키를 사용하여 특정 공개 키 동작들을 수행하도록 허용될 수 있다. 따라서, 예컨대, 애플리케이션이 브라우저와 같이 동작하며 인증서 액세스가 요구되지 않을 때, 애플리케이션이 "나는 누구인가"에 대한 인증서를 판독할 때, 애플리케이션이 보안 세션 토큰을 구축하기 위하여 인증서를 사용할 때, 그리고 애플리케이션이 중요한 데이터에 대한 디지털 서명(예컨대, 트랜잭션 로그)을 위해 또는 일시적 데이터 암호화를 위해 개인 키들을 사용할 때, 다양한 사용의 경우들이 식별되어 처리될 수 있다.

[87] 기업 시스템들에서 사용자 및 디바이스 인증

[88] 도 5 및 도 6은 기업 시스템들에서 클라이언트 디바이스들을 인증하는 특징들 및 방법들의 다양한 예들을 예시하는 흐름도들이다. 도 5 및 도 6를 참조로 하여 이하에서 설명된 특징들 및 방법들은 도 1 및 도 2에 도시된 다양한 컴퓨팅 디바이스들 및 시스템들과 같은 컴퓨팅 디바이스 또는 디바이스들의 조합에 의해 수행될 수 있거나, 도 3 및 도 4에 도시된 예시적인 모빌리티 관리 시스템들과 같은 다양한 상이한 타입들의 기업 시스템들 또는 임의의 다른 기업 시스템(즉, 자원들에 대한 액세스를 제공할 때 인증을 요구하는 임의의 컴퓨팅 디바이스) 내에서 구현될 수 있다. 도 5 및 도 6은 사용자들이 원격 클라이언트 디바이스들을 통해 기업 시스템에 액세스하도록 하기 위하여 기업 시스템에 의한 인증 및 자원 액세스 제어에 관한 것이다. 예컨대, 모바일 디바이스(302 또는 402)의 사용자는 액세스 게이트웨이(360 또는 406)를 통해 기업 시스템과 통신하고, 사용자의 아이덴티티를 검증하기 위하여 인증 크리덴셜들을 제공하며, 이후 기업 시스템의 다양한 자원들 및 서비스들을 요청하고 이에 액세스할 수 있다.

[89] 도 5 및 도 6을 참조로 하여 설명된 다양한 실시예들 및 예들은 기업 시스템들에서 사용자들에게 인증 및 자원 액세스 제어하기 위한 여러 특징들 및 가능한 장점들을 포함할 수 있다. 이하에서 더 상세히 설명되는 바와같이, 특정 실시예들은 사용자들이 자신들의 디바이스들에 인증 크리덴셜들을 덜 자주 입력하도록 할 수 있으며, 일부 경우들에서, 단순화된 사용자 시크릿이 사용자의 완전한 인증 크리덴셜들(예컨대, 사용자이름/패스워드) 대신에 입력될 수 있으며, 이는 디바이스 사용자들 및 특히 모바일 디바이스 사용자들에게 편리성을 제공하고 시간을 절약할 수 있다. 부가적으로, 사용자 인증 및 자원 액세스 제어 기능에 대한 증가된 융통성(flexibility)이 제공될 수 있으며, 따라서 특정 인증 크리덴셜들 및/또는 인증 요청들은 특정 기업 서비스들 및 자원들 및/또는 특정 시간 기간들과 연관될 수 있다. 또한, 기업 시스템 보안은 다양한 실시예들 및 예들로 강화되어, 사용자 패스워드들과 같은 보안 크리덴셜들이 사용자에 의해 덜 자주 입력될 수 있고 (또는 전혀 입력되지 않을 수 있고) 클라이언트 디바이스에 저장될 필요가 없을 때 클라이언트 디바이스 또는 통신 네트워크가 손상되는 경우에 사용자 및 시스템을 보호할 수 있다.

[90] 도 5를 참조하면, 클라이언트 디바이스(예컨대, 모바일 디바이스(302 및/또는 402)) 및 인증 디바이스(예컨대, 인증 서비스(358) 및/또는 클라우드 게이트웨이(406))가 기업 시스템의 사용자를 인증(즉, 검증)하여 검증된 사용자로 하여금 기업 시스템의 자원들 및 서비스들에 액세스하도록 통신하는 예시적인 방법이 제시된다.

[91] 단계(501)에서, 제 1 인증 요청은 클라이언트 디바이스, 예컨대 모바일 디바이스(302 또는 402)에 의해 개시된다. 제 1 인증 요청은 클라이언트 디바이스(302)상에서 실행되는 보안 또는 비보안 애플리케이션, 예컨대 콘솔 애플리케이션, 모바일 애플리케이션 또는 웹 브라우저 또는 다른 웹-기반 애플리케이션을 사용하여 클라이언트 디바이스(302)에 의해 기업 시스템에 로그인을 시도하는 것일 수 있다. 클라이언트 디바이스(302)의 사용자는 클라이언트 디바이스(302)의 입력 인터페이스 및/또는 입력 디바이스를 사용하여 인증 크리덴셜들을 입력할 수 있다. 예컨대, 사용자는 키보드 또는 터치 스크린을 사용하여 클라이언트 디바이스(302)에 사용자 식별자 및 패스워드를 입력할 수 있으며, 이러한 사용자 식별자 및 패스워드는 기업 시스템의 액세스 게이트웨이(360)에 암호화하여 그리고/또는 보안적으로 전송될 수 있다. 액세스 게이트웨이(360)는 보안 서버일 수 있으며, (도 3 및 도 4에 도시된 바와같이) 하나 이상의 개별 컴퓨팅 디바이스들로서 구현될 수 있거나 또는 대안적으로 자원들 또는 서비스들을 제공하는 서버 또는 다른 컴퓨팅 디바이스(예컨대, 이메일 서버, 웹 애플리케이션 서버 등)내에서 구현될 수 있다. 액세스 게이트웨이(360)는 다양한 추가 인증 기술들, 예컨대 패스워드-기반, 토큰-기반 (예컨대, 스마트 카드들, 자기 스트립 카드들), 생체인증(예컨대, 지문, 성문, 홍채, 망막 스캐닝) 등을 지원할 수 있다. 단계(501)에서의 인증은 싱글-팩터(single-factor) 또는 멀티-팩터(multi-factor)일 수 있으며, 다수의 인증 단계들(예컨대, 챌린지 질문(challenge question)들) 및 상호 인증 기술들을 포함할 수 있다.

[92] 단계(502)에서, 인증 디바이스(358)는 클라이언트 디바이스(302)로부터 인증 요청을 수신하며, 사용자가 기업 시스템의 하나 이상의 자원들 또는 서비스들에 액세스하는 것이 허락된 유효 시스템 사용자임을 확인하기 위하여 사용자의 인증 크리덴셜들을 검증한다. 이러한 예에서, 인증 디바이스(358)는 인증 서비스(358)가 실행되는 컴퓨팅 디바이스(들)를 지칭할 수 있다. 도 3에 예시된 바와같이, 액세스 게이트웨이(360)는 모바일 디바이스(302)로부터 로그인 요청을 수신하고, 로그인 요청을 인증 서비스(358)에 포워드할 수 있으며, 이 인증 서비스(358)는 사용자의 크리덴셜들을 검증하고 사용자가 허가된 기업 자원들 또는 서비스들의 세트에 대하 사용자 액세스를 승인한다. 인증 서비스(358)는 하나 이상의 전용 컴퓨팅 디바이스들(358)상에서, 즉 다른 기업 서비스들(308) 및/또는 자원들(304)을 지원하는 공유된 컴퓨팅 디바이스들(358)상에서 구현될 수 있거나 또는 액세스 게이트웨이(360)내에서 구현될 수 있다. 이들 예들에서, 인증 디바이스(358)는 사용자에 의해 인증 서비스, 예컨대 액티브 디렉토리(422)에 입력된 크리덴셜들을 제시함으로써 사용자들을 검증(즉, 인증)하도록 구성될 수 있으며, 이는 사용자의 크리덴셜들의 자신들의 정확성/검증을 해결할 수 있다.

[93] 사용자의 크리덴셜들이 단계(502)에서 성공적으로 검증된 이후에, 사용자는 기업 시스템에 로그인될 수 있으며, 기업 시스템 내의 자원들(304) 또는 서비스들(308)에 대한 액세스가 승인될 수 있다. 단계(502)에서의 사용자의 검증은 기업 시스템의 설계에 따라 선택적일 수 있다. 부가적으로, 특정 예들에서, 사용자는 일부 자원들(304) 및 서비스들(308)에 액세스하도록 허가될 수 있으나, 기업 시스템의 다양한 자원들(304) 및 서비스들(308)에 대한 사용자의 퍼미션들에 따라 다른 것들에 액세스하도록 허가되지 않을 수도 있다.

[94] 이러한 예에서, 사용자가 단계(502)에서 검증된 이후에, 사용자는 미래의 자원 액세스 요청들에서 사용될 "사용자 시크릿"을 클라이언트 디바이스(302)에 입력하도록 단계(503)에서 프롬프트될 수 있다. 다른 예들에서, 사용자들은 단계(501)에서의 제 1 인증 요청 및 단계(502)에서의 검증 전에, 이 이후에 또는 이와 동시에 사용자 시크릿들을 입력하도록 프롬프트될 수 있다. "사용자 시크릿"은 사용자에 의해 클라이언트 디바이스(302)에 입력된 "사용자 시크릿"은 개인 식별 번호(PIN), 터치 스크린 제스처, 생체인증 데이터, 발음 구절(spoken phrase) 또는 시각 이미지 또는 다른 데이터일 수 있다. 단계(503)에서, 사용자들은 자신들의 사용자 시크릿을 입력하기 전에 사용자 시크릿 타입(예컨대, 텍스트, PIN, 제스처, 패스워드, 발음 구절, 생체인증 등)을 선택하도록 허용될 수 있다. 다른 예들에서, 사용자 시크릿 타입은 클라이언트 디바이스(302)의 물리적 능력들에 기초하여 자동적으로 선택될 수 있으며, 사용자는 선택된 타입의 사용자 시크릿을 입력하도록 프롬프트될 수 있다. 예컨대, 만일 클라이언트 디바이스(302)가 터치 스크린을 가진 모바일 폰, PDA, 또는 태블릿 컴퓨터이면, 사용자는 사용자 시크릿으로서 터치 스크린 제스처를 입력하도록 프롬프트될 수 있다. 만일 클라이언트 디바이스(302)가 마이크로폰 및 오디오 프로세싱 소프트웨어를 포함하면, 사용자는 워드 또는 구문을 사용자 시크릿을 말하도록 프롬프트될 수 있다. 유사하게, 만일 클라이언트 디바이스(302)가 카메라를 포함하면, 사용자 시크릿은 사용자의 얼굴의 이미지, 사용자 집 또는 사무실의 아이템, 또는 사용자에 의해 선택된 다른 객체일 수 있다. 사용자 시크릿들의 다른 예들은 키보드들을 통해 입력된 텍스트 패스워드들, 키보드들 또는 숫자 키패드들을 통해 입력된 PIN들을 포함할 수 있으며 그리고/또는 다양한 생체인증 데이터(예컨대, 지문들, 홍채 스캔들 등) 또는 시각적 이미지들 등으로부터 유도될 수 있다.

[95] 일부 예들에서, 사용자 시크릿들은 기업 시스템에 로그인하기 위하여 사용자들로부터 요구된 인증 크리덴셜들(예컨대, 사용자이름 및 패스워드)과 상이할 수 있고 그리고/또는 이보다 더 단순할 수 있다. 많은 시스템들은 강력한 사용자 패스워드들, 예컨대 최소 길이, 복잡성 및/또는 예측 불가능성을 가진 패스워드들을 요구한다. 이러한 패스워드들은 특히 통상적인 키보드들이 없는 디바이스들, 예컨대 모바일 폰들, PDA들, 및 태블릿 컴퓨터들에서는 사용자들이 입력하기에는 싫증이 날 수 있다. 대조적으로, 일부 실시예들에서, 사용자 시크릿은 패스워드보다 더 짧고 더 단순하여 클라이언트 디바이스(302)에 입력하기가 더 빠르게 될 수 있다. 부가적으로, 사용자가 단계(501)에서 입력된 사용자 패스워드와 상이한 사용자 시크릿을 선택하는 것은 선택적이거나 또는 심지어 요구될 수 있다. 따라서, 만일 사용자의 시크릿이 (예컨대, 클라이언트 디바이스(302)의 악성코드에 의해) 손상되면, 사용자의 패스워드는 계속해서 보호될 수 있으며, 기업 시스템의 전체 보안이 강화될 수 있다.

[96] 단계(503)에서, 클라이언트 디바이스(302) 내의 소프트웨어 및/또는 기업 시스템의 소프트웨어는 사용자 시크릿을 입력하도록 클라이언트 디바이스(302)의 사용자에게 프롬프트하는 기능을 개시할 수 있다. 예컨대, 인증 디바이스(358)는 단계(502)에서 사용자의 크리덴셜들의 성공적인 검증에 응답하여 시크릿을 입력하도록 사용자에게 프롬프트하는 기능을 개시할 수 있다. 이러한 예에서, 인증 디바이스(358)는 먼저 클라이언트 디바이스(302)에 사용자 시크릿이 사전에 세팅되어 있는지의 여부를 결정할 수 있으며, 만일 사용자 시크릿이 사전에 세팅되어 있지 않으면 사용자 시크릿을 입력하도록 사용자에게 프롬프트할 수 있다. 클라이언트 디바이스(302)는 또한 사용자 시크릿을 입력하도록 사용자에게 프롬프트하는 기능을 개시할 수 있다. 예컨대, 수신기 애플리케이션(404)(또는 다른 클라이언트-기반 애플리케이션(410))은 기업 시스템에 대한 미래의 자원 액세스 요청들을 단순화하기 위하여 사용자가 사용자 시크릿을 입력해야 함을 제안할 수 있다. 수신기(404) 또는 다른 클라이언트 애플리케이션(410)은 먼저 사용자가 사용자 시크릿을 사전에 입력해야 하는지의 여부를 결정할 수 있으며 그리고/또는 사용자 시크릿을 입력하도록 사용자에게 프롬프트하기 전에 클라이언트 디바이스(302)가 공유된 디바이스가 아님을 사용자에게 확인할 수 있다. 일부 예들에서, 사용자 시크릿은 제 1 인증 요청과 동시에 수신 및 전송될 수 있다. 따라서, 단계들(501 및 503)은 단일 단계로 결합될 수 있으며, 유사하게 단계들(502 및 504)은 단일 단계로 결합될 수 있다. 부가적으로, 이하에서 더 상세히 논의되는 바와같이, 사용자 시크릿들은 선택적일 수 있으며, 일부 실시예들에서 지원될 필요가 없으며, 따라서 단계들(503 및 504)은 일부 예들에서 수행될 필요가 없다.

[97] 단계(504)에서, 기업 시스템의 인증 디바이스(358)는 클라이언트 디바이스(302)로부터 사용자 시크릿을 수신할 수 있으며, 클라이언트 디바이스(302)로부터의 미래의 자원 액세스 요청들을 위해 사용될 액세스 토큰 및 검증 데이터를 생성할 수 있다. 일부 예들에서, 클라이언트 디바이스(302)는 인증 서비스(358)에 콜(call)을 개시하여, 단계(503)에서 입력된 사용자 시크릿을 인증 서비스에 전달할 수 있다. 클라이언트 디바이스(302)는 또한 클라이언트 디바이스(302)가 기업 시스템에 현재 로그인되는 것을 확인하는 추가 데이터, 예컨대 세선 쿠키 또는 토큰을 인증 서비스(358)에 전달할 수 있다.

[98] 이후, 인증 디바이스(358)는 (예컨대, 인증 디바이스(358), 액세스 게이트웨이(360) 또는 기업 시스템내의 다른 위치내에) 기업 시스템에 의해 저장될 검증 데이터를 생성할 수 있으며, 단계(505)에서 클라이언트 디바이스(302)에 전송될 액세스 토큰을 생성할 수 있다. 이하에서 논의된 바와같이, 액세스 토큰 및 검증 데이터는 클라이언트 디바이스(302)로부터 기업 시스템으로의 미래의 요청들을 위해 사용될 수 있다. 일부 실시예들에서, 액세스 토큰은 인증 디바이스(358)에 의해 생성되거나 또는 키 생성기에 의해 수신된 암호 키(예컨대, 암호화 또는 암호해독 키)를 포함할 수 있으며, 검증 데이터는 사용자 및/또는 클라이언트 디바이스에 대응하는 키 식별자; 사용자의 현재 패스워드 또는 다른 인증 크리덴셜들; 및 단계(503)에서 입력된 사용자의 시크릿 중 하나 이상을 암호화하기 위하여 암호 키를 사용하여 인증 디바이스(358)에 의해 생성될 수 있다. 키 식별자는 사용자 식별자(예컨대, 사용자이름 또는 로그인)일 수 있거나 또는 정확한 검증 데이터를 로케이팅하기 위하여 사용되는 테이블 인덱스와 같은 개별 식별자일 수 있다.

[99] 도 7a를 참조하면, 단계(504)에서 인증 디바이스(358)에 의해 검증 데이터(710) 및 액세스 토큰(705)을 생성하기 위한 예가 도시된다. 이러한 예에서, 인증 디바이스는 단계(503)에서 사용자에 의해 입력된 키 식별자(701)(예컨대, 사용자의 검증 데이터에 대응하는 사용자이름 또는 테이블 인덱스), 사용자의 패스워드(702) 및 사용자 시크릿(703)을 수집한다. 사용자의 패스워드(702)는 패스워드, 토큰(예컨대, SAML(Security Assertion Markup Language) 토큰) 또는 사용자 크리덴셜 데이터를 포함할 수 있다. 인증 디바이스(358)는 인증 디바이스(358)에 의해 생성되거나 또는 기업 시스템내의 암호화 키 생성기로부터 수신될 수 있는 암호 키(705)를 사용하여 이러한 데이터를 암호화한다. 결과적인 암호화된 데이터는 단계(505)에서 기업 시스템내에 저장될 수 있고 사용자로부터의 미래의 요청들을 인증하기 위하여 사용될 수 있는 검증 데이터(710)이다. 이러한 예에서, 인증 디바이스(358)는 또한 검증 데이터(710)를 암호화하기 위하여 사용되는 암호 키(705) 및 키 식별자(701)를 포함하는 액세스 토큰(715)을 생성한다. 단계(505)에서, 액세스 토큰(715)은 인증 디바이스(358)에 의해 클라이언트 디바이스(302)에 전송될 수 있다.

[100] 도 7a에 도시된 바와같이, 검증 데이터(710)는 키 식별자(701), 패스워드(702) 및 사용자 시크릿(703)을 암호화함으로써 생성될 수 있다. 그러나, 이러한 예들에서, 데이터의 모든 3개의 피스(piece)들은 사용될 필요가 없으며, 검증 데이터(710)는 데이터의 이들 피스들 중 하나 또는 2개의 피스만을 암호화함으로써 생성될 수 있다. 검증 데이터(710)는 또한 암호화 및 암호해독된 데이터의 조합을 포함할 수 있거나 또는 일부 예들에서 암호해독된 데이터로서 전체적으로 저장될 수 있다. 예컨대, 검증 데이터(710)는 암호화된 패스워드(702)를 암호해독된 키 식별자(701)에 첨부함으로써 일부 실시예들에서 생성될 수 있다. 유사하게, 액세스 토큰(715)은 도 7a에 도시된 바와같이 암호 키(705) 및 사용자 키(701)를 포함할 수 있거나 또는 대안적으로 암호 키(705)만을 포함할 수 있다. 액세스 토큰(715)은 또한 추가 정보, 예컨대 액세스 토큰(715)과 연관된 다수의 사용자들을 식별하는 데이터, 액세스 토큰(715)과 연관된 하나 이상의 클라이언트 애플리케이션들, 액세스 토큰(715)과 연관된 기업 자원들 및/또는 서비스들의 세트, 및 액세스 토큰(715)과 연관된 액세스 시간 기간 또는 만료일을 포함할 수 있다.

[101] 단계(506)에서, 클라이언트 디바이스(302)는 단계(505)에서 인증 디바이스(358)에 의해 전송되는 액세스 토큰(715)을 수신하여 저장한다. 앞서 논의된 바와같이, 액세스 토큰(715)은 사용자의 패스워드(702) 또는 시크릿(703)의 암호화 또는 암호해독된 복사본을 포함하지 않고 암호화/암호해독 키(705)를 포함할 수 있다. 따라서, 액세스 토큰(715)은 클라이언트 디바이스(302)내의 보안 또는 비보안 메모리에 저장될 수 있다.

[102] 단계(507)에서, 사용자는 기업 시스템에 제 2 인증 요청을 개시한다. 제 1 인증 요청과 유사하게, 제 2 인증 요청은 기업 시스템의 액세스 자원들(304) 또는 서비스들(308)에 대한 요청 및/또는 기업 시스템에 대한 로그인 시도일 수 있다. 제 2 인증 요청은 제 1 인증 요청을 수행하도록 사용되는 동일한 클라이언트 애플리케이션을 통해 또는 상이한 클라이언트 애플리케이션을 사용하여 수행될 수 있다. 예컨대, 제 1 인증 요청은 수신기 애플리케이션(404)을 사용하여 수행되는 로그인 시도일 수 있으며, 제 2 인증 요청은 특정 기업 자원들 또는 서비스들에 액세스하기 위하여 개별 클라이언트 애플리케이션(410)(예컨대, 이메일 클라이언트(410), 웹 브라우저(410) 등)에 의해 수행될 수 있다. 제 2 인증 요청은 (예컨대, 동일한 네트워크 통신 세션내에) 제 1 인증 요청 이후에 짧게 발생할 수 있거나 또는 제 1 인증 요청 이후에 (예컨대, 임의의 이전 세션 쿠키들 또는 토큰들의 만료 이후에) 길게 발생할 수 있다.

[103] 제 2 인증 요청 동안, 클라이언트 디바이스(302)는 사용자의 패스워드(또는 다른 인증 크리덴셜들) 보다 오히려, 사용자의 시크릿을 입력하도록 사용자에게 프롬프트할 수 있다. 앞서 논의된 바와같이, 사용자의 시크릿은 사용자의 패스워드 보다 더 짧고 더 간단할 수 있으며, 따라서 사용자가 기억하여 클라이언트 디바이스(302)에 빠르게 입력하기에 용이할 수 있다. 부가적으로, 사용자 시크릿은 통상적인 키보드를 통해 입력된 텍스트 스트링일 필요가 없으나, 클라이언트 디바이스(302)의 능력들 및 사용자의 선호도들(예컨대, 터치 스크린 제스처, PIN, 발음 구절 또는 생체인식 데이터 등)에 따라 다른 입력 인터페이스를 사용하여 입력될 수 있다.

[104] 단계(508)에서, 클라이언트 디바이스(302)는 디바이스 메모리에 이전에 저장된 액세스 토큰을 리트리브하고 제 2 인증 요청을 인증 디바이스(358)에 송신하며, 여기서 액세스 토큰 및 사용자 시크릿은 단계(507)에서 사용자에 의해 입력된다. 사용자 시크릿들이 사용되지 않는 실시예들에서, 제 2 인증 요청은 사용자 시크릿이 아니라 디바이스 메모리로부터 리트리브된 액세스 토큰을 포함하지 않을 수 있다. 따라서, 비록 단계(507)가 잠재적으로 일부 사용자 행동, 예컨대 클라이언트 애플리케이션(404 또는 410)을 여는 것을 수반할 수 있을지라도, 단계(507)는 특정 실시예들에서 사용자 시크릿을 입력하도록 사용자에게 프롬프트하는 것을 수반할 필요가 없다. 이러한 예들에서, 액세스 토큰은 사용자에 의한 어느 명시적 행동 없이 또는 심지어 사용자의 정보 없이 리트리브되고 인증 디바이스(358)에 제출될 수 있다.

[105] 단계(509)에서, 인증 디바이스(358)는 클라이언트 디바이스(302)로부터 제 2 인증 요청을 수신한다. 제 2 인증 요청을 수신한 이후에, 인증 디바이스(358)는 단계(504)에 이전에 저장된, 클라이언트 디바이스(302)로부터의 대응 검증 데이터를 리트리브할 수 있다. 예컨대, 만일 제 2 인증 요청이 키 식별자(701)를 포함하면, 인증 디바이스(358)는 사용자 및/또는 클라이언트 디바이스(302)에 대응하는 검증 데이터(710)를 찾아서 리트리브하기 위하여 키 식별자(701)를 사용할 수 있다. 키 식별자(701)는 특정 기업 사용자/로그인, 특정 클라이언트 디바이스(302) 또는 사용자 및 디바이스의 조합과 연관될 수 있다. 예컨대, 만일 기업 시스템의 다른 사용자가 다수의 클라이언트 디바이스들(예컨대, 데스크탑 컴퓨터, 랩탑 컴퓨터 및 하나 이상의 모바일 디바이스들)을 가지면, 각각의 클라이언트 디바이스는 개별 키 식별자(701) 및/또는 개별 액세스 토큰(715)을 가질 수 있다. 부가적으로, 사용자 시크릿들의 입력 타입들이 클라이언트 디바이스의 능력들(예컨대, 터치 스크린 제스처들, 음성 인식, 생체인식 입력)에 기초할 수 있기 때문에, 일부 사용자들이 자신들의 상이한 디바이스들에 대해 상이한 사용자 시크릿들을 설정하는 것이 바람직할 수 있다. 이들 예들에서, 인증 디바이스(358)는 제 2 인증 요청이 수신되었던 사용자 및/또는 클라이언트 디바이스(302)에 대응하는 적절한 검증 데이터(710)를 찾아서 리트리브하기 위하여 키 식 별자(701) 및/또는 사용자 시크릿(703)을 사용할 수 있다.

[106] 단계(510)에서, 인증 디바이스는 제 2 인증 요청에서 수신된 액세스 토큰(715)을 사용하여 검증 데이터(710)를 암호해독하는 것을 시도한다. 앞서 논의된 바와같이, 검증 데이터(710)를 암호해독하기 위하여 사용될 수 있는 암호 키(705)는 단계(504)에서 액세스 토큰(715)내에서 클라이언트 디바이스(302)에 사전에 전송되었다. 따라서, 만일 동일한 액세스 토큰(715)이 단계(508)에서 클라이언트 디바이스로부터 리턴되면, 인증 디바이스(358)는 키(705)를 추출하여 검증 데이터를 성공적으로 암호해독할 수 있다.

[107] 도 7b를 참조하면, 클라이언트 디바이스(302)로부터 수신된 사용자 시크릿(703) 및 액세스 토큰(715)을 사용하여 인증 디바이스(358)에서 인증 요청을 검증하는 예가 도시된다. 이러한 예에서, 클라이언트 디바이스(302)로부터 제 2 인증 요청을 수신한 이후에, 인증 디바이스(358)는 키 식별자(701)를 사용하여 사용자를 식별하고 기업 시스템의 메모리로부터 적절한 대응하는 검증 데이터(710)를 리트리브할 수 있다. 이후, 인증 디바이스(358)는 인증 요청으로부터 키(705)를 추출하고 키(705)를 사용하여 검증 데이터(710)를 암호해독할 수 있다. 만일 암호해독이 성공적이면, 인증 디바이스(358)는 요청과 함께 클라이언트 디바이스(302)로부터 수신된 사용자 시크릿(703)과 암호해독된 검증 데이터로부터의 사용자 시크릿(703)을 비교할 수 있다. 만일 사용자 시크릿들이 매칭되면, 인증 디바이스(358)는 사용자 시크릿(703) 및 액세스 토큰(715)이 유효하고 따라서 제 2 인증 요청이 단계(502)에서 성공적으로 검증되었던, 동일한 사용자로부터의 유효 요청임을 결정할 수 있다. 사용자 시크릿(703)이 사용되지 않는 실시예들에서, 인증 디바이스(358)는 사용자 시크릿(703)을 검증할 필요성 없이 액세스 토큰(715)을 사용한 암호해독의 검증에 기초하여 제 2 인증 요청이 유효하다고 결정할 수 있다.

[108] 도 7a 및 도 7b에 도시된 예들에서, 사용자 시크릿(703)은 검증 데이터(710)내에 저장된다. 그러나, 다른 예들에서, 사용자 시크릿은 검증 데이터(710)내에 저장될 필요가 없다. 예컨대, 검증 데이터(710)는 액세스 토큰(715)(또는 액세스 토큰(715)의 부분)을 구성하기 위하여 사용될 수 있다. 특정 실시예들에서, 키 식별자(701), 사용자 식별자 및/또는 사용자 패스워드 또는 토큰(702)은 검증 데이터(710)를 생성하기 위하여 암호 키(705)로 암호화될 수 있다. 이후, 액세스 토큰(715)은 키(705) 및 사용자 시크릿(703)에 대하여 수행되는 융합 함수(comingling function)(예컨대, 배타적 OR 함수)의 출력 및 키 식별자(701)를 사용하여 생성될 수 있다. 이러한 예들에서, (도 7b 및 단계(510)에 대응하는) 인증 요청을 검증할 때, 인증 디바이스(358)는 기업 시스템의 스토리지로부터 사용자 시크릿을 리트리브할 수 있고 사용자 시크릿을 사용하여 액세스 토큰(715)에 대하여 역 혼합 함수를 수행할 수 있으며, 이는 암호 키(705)를 리턴할 수 있다. 이후, 인증 디바이스(358)는 키 식별자(701)를 사용하여 스토리지로부터 대응 검증 데이터(710)를 리트리브하고 키(705)를 사용하여 검증 데이터(710)를 암호해독하여, 사용자 식별자 및/또는 사용자 패스워드 또는 토큰(702)을 제공할 수 있다.

[109] 비록 클라이언트 디바이스(302)로부터 수신된 사용자 시크릿(703) 및 액세스 토큰(715)이 유효할지라도, 인증 디바이스(358)는 사용자의 패스워드(702)가 변경되었거나 또는 만료된 경우에 사용자가 요청된 자원들에 액세스하는 것을 승인하지 않을 수 있다. 예컨대, 클라이언트 디바이스(302)로부터 수신된 사용자 시크릿(703) 및 액세스 토큰(715)의 검증을 확인한 이후에, 인증 디바이스(358)는 기업 시스템에 대한 검증 데이터(710)의 사용자 패스워드(702)가 여전히 최신이고 유효하다는 것을 확인하기 위하여 도메인 제어기, 액티브 디렉토리, 또는 다른 서비스와 통신하도록 구성될 수 있다. 만일 사용자의 패스워드(702)가 만료되었으면, 인증 디바이스(358)는 기업 시스템에 대한 새로운 패스워드를 입력하도록 사용자에게 프롬프트하는 기능을 개시할 수 있으며, 이 이후에, 인증 디바이스(358)는 시스템 내의 사용자의 패스워드를 업데이트할 수 있고 또한 새로운 패스워드(702)를 사용하여 새로운 검증 데이터(710)를 생성할 수 있다. 사용자의 시스템 패스워드(702)를 변경한 이후에, 인증 디바이스(358)는 또한 새로운 사용자 시크릿(703)을 생성할 것을 사용자에게 요구할 수 있거나 또는 대안적으로 사용자가 동일한 사용자 시크릿(703)을 유지하도록 할 수 있다.

[110] 인증 디바이스(358)는 또한 예컨대 사용자가 상이한 클라이언트 디바이스를 사용하여 기업 시스템에 최근에 로그인하였고 자신들의 패스워드(702)를 변경하였기 때문에 사용자의 패스워드(702)가 더이상 유효하지 않다고 결정할 수 있다. 이러한 경우에, 사용자 시크릿(703) 및 액세스 토큰(715)이 유효하나 패스워드(702)가 유효하지 않음을 확인한 이후에, 인증 디바이스(358)는 사용자의 현재 패스워드를 사용하여 클라이언트 디바이스(302)를 재인증할 것으로 사용자에게 요구할 수 있다. 사용자가 재인증한 이후에, 인증 디바이스(358)는 새로운 패스워드(702)를 사용하여 새로운 검증 데이터(710)를 생성할 수 있다. 인증 디바이스(358)는 선택적으로 새로운 시크릿(703)을 입력할 것을 사용자에게 요구할 수 있으며, 선택적으로 새로운 액세스 토큰(715)을 생성하여 클라이언트 디바이스(302)에 전송할 수 있다.

[111] 앞서 논의한 바와같이, 사용자 시크릿들은 일부 실시예들에서 선택적일 수 있다. 이러한 경우들에서, 인증 디바이스(358)에 의해 암호화된 검증 데이터는 단지 단계(502)에서 인증된 사용자에 대한 키 식별자 및/또는 패스워드만을 포함할 수 있다. 따라서, 사용자는 제 2 인증 요청을 송신하기 전에 단계(503) 또는 단계(507)에서 사용자 시크릿을 입력할 필요가 없다. 사용자 시크릿이 사용되지 않을 때, 액세스 토큰은 인증 디바이스(358)에 의해 자동적으로 생성될 수 있으며, 이후 제 1 성공 인증 요청 이후에 클라이언트 디바이스(302)에 전송될 수 있다. 이후, 액세스 토큰은 클라이언트 디바이스(302)상에 저장될 수 있으며, 사용자가 취한 어느 명시적 행동 없이 (그리고, 가능한 경우에 액세스 토큰들이 사용되고 있다고 사용자가 정확히 알지 못하고) 후속 인증 요청들에서 리트리브되어 다시 기업 시스템에 전송될 수 있다. 부가적으로, 특정 실시예들에서, 사용자 시크릿들은 (예컨대, 단계들(503 및/또는 507)에서) 사용자에 의해 입력될 수 있으나, 요청된 자원들 및 서비스들에 따라 인증 디바이스(538)에 의해 사용되거나 또는 사용되지 않을 수 있다. 사용자는 단계(503)에서 사용자 시크릿을 설정할 수 있으나, 인증 디바이스(538)는 단지 특정 자원들에 액세스하고 그리고/또는 다른 것들이 아니라 특정 행동들을 수행하기 위하여 단계(507)에서 사용자 시크릿을 재입력할 것을 사용자에게 요구할 수 있다. 예컨대, 사용자 시크릿은 사용자가 이메일을 읽거나 또는 특정 보안 문서들에 액세스하도록 하는데 요구되는 것이 아니라 이메일들을 송신하거나 또는 보안 문서들을 수정하기 위하여 요구될 수 있다.

[112] 일부 경우들에서, 액세스 토큰들 및/또는 사용자 시크릿들은 기업 시스템내에 저장될 수 있는 연관된 시간 기간들 또는 만료일들을 가질 수 있다. 이러한 경우들에서, 인증 디바이스(358)는 액세스 토큰을 포함하는 인증 요청을 수신한 이후에 연관된 시간 기간 또는 만료일을 리트리브할 수 있다. 만일 액세스 토큰이 유효하고 아직 만료되지 않았으면, 사용자는 기업 시스템의 요청된 자원들 또는 서비스들에 액세스하는 것이 승인될 수 있다. 그러나, 만일 클라이언트 디바이스(302)로부터 수신된 액세스 토큰이 만료되었거나 또는 더이상 유효하지 않으면, 인증 디바이스(358)는 사용자의 완전한 인증 크리덴셜들(예컨대, 사용자이름 및 패스워드)를 재입력할 것을 사용자에게 요구할 수 있으며, 이 시간에, 액세스 토큰은 추가 시간 기간 동안 리셋될 수 있다. 일부 실시예들에서, 사용자는 클라이언트 디바이스(302)의 이전 액세스 토큰의 만료 이후에 새로운 및 상이한 사용자 시크릿을 입력하는 것이 요구될 수 있다. 부가적으로, 액세스 토큰들은 인증 디바이스(358) 및/또는 클라이언트 디바이스(302)에 의해 명시적으로 리보크될 수 있다. 예컨대, 액세스 토큰들은 연관된 검증 데이터 엔트리들을 제거함으로써 (또는 리보크된 것으로 마킹함으로써) 인증 디바이스(358)에 의해 리보크될 수 있다. 사용자들 또는 디바이스들의 리스트들은 또한 이러한 액세스 방법이 허용되지 않는 기업 시스템에 저장될 수 있다.

[113] 특정 액세스 토큰들 및/또는 사용자 시크릿들은 또한 기업 시스템 내의 특정 자원들 또는 서비스들과 연관될 수 있다. 예컨대, 클라이언트 디바이스(302)상에 저장된 액세스 토큰은 사용자가 제 1 기업 자원(304)에 대한 액세스를 요청할 때 성공적으로 검증될 수 있으나, 사용자가 상이한 기업 자원(304)에 대한 액세스를 요청할 때 동일한 액세스 토큰은 거절될 수 있다. 이러한 예에서, 인증 디바이스(358)는 각각의 액세스 토큰/검증 데이터 쌍에 대응하는 기업 자원들 또는 서비스들의 리스트를 저장할 수 있다. 인증 디바이스(358)가 액세스 토큰과 함께 기업 자원들 또는 서비스들에 대한 요청을 수신할 때, 인증 디바이스(358)는 액세스 토큰과 연관된 기업 자원들의 리스트를 리트리브할 수 있으며, 따라서 요청을 승인하거나 또는 거절할 수 있다.

[114] 따라서, 일부 예들에서, 단일 클라이언트 디바이스(302)에 대한 다수의 상이한 액세스 토큰들이 생성되어 이 단일 클라이언트 디바이스(302)에 저장될 수 있다. 예컨대, 제 1 액세스 토큰은 특정 기업 자원들(304) 또는 서비스들(308)에 대한 요청들에 대하여 유효할 수 있는 반면에, 제 2 액세스 토큰은 다른 기업 자원들(304) 또는 서비스들(308)에 대한 요청에 대하여 유효할 수 있는 식이다. 이러한 예에서, 클라이언트 애플리케이션(예컨대, 수신기(404) 또는 애플리케이션(410))은 요청된 자원들에 따라 클라이언트 디바이스(302)의 메모리로부터 정확한 액세스 토큰을 리트리브하여 전송할 수 있다. 일부 클라이언트 애플리케이션들, 예컨대 웹 브라우저(410) 또는 이메일 클라이언트(410)가 특정 기업 자원들과 연관될 수 있기 때문에, 이들 클라이언트 애플리케이션들(410)은 모든 요청들에 대한 특정 액세스 토큰을 리트리브하여 전송하도록 구성될 수 있다. 다른 경우들에서, 클라이언트 애플리케이션은 사용자에 의해 요청되고 있는 특정 자원들(304) 또는 서비스들(308)을 식별할 수 있으며, 이후, 정확한 액세스 토큰은 디바이스 메모리로부터 리트리브될 수 있다. 게다가, 만일 단일 클라이언트 디바이스(예컨대, 데스크탑 컴퓨터 또는 모바일 디바이스)가 다수의 사용자들에 의해 공유되면, 다수의 액세스 토큰들(또는 액세스 토큰들의 다수의 세트들)은 클라이언트 디바이스(302)의 메모리에 저장될 수 있다. 이들 예들에서, 클라이언트 애플리케이션(예컨대, 수신기(404) 또는 애플리케이션(410))은 디바이스의 현재 사용자와 연관된 액세스 토큰을 리트리브하고 전송하도록 구성될 수 있다.

[115] 도 6을 지금 참조하면, 클라이언트 디바이스(예컨대, 모바일 디바이스(302 및/또는 402)), 액세스 게이트웨이(예컨대, 액세스 게이트웨이(360) 및/또는 클라우드 게이트웨이(406)), 인증 서비스(358), 및 기업 자원 또는 서비스(예컨대, 자원들(304) 및/또는 서비스들(308 또는 408))이 인증 크리덴셜들의 제 2 세트를 수락하는 기업 자원(304) 또는 서비스(308)에 대하여 인증 크리덴셜들의 제 1세트를 사용하여 사용자를 검증하기 위하여 상호작용할 수 있는 예시적인 방법이 도시된다.

[116] 단계(601)에서, 클라이언트 디바이스(302)의 사용자는 인증 크리덴셜들의 제 1 세트를 포함하는 로그인 요청을 기업 시스템에 개시한다. 단계(601)에서의 로그인 요청은 도 5에서 앞서 설명된 제 1 인증 요청(단계(501))과 유사할 수 있다. 앞서 설명된 바와같이, 로그인 요청은 클라이언트 애플리케이션, 예컨대 수신기(404) 또는 다른 애플리케이션(410)(예컨대, 이메일 클라이언트, 웹 브라우저 등)을 통해 클라이언트 디바이스(302)로부터 전송될 수 있다. 단계(601)에서의 로그인 요청은 인증 크리덴셜들의 제 1 세트, 예컨대 사용자이름 및 패스워드, 스마트 카드로부터의 데이터, 생체인증 데이터 또는 다른 타입의 사용자 인증 데이터를 포함할 수 있다. 인증 크리덴셜들의 제 1 세트는 또한 예컨대 사용자 스크릿(703) 및/또는 액세스 토큰(715)을 비롯하여, 도 5의 단계(508)에서 전송된 인증 크리덴셜들과 유사할 수 있다.

[117] 단계(602)에서, 로그인 요청은 액세스 게이트웨이(360)에 의해 수신될 수 있다. 액세스 게이트웨이(360)는 요청이 클라이언트 디바이스(302)로부터의 새로운 요청임을 결정할 수 있으며, 예컨대 액세스 게이트웨이(360)는 요청이 기업 자원(304) 또는 서비스(308)와의 기존 통신 세션의 부분이 아님을 결정할 수 있다. 요청이 로그인 요청이 아님을 결정한 이후에, 액세스 게이트웨이(360)는 크리덴셜들을 검증하고 사용자가 기업 시스템에 로그인하는 것이 허가되는지의 여부를 결정하기 위하여 로그인 요청 및 인증 크리덴셜들을 인증 서비스(358)에 라우팅할 수 있다. 비록 이러한 예에서의 인증이 액세스 게이트웨이(360)를 통해 수행될 수 있을지라도, 다른 예들에서, 인증은 게이트웨이(360)를 통해 수행될 필요가 없다.

[118] 단계(603)에서, 인증 서비스(358)는 사용자가 유효 사용자이고 기업 시스템에 로그인하는 것이 허가됨을 확인하기 위하여 인증 크리덴셜들의 제 1 세트를 수신하여 검증한다. 단계(603)에서의 검증은 도 5에서 앞서 설명된 제 1 인증 요청의 검증(단계(502))과 유사할 수 있다. 단계(603)에서 사용자를 검증하기 위하여, 인증 서비스(358)는 사용자 인증 크리덴셜들의 제 1 세트를 검증하기 위하여 기업 시스템 내의 보안 데이터 스토리지 또는 서비스, 예컨대 액티브 디렉토리 또는 도메인 제어기에 액세스하도록 구성될 수 있다. 단계(603)에서 크리덴셜들의 제 1 세트를 사용하여 사용자를 성공적으로 검증한 이후에, 사용자는 기업 시스템에 로그인될 수 있으며, 기업 시스템의 다양한 자원들(304) 또는 서비스들(308)에 대한 액세스가 승인될 수 있다.

[119] 부가적으로, 단계(603)에서 크리덴셜들의 제 1 세트를 사용하여 사용자를 검증한 이후에, 인증 서비스(358)는 단계(604)에서 동일한 사용자에 대한 크리덴셜들의 하나 이상의 추가 세트들을 리트리브하도록 구성될 수 있다. 기업 시스템내에서, 단일 사용자는 상이한 기업 자원들(304) 또는 서비스들(308)에 대응하는 다수의 상이한 인증 크리덴셜들을 가질 수 있다. 예컨대, 사용자는 기업 시스템에 로그인하기 위한 크리덴셜들(예컨대, 사용자이름 및 패스워드)의 제 1 세트, 사용자의 이메일 서버(304)에 로그인하기 위한 크리덴셜들의 제 2 세트, 웹 애플리케이션 서버(304)상의 웹-기반 애플리케이션에 액세스하기 위한 크리덴셜들의 제 3 세트, 파일 공유 서비스(368)를 인보크하기 위한 크리덴셜들의 제 4 세트 등을 가질 수 있다. 따라서, 단계(604)에서, 인증 서비스(358)는 다양한 기업 서비스들 및 자원들, 예컨대 액티브 디렉토리, 도메인 제어 서비스 및/또는 사용자 크리덴셜 데이터베이스에 액세스할 수 있다. 인증 서비스(358)는 또한 이들 개별 서비스들 및 자원들에 대한 동일한 사용자의 인증 크리덴셜들을 리트리브하기 위하여 개별 기업 서비스들(308) 및 자원들(304)(예컨대, Exchange, Sharepoint, PKI 자원들, Kerberos 자원들, 인증서 발행 등)과의 통신을 개시할 수 있다.

[120] 단계(604)에서 사용자에 대한 크리덴셜들의 추가 세트들을 리트리브한 이후에, 인증 서비스(358)는 액세스 게이트웨이(360)에 크리덴셜들의 추가 세트들을 전송할 수 있다. 단계(605)에서, 액세스 게이트웨이(360)는 사용자에 대한 크리덴셜들의 추가 세트를 수신하여 게이트웨이(360) 내의 메모리 또는 게이트웨이(360)에게 액세스가능한 다른 스토리지에 저장할 수 있다. 일부 실시예들에서, 크리덴셜들의 사용자의 추가 세트들은 게이트웨이(360) 내에 보안적으로 저장될 수 있으며 그리고/또는 게이트웨이(360)가 손상되는 경우에 기업 시스템에 대한 추가 보안을 제공하기 위하여 게이트웨이(360) 외부에 저장될 수 있다. 도 6에 도시된 예에서, 단계들(604 및 605)은 단계(603)에서 성공적인 사용자 검증에 응답하여 수행될 수 있다. 다른 예들에서, 단계(604 및 605)에서 추가 크리덴셜들의 리트리브 및 저장은 나중에 수행될 수 있다. 예컨대, 단계들(404 및 405)은 인증 서버(358)에 대한 액세스 게이트웨이(360)에 의한 요청에 응답하여, 2차 크리덴셜들을 위하여, 단계(606) 이후에 수행될 수 있다.

[121] 단계(605)에서 저장된 사용자 크리덴셜들의 추가 세트들은 또한 예컨대 도 5를 참조로 하여 앞서 설명된 검증 데이터(710)의 형태로 암호화될 수 있다. 이러한 예들에서, 상이한 사용자들에 대한 인증 크리덴셜들의 세트들은 상이한 암호 키들(705)을 사용하여 암호화될 수 있다. 앞서 설명된 바와같이, 상이한 키들(705)은 액세스 토큰들(715)에서 상이한 사용자들의 클라이언트 디바이스들(302)에 전송될 수 있다. 따라서, 만일 사용자의 키(705)가 게이트웨이(360)상에 저장된 인증 크리덴셜들에 대한 액세스로 악의적인 자에 의해 손상되면, 악의적인 자는 그 사용자의 패스워드들/크리덴셜들을 단지 암호해독할 수 있으며, 상이한 키들(705)로 암호화된 다른 사용자들의 패스워드들/크리덴셜들을 암호해독하지 않을 수 있다.

[122] 단계(606)에서, 크리덴셜 디바이스(302)의 사용자는 단계(601)에서 로그인 요청을 위하여 사용되는 크리덴셜들의 동일한 제 1 세트를 사용하여 기업 시스템내에서 기업 자원(304) 또는 서비스(308)에 대한 요청을 개시한다. 단계(606)에서의 요청은 기업 시스템의 자원(304) 또는 서비스(308), 예컨대 이메일 서버(304), 파일 공유 서버(304), 웹 애플리케이션 서버(304), 디바이스 관리자 서비스(324), 파일 공유 서비스(368), 소셜 통합 서비스(372) 또는 기업 시스템에 의해 제공되는 임의의 다른 자원 또는 서비스에 대한 요청 및/또는 다른 로그인 요청일 수 있다.

[123] 단계(607), 액세스 게이트웨이(360)는 사용자의 제 1 크리덴셜 세트를 수신하고 검증할 수 있으며, 이후 적절한 자원(304) 또는 서비스(308)에 요청을 라우팅하기 전에 요청에 크리덴셜들의 제 2 상이한 세트를 삽입할 수 있다. 클라이언트 디바이스(302)로부터 요청을 수신한 이후에, 액세스 게이트웨이(360)는 사용자가 요청된 자원(304) 또는 서비스(308)에의 액세스를 허락한 유효 시스템 사용자임을 확인하기 위하여 사용자의 제 2 크리덴셜 세트를 검증할 수 있다. 단계(607)에서의 사용자 검증은 단계들(603, 502 및/또는 510) 중 임의의 단계에서 앞서 설명된 인증 서비스(358)에 의한 검증과 유사할 수 있다. 예컨대, 액세스 게이트웨이(360)는 단계(605)에서 게이트웨이(360)에 또는 기업 시스템 내의 보안 데이터 스토리지 또는 서비스, 예컨대 액티브 디렉토리 또는 도메인 제어기에 저장된 사용자 크리덴셜들과 사용자의 인증 크리덴셜들과 비교함으로써 사용자 인증 크리덴셜들을 검증할 수 있다. 다른 경우들에서, 단계(607)에서의 사용자 검증은 제 1 크리덴셜들의 검증에 의한 것보다 오히려 토큰/쿠키를 사용하여 수행될 수 있다. 예컨대, 단계들(601-603)에서의 사용자 크리덴셜들의 제 1 검증 이후에, 액세스 게이트웨이(360)는 세션 토큰 또는 쿠키를 클라이언트 디바이스(302)에 리턴할 수 있다. 단계(606)에서, 클라이언트 디바이스(302)는 제 1 크리덴셜들 대신에 세션 토큰 또는 쿠키를 사용할 수 있으며, 단계(607)에서, 액세스 게이트웨이는 수신된 토큰 또는 쿠키가 게이트웨이(360)에 의해 발행되었고 아직 통용되고 있음을 확인할 수 있다.

[124] 사용자가 요청된 자원(304) 또는 서비스(308)에 액세스하도록 허가됨을 검증한 이후에, 액세스 게이트웨이(360)는 요청된 자원(304) 또는 서비스(308)가 단계(606)에서 사용자에 의해 입력된 인증 크리덴셜들의 제 1 세트를 수락한 것인지의 여부를 결정할 수 있다. 앞서 논의된 바와같이, 단일 사용자는 기업 시스템의 상이한 자원들(304) 및 서비스들(308)에 대한 다수의 상이한 인증 크리덴셜들을 가질 수 있다. 만일 요청된 자원(304) 또는 서비스(308)가 사용자의 제 1 인증 크리덴셜 세트를 수락하지 않을 것이면, 액세스 게이트웨이(360)는 인증 크리덴셜들의 적절한 세트를 리트리브하여 요청에 삽입할 수 있다. 예컨대, 만일 사용자의 제 1 인증 크리덴셜 세트가 사용자의 기업 시스템 사용자이름 및 패스워드이거나 또는 액세스 토큰(715) 및 이전에 입력된 사용자 시크릿(703)이면, 요청된 자원(304) 또는 서비스(308)(예컨대, 이메일 서버, 웹 애플리케이션 서버 등)는 이들 사용자 인증 크리덴셜들을 받아들이지 않을 수 있다. 따라서, 단계(607)에서, 액세스 게이트웨이(360)는 단계(605)에서 저장된 인증 크리덴셜들로부터 유효 사용자 크리덴셜들의 제 2 세트를 리트리브하고, 자원(304) 또는 서비스(308)에 요청을 포워드하기 전에 요청에 크리덴셜들의 제 2 세트를 삽입할 수 있다.

[125] 단계(608)에서, 요청된 기업 자원(304) 또는 서비스(308)는 액세스 게이트웨이(360)로부터 요청을 수신하여 검증한다. 액세스 게이트웨이(360)가 유효 사용자 크리덴셜들의 제 2 세트를 요청에 삽입하였기 때문에, 자원(304) 또는 서비스(308)는 크리덴셜들이 사용자에 의해 클라이언트 디바이스(302)에 직접 입력된 것 처럼 제 2 크리덴셜 세트를 사용하여 사용자를 성공적으로 검증할 수 있다. 단계(608)에서의 검증은 다수의 인증 단계들 및/또는 하나 이상의 챌린지-응답 검증들을 수반할 수 있다. 그러나, 액세스 게이트웨이(360)가 사용자가 자원(304) 또는 서비스(308)에 액세스하기에 적절한 인증 크리덴셜들 및 클라이언트 디바이스(302)로부터의 요청을 가지기 때문에, 게이트웨이(360)는 사용자 또는 클라이언트 디바이스(302)의 관여 없이 모든 인증 챌린지들을 처리할 수 있다.

[126] 자원(304) 또는 서비스(308)가 단계(608)에서 제 2 크리덴셜 세트를 사용하여 사용자를 검증한 이후에, 요청된 데이터 및/또는 서비스들은 단계(609)에서 자원(304) 또는 서비스(308)에 의해, 검증된 사용자에게 제공될 수 있다. 단계(610)에서, 액세스 게이트웨이(360)는 기업 자원 또는 서비스로부터, 요청된 데이터 및/또는 서비스들을 수신하고 데이터를 클라이언트 디바이스(302)에 포워드하며, 단계(611)에서, 클라이언트 디바이스(302)는 요청된 데이터 및/또는 서비스들을 수신하여 사용자에게 제공한다.

[127] 따라서, 이러한 예에서, 액세스 게이트웨이(360)는 클라이언트 디바이스(302)와 요청된 자원(304) 또는 서비스(308) 사이의 프록시 서버로서 역할을 할 수 있다. 즉, 액세스 게이트웨이(360)가 제 1 사용자 크리덴셜 세트를 검증하고 이후 제 2 사용자 크리덴셜 세트를 리트리브하여 요청에 삽입하기 때문에, 제 1 크리덴셜 세트가 자원(304) 또는 서비스(308)에 제출되고 있다는 것이 클라이언트 디바이스(302)에 보일 수 있고 정확한 제 2 크리덴셜 세트가 사용자에 의해 클라이언트 디바이스(302)에 제공되었음이 자원(304) 또는 서비스(308)에 보일 수 있다. 따라서, 클라이언트 디바이스(302)의 사용자는 단일 인증 크리덴셜 세트를 사용하여 상이한 크리덴셜 세트들을 요구하는 다수의 상이한 자원들(304) 또는 서비스들(308)에 성공적으로 로그인할 수 있다. 이러한 기능은 사용자에게 명백할 수 있으며, 따라서 사용자는 많은 상이한 자원들(304) 및 서비스들(308)에 대한 정확인 인증 크리덴셜들을 알 필요가 없으나, 그럼에도 불구하고, 단일 인증 크리덴셜 세트를 사용하여 단일 사인-온으로 이들 상이한 자원들(304) 및 서비스들(308)에 액세스할 수 있다. 더욱이, 단지 단일 인증 크리덴셜 세트만이 사용자에게 아려지고 클라이언트 디바이스(302)에 의해 저장되고 전송될 때, 이러한 단일 크리덴셜 세트는 보안 패스워드를 포함하지 않을 수 있거나 또는 어느 다른 기업 시스템 인정 데이터도 포함하지 않을 수 있다. 예컨대, 앞서 논의된 바와같이, 제 1 인증 크리덴셜 세트는 사용자에 대한 하나 이상의 암호화된 패스워드들을 암호해독하기 위하여 사용될 수 있는 키(705)를 포함하는 액세스 토큰(715) 및/또는 사용자 시크릿(703)일 수 있다.

[128] 비록 요지가 구성적 특징들 및/또는 방법적 동작들에 특정한 언어로 설명되었을지라도, 첨부된 청구항들에서 정의된 요지가 반드시 앞서 설명된 특정 특징들 또는 동작들로 제한되는 것이 아니라는 것이 이해되어야 한다. 오히려, 앞서 설명된 특정 특징들 및 동작들은 하기의 청구항들의 예시적인 구현들로서 설명된다.

Claims (20)

1. 클라이언트 디바이스로부터의 제 1 인증 크리덴셜들을 인증 컴퓨팅 디바이스에 의해 수신하는 단계 ― 상기 제 1 인증 크리덴셜들은 사용자에게 대응하는 사용자 패스워드 또는 토큰을 포함함 ―;
   암호 키로 암호화된 사용자 패스워드 또는 토큰을 포함하는 제 1 검증 데이터를 상기 인증 컴퓨팅 디바이스에 의해 생성하여 저장하는 단계;
   상기 제 1 검증 데이터의 상기 사용자 패스워드 또는 토큰을 암호화하기 위하여 사용되는 암호 키를 포함하는 제 1 액세스 토큰을 상기 인증 컴퓨팅 디바이스에 의해 생성하는 단계; 및
   상기 제 1 액세스 토큰을 상기 인증 컴퓨팅 디바이스에 의해 상기 클라이언트 디바이스에 전송하는 단계를 포함하는, 방법.
2. 제 1항에 있어서, 상기 클라이언트 디바이스로부터 자원 액세스 요청을 수신하는 단계 ― 상기 요청은 암호 키를 포함하는 제 2 액세스 토큰을 포함함 ―;
   상기 제 2 액세스 토큰에 포함된 상기 암호 키를 사용하여 상기 제 1 검증 데이터를 암호해독하는 것을 시도하는 단계; 및
   상기 제 2 액세스 토큰에 포함된 상기 암호 키를 사용하여 상기 제 1 검증 데이터를 성공적으로 암호해독하는 것에 응답하여, 상기 요청된 자원들에 대한 상기 클라이언트 디바이스의 액세스를 승인하는 단계를 더 포함하는, 방법.
3. 제 2항에 있어서, 상기 요청된 자원들에 대한 상기 클라이언트 디바이스 자원들의 액세스를 승인하는 상기 단계는,
   상기 제 1 인증 크리덴셜들과 상이한 하나 이상의 추가 인증 크리덴셜들을 리트리브하는 단계 ― 상기 추가 인증 크리덴셜들은 기업 시스템의 하나 이상의 서비스들 또는 자원들에 액세스하기 위한 제 1 사용자의 크리덴셜들에 대응함 ―; 및
   상기 기업 시스템의 액세스 게이트웨이에 상기 추가 인증 크리덴셜들을 전송하는 단계를 포함하는, 방법.
4. 제 2항에 있어서, 상기 요청된 자원들에 대한 상기 클라이언트 디바이스 자원들의 액세스를 승인하는 상기 단계는,
   상기 암호해독된 제 1 검증 데이터로부터의 하나 이상의 인증 크리덴셜들을 외부 인증 서비스에 제출하는 단계;
   제출된 인증 크리덴셜들이 무효되거나 또는 만료되었다는 표시를 상기 외부 인증 서비스로부터 리트리브하는 단계;
   상기 제 1 사용자에 대한 업데이트된 인증 크리덴셜들에 대한 요청을 상기 클라이언트 디바이스에 전송하는 단계; 및
   상기 클라이언트 디바이스로부터 상기 제 1 사용자에 대한 업데이트된 인증 크리덴셜들을 수신하는 단계를 포함하는, 방법.
5. 제 1항에 있어서, 상기 제 1 인증 크리덴셜들에 기초하여 상기 제 1 사용자를 인증하는 단계;
   상기 제 1 사용자를 인증한 이후에, 상기 클라이언트 디바이스로부터 사용자 시크릿을 수신하는 단계를 더 포함하며,
   상기 제 1 검증 데이터를 생성하는 단계는 상기 암호 키, 즉 상기 제 1 사용자를 식별하는 정보, 상기 사용자 패스워드 또는 토큰 및 상기 사용자 시크릿으로 암호화하는 단계를 포함하는, 방법.
6. 제 5항에 있어서, 상기 클라이언트 디바이스로부터 자원 액세스 요청을 수신하는 단계 ― 상기 요청은 사용자 시크릿, 및 암호 키를 포함하는 제 2 액세스 토큰을 포함함 ―;
   상기 제 2 액세스 토큰에 포함된 상기 암호 키를 사용하여 상기 제 2 검증 데이터를 암호해독하는 단계;
   상기 제 1 검증 데이터의 상기 사용자 시크릿과 상기 자원 액세스 요청의 상기 사용자 시크릿을 비교하는 단계; 및
   상기 제 1 검증 데이터의 사용자 시크릿이 상기 자원 액세스 요청의 사용자 시크릿과 동일하다고 결정하는 것에 응답하여, 상기 요청된 자원들에 대한 클라이언트 디바이스의 액세스를 승인하는 단계를 더 포함하는, 방법.
7. 제 6항에 있어서, 상기 요청된 자원들에 대한 상기 클라이언트 디바이스의 액세스를 승인하는 상기 단계는,
   상기 제 2 액세스 토큰과 연관된 만료 시간 데이터를 리트리브하는 단계; 및
   상기 제 2 액세스 토큰과 연관된 상기 만료 시간 데이터와 상기 자원 액세스 요청과 연관된 요청 시간 사이의 비교에 기초하여, 상기 제 2 액세스 토큰이 유효함을 결정하는 단계를 포함하는, 방법.
8. 제 6항에 있어서, 상기 요청된 자원들에 대한 상기 클라이언트 디바이스의 액세스를 승인하는 상기 단계는,
   상기 자원 액세스 요청과 연관된 제 1 요청된 서비스 또는 자원을 기업 시스템에서 결정하는 단계;
   상기 제 2 액세스 토큰과 연관된 하나 이상의 서비스들 또는 자원들의 세트를 상기 기업 시스템에서 리트리브하는 단계; 및
   상기 제 2 액세스 토큰과 연관된 서비스들 또는 자원들의 세트와 상기 제 1 요청된 서비스 또는 자원의 비교에 기초하여, 상기 제 2 액세스 토큰이 유효함을 결정하는 단계를 포함하는, 방법.
9. 제 5항에 있어서, 상기 클라이언트 디바이스는 모바일 디바이스이며, 상기 모바일 디바이스로부터 수신된 상기 사용자 시크릿은 개인 식별 번호(PIN), 모바일 디바이스 제스처 또는 사용자 생체인식 데이터 중 적어도 하나를 포함하는, 방법.
10. 인증 디바이스로서,
    프로세서; 및
    컴퓨터-실행가능 명령들을 저장한 메모리를 포함하며,
    상기 컴퓨터-실행가능 명령들은, 상기 프로세서에 의해 실행될 때, 상기 인증 디바이스로 하여금,
    클라이언트 디바이스로부터의 제 1 인증 크리덴셜들을 수신하며 ― 상기 제 1 인증 크리덴셜들은 제 1 사용자에게 대응하는 사용자 패스워드 또는 토큰을 포함함 ―;
    암호 키로 암호화된 사용자 패스워드 또는 토큰을 포함하는 제 1 검증 데이터를 생성하여 저장하며;
    상기 제 1 검증 데이터의 상기 사용자 패스워드 또는 토큰을 암호화하기 위하여 사용되는 암호 키를 포함하는 제 1 액세스 토큰을 생성하며; 그리고
    상기 제 1 액세스 토큰을 상기 클라이언트 디바이스에 전송하도록 하는, 인증 디바이스.
11. 제 10항에 있어서, 상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 인증 디바이스로 하여금,
    상기 클라이언트 디바이스로부터 자원 액세스 요청을 수신하며 ― 상기 요청은 암호 키를 포함하는 제 2 액세스 토큰을 포함함 ―;
    상기 제 2 액세스 토큰에 포함된 상기 암호 키를 사용하여 상기 제 1 검증 데이터를 암호해독하는 것을 시도하며; 그리고
    상기 제 2 액세스 토큰에 포함된 상기 암호 키를 사용하여 상기 제 1 검증 데이터를 성공적으로 암호해독하는 것에 응답하여, 상기 요청된 자원들에 대한 상기 클라이언트 디바이스의 액세스를 승인하도록 하는 컴퓨터-실행가능 명령들을 더 저장하는, 인증 디바이스.
12. 제 11항에 있어서, 상기 요청된 자원들에 대한 상기 클라이언트 디바이스의 액세스를 승인하는 것은,
    상기 제 1 인증 크리덴셜들과 상이한 하나 이상의 추가 인증 크리덴셜들을 리트리브하는 것 ― 상기 추가 인증 크리덴셜들은 기업 시스템의 하나 이상의 서비스들 또는 자원들에 액세스하기 위한 제 1 사용자의 크리덴셜들에 대응함 ―; 및
    상기 기업 시스템의 액세스 게이트웨이에 상기 추가 인증 크리덴셜들을 전송하는 것을 포함하는, 인증 디바이스.
13. 제 10항에 있어서, 상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 인증 디바이스로 하여금,
    상기 제 1 인증 크리덴셜들에 기초하여 상기 제 1 사용자를 인증하며;
    상기 제 1 사용자를 인증한 이후에, 상기 클라이언트 디바이스로부터 사용자 시크릿을 수신하도록 하는 컴퓨터-실행가능 명령들을 더 저장하며,
    상기 제 1 검증 데이터를 생성하는 것은 상기 암호 키, 즉 상기 제 1 사용자를 식별하는 정보, 상기 사용자 패스워드 또는 토큰 및 상기 사용자 시크릿으로 암호화하는 것을 포함하는, 인증 디바이스.
14. 제 13항에 있어서, 상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 인증 디바이스로 하여금,
    상기 클라이언트 디바이스로부터 자원 액세스 요청을 수신하며 ― 상기 요청은 사용자 시크릿, 및 암호 키를 포함하는 제 2 액세스 토큰을 포함함 ―;
    상기 제 2 액세스 토큰에 포함된 상기 암호 키를 사용하여 상기 제 1 검증 데이터를 암호해독하며;
    상기 제 1 검증 데이터의 상기 사용자 시크릿과 상기 자원 액세스 요청의 상기 사용자 시크릿을 비교하며; 그리고
    상기 제 1 검증 데이터의 사용자 시크릿이 상기 자원 액세스 요청의 사용자 시크릿과 동일하다고 결정하는 것에 응답하여, 상기 요청된 자원들에 대한 클라이언트 디바이스의 액세스를 승인하도록 하는 컴퓨터-실행가능 명령들을 더 저장하는, 인증 디바이스.
15. 제 14항에 있어서, 상기 요청된 자원들에 대한 상기 클라이언트 디바이스의 액세스를 승인하는 것은,
    상기 제 2 액세스 토큰과 연관된 만료 시간 데이터를 리트리브하는 것; 및
    상기 제 2 액세스 토큰과 연관된 상기 만료 시간 데이터와 상기 자원 액세스 요청과 연관된 요청 시간 사이의 비교에 기초하여, 상기 제 2 액세스 토큰이 유효함을 결정하는 것을 포함하는, 인증 디바이스.
16. 제 14항에 있어서, 상기 요청된 자원들에 대한 상기 클라이언트 디바이스의 액세스를 승인하는 것은,
    상기 자원 액세스 요청과 연관된 제 1 요청된 서비스 또는 자원을 기업 시스템에서 결정하는 것;
    상기 제 2 액세스 토큰과 연관된 하나 이상의 서비스들 또는 자원들의 세트를 상기 기업 시스템에서 리트리브하는 것; 및
    상기 제 2 액세스 토큰과 연관된 서비스들 또는 자원들의 세트와 상기 제 1 요청된 서비스 또는 자원의 비교에 기초하여, 상기 제 2 액세스 토큰이 유효함을 결정하는 것을 포함하는, 인증 디바이스.
17. 모바일 디바이스로서,
    프로세서;
    적어도 하나의 입력 인터페이스; 및
    컴퓨터-실행가능 명령들을 저장한 메모리를 포함하며;
    상기 컴퓨터-실행가능 명령들은, 상기 프로세서에 의해 실행될 때, 상기 모바일 디바이스로 하여금,
    상기 모바일 디바이스의 입력 인터페이스를 통해 사용자 패스워드 또는 토큰을 수신하며;
    기업 시스템의 인증 디바이스에 제 1 요청을 전송하며 ― 상기 제 1 요청은 상기 사용자 패스워드 또는 토큰을 포함함 ―;
    상기 인증 디바이스로부터 제 1 액세스 토큰을 수신하며 ― 상기 제 1 액세스 토큰은 암호 키를 포함함 ―;
    상기 모바일 디바이스의 입력 인터페이스를 통해 사용자 시크릿을 수신하며; 그리고
    상기 기업 시스템의 인증 디바이스에 제 2 요청을 전송하도록 하며;
    상기 제 2 요청은 상기 제 1 액세스 토큰 및 상기 사용자 시크릿을 포함하는, 모바일 디바이스.
18. 제 17항에 있어서, 상기 인증 디바이스에 전송되는 제 2 요청은 상기 사용자 패스워드 또는 토큰의 암호화 또는 암호해독된 복사본을 포함하지 않는, 모바일 디바이스.
19. 제 17항에 있어서, 상기 사용자 패스워드 또는 토큰은 제 1 입력 인터페이스를 통해 수신되며, 상기 사용자 시크릿은 상이한 제 2 입력 인터페이스를 통해 수신되는, 모바일 디바이스,
20. 제 19항에 있어서, 상기 사용자 패스워드 또는 토큰은 상기 모바일 디바이스의 키보드를 통해 수신되며;
    상기 사용자 시크릿을 수신하는 것은,
    상기 모바일 디바이스의 숫자 키패드를 통해 개인 식별 번호(PIN)를 수신하는 것,
    상기 모바일 디바이스의 터치 스크린을 통해 제스처를 수신하는 것, 또는
    상기 모바일 디바이스의 생체인식 입력 인터페이스를 통해 사용자 생체인식 데이터를 수신하는 것 중 적어도 하나를 포함하는, 모바일 디바이스.

Images