Android SDK 개요 android-sdk-overview

소개 intro

Android AccessEnabler는 모바일 앱이 TV Everywhere의 권한 부여 서비스를 위해 Adobe Pass 인증을 사용할 수 있도록 해주는 Java Android 라이브러리입니다. Android 구현은 권한 부여 API를 정의하는 AccessEnabler 인터페이스와 라이브러리가 트리거하는 콜백을 설명하는 EntitlementDelegate 프로토콜로 구성됩니다. 프로토콜과 함께 인터페이스는 하나의 공통 이름인 AccessEnabler Android 라이브러리에서 참조됩니다.

Android 요구 사항 reqs

Android 플랫폼 및 Adobe Pass 인증과 관련된 현재 기술 요구 사항은 을 참조하십시오. 플랫폼/장치/도구 요구 사항또는 Android SDK 다운로드에 포함된 릴리스 노트를 참조하십시오.

기본 클라이언트 워크플로우 이해 native_client_workflows

기본 클라이언트 워크플로우는 일반적으로 브라우저 기반 Adobe Pass 인증 클라이언트의 워크플로와 동일하거나 매우 유사합니다. 그러나 아래에 설명된 대로 몇 가지 예외가 있습니다.

초기화 후 워크플로 post-init

AccessEnabler에서 지원하는 모든 자격 부여 워크플로우는 이전에 을 호출했다고 가정합니다. setRequestor() 자신의 신분을 밝히기 위해 이 호출을 수행하면 일반적으로 애플리케이션의 초기화/설정 단계 중에 요청자 ID를 한 번만 제공합니다.

를 처음 호출한 후 기본 클라이언트(예: Android)를 사용하여 setRequestor(), 진행 방법에 대한 선택 사항이 있습니다.

의 성공 알림을 기다릴 것인지 여부는 사용자가 결정합니다. setRequestor() 또는 AccessEnabler의 콜 큐 메커니즘을 사용하는 것이 좋습니다. 모든 후속 인증 및 인증 요청에는 요청자 ID 및 관련 구성 정보가 필요하므로 setRequestor() 메서드는 초기화가 완료될 때까지 모든 인증 및 권한 부여 API 호출을 효과적으로 차단합니다.

일반 초기 인증 워크플로 generic

이 워크플로우의 목적은 MVPD로 사용자를 로그인하는 것입니다. 로그인에 성공하면 백엔드 서버가 사용자에게 인증 토큰을 발행합니다. 인증은 일반적으로 권한 부여 프로세스의 일부로 수행되지만, 다음은 인증이 개별적으로 작동하는 방법에 대한 설명이며, 권한 부여 단계는 포함하지 않습니다.

다음 기본 클라이언트 워크플로우는 일반적인 브라우저 기반 인증 워크플로와 다르지만 기본 클라이언트와 브라우저 기반 클라이언트 모두에 대해 1~5단계는 동일합니다.

로그아웃 워크플로 logout

기본 클라이언트의 경우, 로그아웃은 위에서 설명한 인증 프로세스와 유사하게 처리됩니다. 이 패턴을 따라 AccessEnabler는 Chrome 사용자 지정 탭을 열고 백엔드 서버에 있는 로그아웃 끝점의 URL을 로드합니다.

참고: 한 프로그래머/MVPD 세션에서 로그아웃하면 해당 장치에서 SSO를 통해 얻은 다른 모든 프로그래머 인증 토큰을 포함하여 특정 MVPD에 대한 기본 저장소가 지워집니다. SSO를 통해 다른 MVPD에 대해 획득한 토큰은 삭제되지 않습니다.

토큰 tokens

정의 및 사용 definitions

Adobe Pass 인증 권한 부여 솔루션은 인증 및 권한 부여 워크플로가 성공적으로 완료되면 Adobe Pass 인증이 생성하는 특정 데이터(토큰)를 생성하는 것에 중점을 둡니다. 이러한 토큰은 클라이언트의 Android 디바이스에 로컬로 저장됩니다.

토큰의 수명은 제한됩니다. 만료 시 인증 및/또는 권한 부여 워크플로의 재시작을 통해 토큰을 재발행해야 합니다.

자격 워크플로 중에 발급되는 세 가지 유형의 토큰이 있습니다.

인증 및 인증에 성공하면 Adobe Pass 인증에서 인증, 권한 부여 및 수명이 짧은 미디어 토큰을 발행합니다. 이러한 토큰은 사용자의 장치에 캐시되어야 하며 관련 수명 기간에 사용되어야 합니다.

캐싱 지침 caching

인증 토큰

인증 토큰

AccessEnabler는 특정 시점에 리소스당 하나의 인증 토큰만 캐시합니다. 여러 인증 토큰이 캐시될 수 있지만 서로 다른 리소스와 연결되어 있습니다. 새 인증 토큰이 발행되고 동일한 리소스에 대한 이전 인증 토큰이 이미 있을 때마다 새 토큰이 기존 캐시된 값을 덮어씁니다.

미디어 토큰

단기 미디어 토큰은 전혀 캐시되지 않아야 합니다. 미디어 토큰은 일회성 사용으로 제한되므로 인증 API가 호출될 때마다 서버에서 검색해야 합니다.

지속성 persistence

토큰은 동일한 애플리케이션의 연속 실행 간에 지속적이어야 합니다. 즉, 인증 및 인증 토큰이 획득되고 사용자가 애플리케이션을 닫으면 사용자가 애플리케이션을 다시 열 때 애플리케이션에서 동일한 토큰을 사용할 수 있습니다. 더욱이, 이러한 토큰들은 다수의 애플리케이션들에 걸쳐 지속되는 것이 바람직하다. 즉, 사용자가 하나의 애플리케이션을 사용하여 특정 ID 공급자로 로그인한 후(인증 및 인증 토큰을 성공적으로 획득) 다른 애플리케이션을 통해 동일한 토큰을 사용할 수 있으며, 동일한 ID 공급자를 통해 로그인할 때 더 이상 자격 증명을 묻는 메시지가 표시되지 않습니다.

이러한 유형의 원활한 인증/권한 부여 워크플로우는 Adobe Pass 인증 솔루션을 진정한 TV Everywhere 구현으로 만드는 요소입니다. 엔지니어링 관점에서 Android AccessEnabler 라이브러리는 토큰 데이터를 외부 스토리지에 있는 데이터베이스 파일에 저장하여 애플리케이션 간 데이터 공유 문제를 해결합니다. 이 시스템 수준 공유 리소스는 원하는 영구 토큰 사용 사례를 구현할 수 있는 주요 구성 요소를 제공합니다.

토큰 캐시에 특정 토큰을 배치하면 AccessEnabler 라이브러리에서 해당 토큰의 유효성을 다른 시간에 확인합니다. 유효한 토큰은 다음과 같이 정의됩니다.

AccessEnabler 1.7부터 토큰 스토리지는 여러 인증 토큰을 보유할 수 있는 다중 레벨 중첩 맵 구조에 따라 여러 프로그래머-MVPD 조합을 지원할 수 있습니다. 이 새로운 스토리지는 AccessEnabler 공용 API에 영향을 주지 않으며 프로그래머 측에서는 변경할 필요가 없습니다. 다음은 이러한 최신 기능을 보여주는 예입니다.

이전 버전의 AccessEnabler에서는 토큰 저장소가 이전에 하나의 인증 토큰만 지원했으므로 6단계에서 사용자를 인증되지 않은 것으로 렌더링했습니다.

참고: 한 프로그래머/MVPD 세션에서 로그아웃하면 SSO를 사용하여 디바이스의 다른 프로그래머 인증 토큰을 모두 포함하여 기본 스토리지가 지워집니다. SSO를 통해 다른 MVPD에 대해 획득한 토큰은 삭제되지 않습니다. 인증 흐름 취소(호출) setSelectedProvider(null))는 기본 스토리지를 지우지 않지만 현재 프로그래머/MVPD 인증 시도에만 영향을 미칩니다(현재 프로그래머에 대한 MVPD 삭제).

AccessEnabler 1.7에 포함된 또 다른 스토리지 관련 기능을 사용하면 이전 스토리지 영역에서 인증 토큰을 가져올 수 있습니다. 이 "Token Importer"를 사용하면 스토리지 버전이 업그레이드되어도 SSO 상태를 유지하면서 연속적인 AccessEnabler 릴리스 간의 호환성을 유지할 수 있습니다.

가져오기는 다음 기간 동안 실행됩니다. setRequestor() 흐름 및 는 다음 두 가지 시나리오에서 실행됩니다(현재 프로그래머에 대한 유효한 인증 토큰이 현재 저장소에 없다고 가정).

가져오기 작업은 프로그래머에게 투명하며 클라이언트 애플리케이션에서 코드를 변경할 필요가 없습니다.

형식 format

인증 토큰 authn_token

아래 목록은 인증 토큰의 형식을 제공합니다.

    <signatureInfo>base64(...)<signatureInfo>
    <simpleAuthenticationToken>
        <simpleTokenAuthenticationGuid>71C69B91-F327-F185-F29E-2CE20DC560F5</simpleTokenAuthenticationGuid>
        <simpleTokenRequestorID>TEST_REQUESTOR</simpleTokenRequestorID>
        <simpleTokenDomainName>adobe.com</simpleTokenDomainName>
        <simpleTokenExpires>2011/03/19 02:29:34 GMT +0200</simpleTokenExpires>
        <simpleTokenMsoID>Adobe</simpleTokenMsoID>
        <simpleTokenDeviceID>
            <simpleTokenFingerprint>
                HASH(true device identification info)
            </simpleTokenFingerprint>
        </simpleTokenDeviceID>
    </simpleAuthenticationToken>

인증 토큰 authz_token

아래 목록은 인증 토큰의 형식을 제공합니다.

    <signatureInfo>base64(...)<signatureInfo>
    <simpleAuthorizationToken>
        <simpleTokenRequestorID>TEST_REQUESTOR</simpleTokenRequestorID>
        <simpleTokenResourceID>TEST_RESOURCE</simpleTokenResourceID>
        <simpleTokenTTL>2011/03/17 14:40:08 GMT +0200</simpleTokenTTL>
        <simpleTokenMsoID>Adobe</simpleTokenMsoID>
        <simpleTokenDeviceID>
            <simpleTokenFingerprint>
                HASH(true device identification info)
            </simpleTokenFingerprint>
        </simpleTokenDeviceID>
    </simpleAuthorizationToken>

짧은 미디어 토큰 short_media_token

아래 목록은 짧은 미디어 토큰의 형식을 제공합니다. 이 토큰은 프로그래머 애플리케이션에 노출됩니다. 이것은 성공적인 자격 프로세스가 끝나면 프로그래머 애플리케이션에 전달됩니다.

    <signatureInfo>signature<signatureInfo>
    <shortAuthorizationToken>
      <sessionGUID>session_guid</sessionGUID>
      <requestorID>requestor_id</requestorID>
      <resourceID>resource_id</resourceID>
      <ttl>ttl_in_ms</ttl>
      <issueTime>issue_time</issueTime>
      <mvpdId>mvpd_id</mvpdId>
      <proxyMvpdId>proxy_mvpd_id</proxyMvpdId>
    </shortAuthorizationToken>

장치 바인딩 device_binding

위의 XML 목록에서 제목이 있는 태그를 참고하십시오 simpleTokenFingerprint. 이 태그의 목적은 기본 장치 ID 개별화 정보를 보유하는 것입니다. AccessEnabler 라이브러리는 이러한 개별화 정보를 가져와 권한 부여 호출 중에 Adobe Pass 인증 서비스에서 사용할 수 있도록 할 수 있습니다. 이 서비스는 이 정보를 사용하여 실제 토큰에 포함하므로 토큰을 특정 장치에 효과적으로 바인딩합니다. 이것의 최종 목표는 여러 디바이스에서 토큰을 전송할 수 없도록 하는 것입니다.

위의 XML 목록에서 simpleTokenFingerprint라는 태그를 참고하십시오. 이 태그의 목적은 기본 장치 ID 개별화 정보를 보유하는 것입니다. AccessEnabler 라이브러리는 이러한 개별화 정보를 가져와 권한 부여 호출 중에 Adobe Pass 인증 서비스에서 사용할 수 있도록 할 수 있습니다. 이 서비스는 이 정보를 사용하여 실제 토큰에 포함하므로 토큰을 특정 장치에 효과적으로 바인딩합니다. 이것의 최종 목표는 여러 디바이스에서 토큰을 전송할 수 없도록 하는 것입니다.

이는 명백히 보안 관련 기능이므로 이 정보는 보안 관점에서 본질적으로 "민감합니다". 결과적으로 이러한 정보는 변조 및 도청으로부터 보호될 필요가 있다. 도청 문제는 HTTPS 프로토콜을 통해 인증/권한 부여 요청을 전송하여 해결됩니다. 변조 방지는 기기 식별 정보에 디지털 서명을 함으로써 처리된다. AccessEnabler 라이브러리는 디바이스에서 제공하는 정보에서 디바이스 ID를 계산한 다음, 디바이스 ID를 "in the clear"를 요청 매개 변수로 Adobe Pass 인증 서버에 보냅니다. Adobe Pass 인증 서버는 Adobe의 개인 키로 장치 ID를 디지털 서명하고 AccessEnabler에 반환되는 인증 토큰에 추가합니다. 따라서 장치 ID가 인증 토큰과 바인딩됩니다. 인증 흐름 중에 AccessEnabler는 인증 토큰과 함께 디바이스 ID를 지우고 다시 전송합니다. 유효성 검사 프로세스가 실패하면 자동으로 인증/권한 부여 워크플로가 실패합니다. Adobe Pass 인증 서버는 개인 키를 장치 ID에 적용하고 인증 토큰의 값과 비교합니다. 일치하지 않으면 해당 권한 흐름이 실패합니다.