Overzicht van Android SDK android-sdk-overview

Inleiding intro

Android AccessEnabler is een Java Android-bibliotheek waarmee mobiele apps Adobe Pass-verificatie kunnen gebruiken voor de machtigingsservices van TV Anywhere. Een implementatie Android bestaat uit de interface AccessEnabler die de machtiging API bepaalt, en een protocol EntitlementDelegate dat callbacks beschrijft die de bibliotheek teweegbrengt. De interface samen met het protocol wordt bedoeld onder één gemeenschappelijke naam: de bibliotheek AccessEnabler Android.

Android-vereisten reqs

Voor de huidige technische vereisten met betrekking tot het Android-platform en de Adobe Pass-verificatie, raadpleegt u Vereisten voor platform/apparaat/gereedschapof raadpleeg de releaseopmerkingen die bij het downloaden van de Android-SDK zijn inbegrepen.

Native clientworkflows begrijpen native_client_workflows

Native clientworkflows zijn doorgaans hetzelfde als of lijken sterk op die van op browsers gebaseerde Adobe Pass Authentication-clients. Er zijn echter enkele uitzonderingen, zoals hieronder beschreven.

Workflow na initialisatie post-init

Alle die machtigingswerkschema's door AccessEnabler worden gesteund veronderstellen dat u eerder hebt geroepen setRequestor() om uw identiteit vast te stellen. U doet deze vraag om uw identiteitskaart van de Aanvrager slechts eenmaal te verstrekken, gewoonlijk tijdens de initialisatie/opstellingsfase van uw toepassing.

Met de native clients (bijvoorbeeld Android), na uw eerste oproep aan setRequestor()hebt u een keuze voor de volgende stappen:

Het is aan u om te wachten op de kennisgeving van het succes van setRequestor() of om op het mechanisme van de vraagrij van AccessEnabler te vertrouwen. Aangezien alle volgende autorisatie- en verificatieverzoeken de aanvrager-id en de bijbehorende configuratiegegevens nodig hebben, setRequestor() de methode blokkeert effectief alle authentificatie en vergunning API vraag tot de initialisering volledig is.

Generic Initial Authentication Workflow generic

Het doel van deze workflow is om een gebruiker aan te melden bij zijn MVPD. Na een geslaagde aanmelding geeft de server de gebruiker een verificatietoken uit. Terwijl de authentificatie typisch als deel van het vergunningsproces wordt gedaan, beschrijft het volgende hoe de authentificatie afzonderlijk kan werken, en omvat geen toestemmingsstappen.

Hoewel de volgende native clientworkflow afwijkt van de typische browsergebaseerde verificatieworkflow, zijn de stappen 1-5 hetzelfde voor zowel native clients als op browsers gebaseerde clients:

Logout-workflow logout

Voor native clients worden aanmeldgegevens op dezelfde manier verwerkt als het hierboven beschreven verificatieproces. Na dit patroon, opent AccessEnabler de Aangepaste Tabs van het Chroom en laadt URL van het logout eindpunt op de backendserver.

Opmerking: Het programma openen van één zitting Programma/MVPD zal de onderliggende opslag voor dat specifieke MVPD met inbegrip van alle andere die authentificatietokens van de Programmer door SSO op dat apparaat worden verkregen ontruimen. Tokens die voor andere MVPD's of niet via SSO zijn verkregen, worden niet verwijderd.

Tokens tokens

Definities en gebruik definitions

De Adobe Pass Authentication-machtigingsoplossing draait om het genereren van specifieke gegevens (tokens) die door Adobe Pass Authentication worden gegenereerd wanneer de workflows voor verificatie en autorisatie met succes zijn voltooid. Deze tokens worden lokaal opgeslagen op het Android-apparaat van de client.

Tokens hebben een beperkte levensduur; bij het verlopen moeten tokens opnieuw worden uitgegeven door het opnieuw opstarten van de workflows voor verificatie en/of autorisatie.

Er zijn drie typen tokens die worden uitgegeven tijdens de workflows voor machtigingen:

Bij geslaagde verificatie en autorisatie geeft Adobe Pass Authentication, Authentificatie en kortstondige mediatokens uit. Deze tokens zouden op het apparaat van de gebruiker moeten worden in het voorgeheugen ondergebracht en voor de duur van hun bijbehorende leven-spanwijdten worden gebruikt.

Richtlijnen voor caching caching

Verificatietoken

Token voor autorisatie

Op om het even welk bepaald ogenblik wordt slechts ÉÉN toestemmingstoken per middel caching door AccessEnabler. Er kunnen veelvoudige toestemmingstokens in het voorgeheugen ondergebracht zijn, maar zij worden geassocieerd met verschillende middelen. Wanneer een nieuw toestemmingstoken wordt uitgegeven en oud reeds voor het zelfde middel bestaat, beschrijft het nieuwe teken de bestaande caching waarde.

Mediumtoken

De media-token voor korte tijd mag NIET in de cache worden opgeslagen. Het mediatoken moet van de server worden opgehaald telkens wanneer een autorisatie-API wordt aangeroepen, omdat dit beperkt is tot eenmalig gebruik.

Persistentie persistence

Tokens moeten blijvend zijn in opeenvolgende uitvoeringen van dezelfde toepassing. Dit betekent dat zodra de verificatie- en autorisatietokens zijn verkregen en de gebruiker de toepassing sluit, dezelfde tokens beschikbaar zijn voor de toepassing wanneer de gebruiker de toepassing opnieuw opent. Bovendien is het wenselijk dat deze tokens voor meerdere toepassingen blijvend zijn. Met andere woorden, nadat een gebruiker een toepassing gebruikt om zich aan te melden bij een specifieke identiteitsprovider (met succes authentificatie en toestemmingstkens), kunnen de zelfde tokens door een verschillende toepassing worden gebruikt, en de gebruiker wordt niet meer veroorzaakt voor geloofsbrieven wanneer het registreren via de zelfde identiteitsleverancier.

Dit type naadloze verificatie-/autorisatieworkflow maakt van de Adobe Pass-verificatieoplossing een echte implementatie op tv en overal. Vanuit zuiver technisch oogpunt werkt de Android AccessEnabler-bibliotheek rond de problemen van het delen van toepassingsgegevens door de tokengegevens op te slaan in een databasebestand dat zich op externe opslag bevindt. Deze op systeemniveau gedeelde middelen verstrekken de belangrijkste ingrediënten die de implementatie van de gewenste blijvende tokens gebruiks-geval toelaten:

Zodra een bepaald teken in het symbolische geheime voorgeheugen wordt geplaatst, zal zijn geldigheid op verschillende tijden door de bibliotheek AccessEnabler worden gecontroleerd. Een geldig token wordt gedefinieerd als:

Beginnend met AccessEnabler 1.7, kan de symbolische opslag veelvoudige combinaties programmmer-MVPD steunen, die zich op een op meerdere niveaus genestelde kaartstructuur baseren die veelvoudige authentificatietokens kan houden. Deze nieuwe opslag heeft op geen enkele wijze invloed op de openbare API van AccessEnabler en vereist geen wijzigingen aan de kant van de programmeur. Hier volgt een voorbeeld van deze nieuwere functionaliteit:

In oudere versies van AccessEnabler, zou Stap 6 de gebruiker als niet-voor authentiek verklaard teruggeven, omdat de symbolische opslag vroeger slechts één authentificatietoken steunde.

OPMERKING: Als u zich afmeldt bij een programmeur-/MVPD-sessie, wordt de onderliggende opslag gewist, inclusief alle andere programmamarkerverificatietokens op het apparaat met SSO. Tokens die voor andere MVPD's of niet via SSO zijn verkregen, worden niet verwijderd. De verificatiestroom annuleren (aanroepen) setSelectedProvider(null)) zal NIET de onderliggende opslag ontruimen, maar zal slechts de huidige de authentificatiepoging van Programmer/MVPD beïnvloeden (door MVPD voor de huidige Programmer te wissen).

Een andere opslag-verwante eigenschap die in AccessEnabler 1.7 inbegrepen is maakt het mogelijk om authentificatietokens van oudere opslaggebieden in te voeren. Deze "Symbolische Importer"helpt om verenigbaarheid tussen opeenvolgende versies te bereiken AccessEnabler, die de SSO staat handhaven zelfs wanneer de opslagversie wordt bevorderd.

De importeur wordt uitgevoerd tijdens de setRequestor() stroom, en looppas in de volgende twee scenario's (veronderstellend dat geen geldig authentificatietoken voor huidige Programmer in de huidige opslag aanwezig is):

De importbewerking is transparant voor de programmeur en vereist geen codewijziging in de clienttoepassing.

Indeling format

Verificatietoken authn_token

Hieronder ziet u de indeling van het verificatietoken:

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

Token voor autorisatie authz_token

De onderstaande lijst geeft de indeling van de machtigingstoken weer:

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

Token voor korte media short_media_token

Hieronder ziet u de indeling van de token voor korte media. Dit teken wordt blootgesteld aan de toepassing van de Programmer. Het wordt doorgegeven aan de toepassing van de programmeur na een succesvol machtigingsproces:

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

Apparaatbinding device_binding

Let in de bovenstaande XML-items op de tag met de titel simpleTokenFingerprint. Het doel van deze tag is om de individualisatiegegevens van de native apparaat-id op te slaan. De bibliotheek AccessEnabler kan dergelijke individualisatieinformatie verkrijgen en het ter beschikking stellen van de diensten van de Authentificatie van Adobe Pass tijdens de machtigingsvraag. De dienst zal deze informatie gebruiken en zal het in de daadwerkelijke tokens inbedden, zo effectief binden de tokens aan een specifiek apparaat. Het uiteindelijke doel hiervan is om de tokens niet-overdraagbaar te maken op verschillende apparaten.

Let in de bovenstaande XML-lijsten op de tag simpleTokenFingerprint. Het doel van deze tag is om de individualisatiegegevens van de native apparaat-id op te slaan. De bibliotheek AccessEnabler kan dergelijke individualisatieinformatie verkrijgen en het ter beschikking stellen van de diensten van de Authentificatie van Adobe Pass tijdens de machtigingsvraag. De dienst zal deze informatie gebruiken en zal het in de daadwerkelijke tokens inbedden, zo effectief binden de tokens aan een specifiek apparaat. Het uiteindelijke doel hiervan is om de tokens niet-overdraagbaar te maken op verschillende apparaten.

Aangezien dit duidelijk een veiligheids verwante eigenschap is, is deze informatie inherent "gevoelig"uit veiligheidsoogpunt. Daarom moet deze informatie worden beschermd tegen knoeien en afluisteren. Het afluisterprobleem wordt opgelost door de verificatie-/autorisatieverzoeken via het HTTPS-protocol te verzenden. De manipulatiebeveiliging wordt afgehandeld door de apparaatidentificatiegegevens digitaal te ondertekenen. De AccessEnabler-bibliotheek berekent een apparaat-id aan de hand van de informatie die door het apparaat wordt verstrekt en verzendt de apparaat-id vervolgens "in the clear" naar de Adobe Pass-verificatieservers als een aanvraagparameter. De servers van de Authentificatie van Adobe Pass ondertekenen digitaal apparatenidentiteitskaart met de privé sleutel van de Adobe en voegen het aan het authentificatietoken toe dat aan AccessEnabler is teruggekeerd. Aldus wordt apparaat-id gebonden aan het verificatietoken. Tijdens de vergunningsstroom, verzendt AccessEnabler opnieuw apparatenidentiteitskaart in duidelijk, samen met het authentificatietoken. Als het validatieproces mislukt, mislukt de verificatie-/autorisatieworkflows automatisch. De Adobe Pass-verificatieservers passen de persoonlijke sleutel toe op de apparaat-id en vergelijken deze met de waarde in het verificatietoken. Als ze niet overeenkomen, mislukt die machtigingsstroom.