Android SDK - översikt android-sdk-overview

Introduktion intro

Android AccessEnabler är ett Java Android-bibliotek som gör att mobilappar kan använda Adobe Pass Authentication for TV Everywhere's tillståndsservice. En Android-implementering består av AccessEnabler-gränssnittet som definierar berättigande-API:t och ett EntitlementDelegate-protokoll som beskriver återanropen som biblioteket utlöser. Gränssnittet och protokollet kallas under ett gemensamt namn: AccessEnabler Android-biblioteket.

Android-krav reqs

Aktuella tekniska krav för Android-plattformen och Adobe Pass-autentisering finns i Plattform/Enhet/Verktygskrav eller i versionsinformationen som medföljer vid hämtningen av Android SDK.

Understanding Native Client Workflows native_client_workflows

Inbyggda klientarbetsflöden är vanligtvis desamma som, eller mycket lika, för webbläsarbaserade Adobe Pass Authentication-klienter. Det finns dock några undantag, som beskrivs nedan.

Arbetsflöde efter initiering post-init

Alla tillståndsarbetsflöden som stöds av AccessEnabler förutsätter att du tidigare har anropat setRequestor() för att upprätta din identitet. Du gör det här anropet för att bara ange ditt begärande-ID en gång, vanligtvis under programmets initierings-/installationsfas.

Med de inbyggda klienterna (t.ex. Android) kan du efter ditt första anrop till setRequestor() välja hur du vill fortsätta:

Det är upp till dig om du ska vänta på att meddelandet om att setRequestor() lyckades ska visas eller om du ska förlita dig på åtkomstaktiverarens anropskömekanism. Eftersom alla efterföljande autentiserings- och autentiseringsbegäranden behöver begärande-ID och den associerade konfigurationsinformationen blockerar metoden setRequestor() alla autentiserings- och auktoriserings-API-anrop tills initieringen är slutförd.

Allmänt inledande autentiseringsarbetsflöde generic

Syftet med det här arbetsflödet är att logga in en användare med sitt MVPD-program. När inloggningen är klar utfärdar backend-servern en autentiseringstoken till användaren. Autentisering sker vanligtvis som en del av auktoriseringsprocessen, men följande beskriver hur autentisering kan fungera fristående och inkluderar inga auktoriseringssteg.

Observera att även om följande inbyggda klientarbetsflöde skiljer sig från det vanliga webbläsarbaserade autentiseringsarbetsflödet är steg 1-5 samma för både inbyggda klienter och webbläsarbaserade klienter:

Utloggningsarbetsflöde logout

För inbyggda klienter hanteras inloggningar på liknande sätt som autentiseringsprocessen som beskrivs ovan. I det här mönstret öppnar AccessEnabler anpassade Chrome-flikar och läser in URL:en för utloggningsslutpunkten på backend-servern.

Obs! Loggning ut från en programmerare/MVPD-session kommer att rensas
det underliggande lagringsutrymmet för det specifika sidoskyddet, inklusive samtliga
andra autentiseringstoken för programmerare som erhållits via enkel inloggning
den enheten. Token som erhållits för andra videoprogrammerings-programmerings-ID eller inte via enkel inloggning kommer inte att
tas bort.

Tokens tokens

Definitioner och användning definitions

Adobe Pass Authentication-berättigandelösningen kretsar kring genereringen av specifika datadelar (tokens) som genereras av Adobe Pass Authentication när autentiserings- och auktoriseringsarbetsflödena har slutförts. Dessa token lagras lokalt på klientens Android-enhet.

Tokens har begränsad livslängd. När den upphör att gälla måste tokens utfärdas på nytt genom att autentiserings- och/eller auktoriseringsarbetsflödena återupptas.

Det finns tre typer av tokens som utfärdas under tillståndsarbetsflödena:

När autentiseringen och auktoriseringen är klar kommer Adobe Pass Authentication att utfärda autentiserings-, auktoriserings- och kortlivade medietoken. Dessa token bör cachelagras på användarens enhet och användas under hela den tid som de är kopplade till sin livstid.

Riktlinjer för cachelagring caching

Autentiseringstoken

Auktoriseringstoken

Vid ett givet tillfälle cachelagras bara EN auktoriseringstoken per resurs av AccessEnabler. Det kan finnas flera autentiseringstoken cachelagrade, men de är associerade med olika resurser. När en ny auktoriseringstoken utfärdas och en gammal redan finns för samma resurs, skriver den nya token över det befintliga cachelagrade värdet.

Medietoken

Den kortlivade medietoken får INTE cachelagras alls. Medietoken bör hämtas från servern varje gång ett auktoriserings-API anropas, eftersom det är begränsat till engångsanvändning.

Persistence persistence

Token måste vara beständig i flera på varandra följande körningar av samma program. Detta innebär att när autentiserings- och auktoriseringstoken har hämtats och användaren stänger programmet, är samma token tillgängliga för programmet när användaren öppnar programmet igen. Dessutom är det önskvärt att dessa variabler är beständiga i flera program. När en användare har använt ett program för att logga in med en viss identitetsleverantör (har hämtat autentiserings- och auktoriseringstoken) kan samma token användas via ett annat program, och användaren uppmanas inte längre att ange autentiseringsuppgifter när han eller hon loggar in via samma identitetsleverantör.

Den här typen av smidigt autentiserings-/auktoriseringsarbetsflöde gör Adobe Pass Authentication-lösningen till en äkta TV-Everywhere-implementering. Ur en rent teknisk synvinkel kan Android AccessEnabler-biblioteket kringgå problemen med datadelning mellan program genom att lagra tokendata i en databasfil som finns på en extern lagringsplats. Dessa delade resurser på systemnivå innehåller de viktigaste komponenterna som gör det möjligt att implementera de önskade permanenta token-användningsexemplen:

När en viss token har placerats i token-cachen kontrolleras dess giltighet vid olika tillfällen av AccessEnabler-biblioteket. En giltig token definieras som:

Från och med AccessEnabler 1.7 kan tokenlagringen ha stöd för flera programmerings-MVPD-kombinationer, beroende på en kapslad mappningsstruktur på flera nivåer som kan innehålla flera autentiseringstoken. Det nya lagringsutrymmet påverkar inte det offentliga API:t för AccessEnabler på något sätt och kräver inga ändringar från programmerarens sida. Här följer ett exempel som visar den här nyare funktionen:

I äldre versioner av AccessEnabler återges användaren som icke-autentiserad i steg 6, eftersom tokenlagringen tidigare bara hade stöd för en autentiseringstoken.

OBS! Om du loggar ut från en programmerare/MVPD-session rensas det underliggande lagringsutrymmet, inklusive alla andra programmerarautentiseringstoken på enheten med enkel inloggning. Token som erhållits för andra MVPD eller inte via enkel inloggning tas inte bort. Om du avbryter autentiseringsflödet (anropar setSelectedProvider(null)) rensas INTE det underliggande lagringsutrymmet, men det påverkar bara det aktuella autentiseringsförsöket för programmerare/MVPD (genom att radera det MVPD för den aktuella programmeraren).

En annan lagringsrelaterad funktion som ingår i AccessEnabler 1.7 gör det möjligt att importera autentiseringstoken från äldre lagringsområden. Den här"tokenimporteraren" hjälper till att uppnå kompatibilitet mellan efterföljande AccessEnabler-versioner och upprätthålla SSO-läget även när lagringsversionen uppgraderas.

Importören körs under setRequestor()-flödet och körs i följande två scenarier (förutsatt att det inte finns någon giltig autentiseringstoken för den aktuella programmeraren i det aktuella lagringsutrymmet):

Importåtgärden är genomskinlig för programmeraren och kräver ingen kodändring i klientprogrammet.

Format format

Autentiseringstoken authn_token

I listan nedan visas formatet för autentiseringstoken:

    <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>

Auktoriseringstoken authz_token

I listan nedan visas auktoriseringstokens format:

    <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>

Kort medietoken short_media_token

I listan nedan visas formatet för den korta medietoken. Denna token visas för programmerarens program. Det skickas till Programmerarens program när en tillståndsprocess är slutförd:

    <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>

Enhetsbindning device_binding

Observera taggen simpleTokenFingerprint i XML-listan ovan. Syftet med den här taggen är att lagra information om anpassad enhets-ID. AccessEnabler-biblioteket kan hämta sådan individualiseringsinformation och göra den tillgänglig för Adobe Pass Authentication Services under berättigandeanropen. Tjänsten kommer att använda den här informationen och bädda in den i de faktiska tokenerna, vilket effektivt binder tokenerna till en viss enhet. Slutmålet för detta är att göra tokens icke-överförbara över olika enheter.

Observera taggen simpleTokenFingerprint i XML-listan ovan. Syftet med den här taggen är att lagra information om anpassad enhets-ID. AccessEnabler-biblioteket kan hämta sådan individualiseringsinformation och göra den tillgänglig för Adobe Pass Authentication Services under berättigandeanropen. Tjänsten kommer att använda den här informationen och bädda in den i de faktiska tokenerna, vilket effektivt binder tokenerna till en viss enhet. Slutmålet för detta är att göra tokens icke-överförbara över olika enheter.

Eftersom detta är en uppenbart säkerhetsrelaterad funktion är denna information i sig"känslig" ur säkerhetssynpunkt. Därför måste denna information skyddas mot både manipulering och tjuvlyssning. Eavesdropping-problemet löses genom att autentiserings-/auktoriseringsbegäranden skickas via HTTPS-protokollet. Manipuleringsskyddet hanteras genom att enhetsidentifieringsinformationen signeras digitalt. AccessEnabler-biblioteket beräknar ett enhets-ID från information som enheten anger och skickar sedan enhets-ID:t "i klartext" till Adobe Pass autentiseringsservrar som en begärandeparameter. Adobe Pass autentiseringsservrar signerar digitalt enhets-ID med Adobe privata nyckel och lägger till det i den autentiseringstoken som returneras till AccessEnabler. Detta innebär att enhets-ID är bundet till autentiseringstoken. Under auktoriseringsflödet skickar AccessEnabler igen enhets-ID:t i rensningen tillsammans med autentiseringstoken. Om valideringsprocessen misslyckas kommer det automatiskt att leda till att arbetsflödena för autentisering/auktorisering misslyckas. Adobe Pass autentiseringsservrar använder den privata nyckeln för enhets-ID och jämför den med värdet i autentiseringstoken. Om de inte matchar misslyckas tillståndsflödet.