Overzicht iOS/tvOS SDK iostvos-sdk-overview

Inleiding intro

iOS AccessEnabler is een Objectieve C iOS/tvOS-bibliotheek waarmee mobiele apps Adobe Pass Authentication for TV Anywhere's machtigingsservices kunnen gebruiken. De uitvoering bestaat uit AccessEnabled interface die de API voor machtiging definieert, en de EntitlementDelegate en EntitlementStatus protocollen die de callbacks beschrijven die de bibliotheek teweegbrengt. De interface samen met het protocol wordt bedoeld onder één gemeenschappelijke naam: de bibliotheek AccessEnabler.

iOS- en tvOS-vereisten reqs

Voor de huidige technische vereisten met betrekking tot het iOS- en tvOS-platform en de Adobe Pass-verificatie, raadpleegt u Vereisten voor platform/apparaat/gereedschapen raadpleeg de releaseopmerkingen die zijn opgenomen in de SDK-download. In de rest van deze pagina ziet u secties waarin wijzigingen worden vermeld die van toepassing zijn op bepaalde SDK-versies en hoger. Hier volgt bijvoorbeeld een legitieme opmerking met betrekking tot de 1.7.5-SDK:

Native clientworkflows begrijpen flows

Native clientworkflows zijn doorgaans gelijk aan of lijken sterk op die van Adobe Pass-verificatieclients op browserbasis. 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 een eigen iOS-client, na uw eerste oproep aan setRequestor()hebt u een keuze voor de volgende stappen:

U kunt kiezen of uw app wacht op een melding van het succes van setRequestor() of het hebben baseert zich op het mechanisme van de vraagrij van AccessEnabler. 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 deze workflow voor native clients verschilt 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 wordt afmelding op dezelfde manier afgehandeld als het hierboven beschreven verificatieproces.

De logout stroom verschilt van de authentificatiestroom in die zin dat de gebruiker niet wordt vereist om met interactie aan te gaan UIWebView/WKWebView or SFSafariViewController op welke manier dan ook. Daarom adviseert de Adobe dat u de controle onzichtbaar (d.w.z. verborgen) tijdens het logout proces maakt.

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 iOS-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 BRON caching door AccessEnabler. Er kunnen meerdere machtigingstokens in de cache zijn opgeslagen, maar deze zijn gekoppeld aan verschillende bronnen. Wanneer een nieuw machtigingstoken wordt uitgegeven en er al een bestaat voor dezelfde resource, overschrijft het nieuwe token de bestaande waarde in de cache.

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.

iOS

De iOS AccessEnabler-bibliotheek werkt aan de oplossing van de problemen bij het delen van toepassingsgegevens door de tokengegevens op te slaan in een gegevensstructuur die vergelijkbaar is met het klembord, de zogenaamde plakbord. Dit systeem-vlakke gedeelde middel verstrekt de belangrijkste ingrediënten die de implementatie van de gewenste blijvende tokens gebruiksgeval 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:

tvOS

Aangezien het plakbord op tvOS niet beschikbaar is, gebruikt de bibliotheek tvOS AccessEnabler de NsUserDefaults als opslagoptie. Dit lost het probleem van het voortbestaan authentificatie en toestemmingstkens op maar de opgeslagen informatie kan niet onder verschillende toepassingen worden gedeeld.

iOS 10 Pasteboard-wijzigingen - Wanneer u een upgrade uitvoert vanaf een eerdere versie van iOS, wordt het plakbord gewist. Dit betekent dat alle toepassingen opnieuw moeten worden geverifieerd.

iOS 7 Pasteboard-wijzigingen - Als gevolg van wijzigingen in de werking van plakborden op iOS 7, is de Cross SSO beperkt tussen toepassingen die op iOS 7 worden uitgevoerd. Toepassingen die dezelfde <Bundle Seed ID>(ook bekend als <Team ID>) deelt tokens, wat betekent dat apps A1 en A2 van dezelfde programmeur X tokens delen, terwijl app A1 (programmeur X) en app A3 (programmeur Y) geen tokens delen.

Lees deze technische notitie voor meer informatie over het configureren van SSO op iOS 7 en hoger (de technische notitie is van toepassing op Access Enabler v1.8 en hoger): https://tve.zendesk.com/entries/58233434-Configuring-Pay-TV-pass-SSO-on-iOS

Token Storage (AccessEnabler 1.7)

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

Als u zich afmeldt bij een programmeur-/MVPD-sessie, wordt de volledige onderliggende opslag gewist, inclusief alle andere programma-/MVPD-verificatietokens op het apparaat. Anderzijds, annuleert het annuleren van de authentificatiestroom (het aanhalen van setSelectedProvider(null)) zal NIET de onderliggende opslag ontruimen, maar het zal slechts het huidige programma/MVPD authentificatiepoging beïnvloeden (door MVPD voor de huidige Programmer te wissen).

Token Importer (AccessEnabler 1.7)

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 loopt in de volgende twee scenario's (veronderstellend dat geen geldig authentificatietoken voor huidige programmeur in de huidige opslag aanwezig is):

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

Token Sanitizer (AccessEnabler 1.7.5)

Van AccessEnabler 1.7.5 door:sturen, loopt deze dienst op setRequestor(). Het is ontwikkeld als resultaat van de iOS 7-switch van het WiFi MAC-adres naar het IDFA voor tracering. De sanitizer zorgt ervoor dat de huidige opslag alleen geldige verificatietokens bevat (geldig in termen van de apparaat-id, eerder berekend met het MAC-adres, vóór iOS7). Met de Token Sanitizer worden alle ongeldige tokens verwijderd.

De Symbolische dienst Sanitizer is het nuttigst wanneer een toepassing AccessEnabler 1.7.5 op iOS 6 wordt gebruikt, en dan de gebruiker werkt aan iOS 7 bij. Als dit gebeurt, zijn alle verificatietokens die zijn verkregen op iOS 6 nu ongeldig (omdat het algoritme voor de apparaat-id is gewijzigd van het gebruik van het MAC-adres in de IDFA). De sanitizer zal alle ongeldige tokens ontruimen, en de gebruiker zal dan unauthenticated zijn.

Zonder de Symbolische Sanitizer die ongeldige tokens verwijdert, zou AccessEnabler geen vergunningen wegens de aanwezigheid van ongeldige authentificatietokens verkrijgen. Dit zou voor de eindgebruiker lastig blijken om te zuiveren, aangezien de berichten van de vergunningsfout cryptisch en niet overdreven nuttig kunnen zijn in het bepalen van wat het probleem veroorzaakte.

Indeling format

Merk op dat het formaat van de tokens AuthN en AuthZ hier voor achtergrondinformatie slechts inbegrepen zijn. De structuur van deze tokens kan op elk gewenst moment worden gewijzigd door Adobe Pass-verificatie. Programmeurs hoeven niet de nauwkeurige structuur van de tokens AuthN en AuthZ te kennen om hun apps uit te voeren, aangezien de tokens AuthN en AuthZ niet op het lokale apparaat worden blootgesteld. Het token Short Media is aan de toepassing van de programmeur worden blootgesteld.

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

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, zullen de workflows voor verificatie en autorisatie automatisch mislukken. 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.

Nota over ApparaatBinding in AccessEnabler 1.7.5: Beginnend met AccessEnabler 1.7.5, is er een verandering in hoe apparatenidentiteitskaart wordt berekend om individualiseringsinformatie voor een apparaat van iOS te verstrekken. Deze wijziging is het gevolg van een wijziging in iOS 7: vanaf iOS 7 biedt Apple niet langer het WiFi MAC-adres als traceringsoptie, ten gunste van de ID (Identifier for Advertisers) ervan. Aangezien de informatie over individualisatie voor een toepassing die op iOS 7 wordt uitgevoerd op IDFA is gebaseerd, en die informatie in de machtigingsstroomtokens wordt ingebed, betekent dit dat er een aantal verschillende mogelijke effecten op gebruikerservaring zijn die uit deze wijziging voortvloeien. De verschillende mogelijke effecten zijn gebaseerd op welke versie van iOS de gebruiker bijwerkt in combinatie met welke versie van AccessEnabler de programmeur bijwerkt. Voor details over deze verandering, zie de nota's van de Versie inbegrepen met AccessEnabler SDK 1.7.5.