REST API Cookbook (Server-to-Server) rest-api-cookbook-server-to-server
Overzicht overview
Het doel van dit kookboekdocument is om beste praktijken voor het uitvoeren van de Authentificatie van Adobe Pass te detailleren gebruikend de server-aan-Server architectuur. Het verstrekt basisvereisten, geleidelijke stroomimplementatie en algemene overwegingen voor productiemilieu's en verrichting.
Draaimechanisme
De Adobe Pass Authentificatie REST API wordt geregeerd door a het Throttling mechanisme.
Componenten components
In een werkende server-aan-server oplossing zijn de volgende componenten betrokken:
Aanvullende termen die in de flow worden gebruikt, worden gedefinieerd in de
Verklarende woordenlijst.
Stromen flows
Dynamische clientregistratie (DCR)
Adobe Pass gebruikt DCR om clientcommunicatie tussen een programmeertoepassing of server en de Adobe Pass-services te beveiligen. De stroom DCR is afzonderlijk en beschreven in het Dynamische Overzicht van de Registratie van de Cliëntdocumentatie.
Verificatie (authN)
De authentificatiestroom wordt gebruikt om een gebruiker toe te staan om zich te identificeren
aan hun MVPD om te bepalen of de gebruiker een geldige rekening heeft.
- De gebruiker start de Streaming Device-app en probeert zich aan te melden of beveiligde inhoud weer te geven.
- De toepassing Streaming Device (Streaming Device) vraagt de programmeerservice of het apparaat al is geverifieerd.
- De programmeerservice registreert de toepassing met DCR.
- De Dienst van de Programmer controleert de Streaming status van Device AUthN door de dienst van Adobe Pass checkauthn API te roepen.
- Voor het geval waar de controleauteur vraag de status terugkeert die het Apparaat van de Gebruiker voor authentiek wordt verklaard, dan kan app aan de stroom van de Vergunning te werk gaan.
- Voor het geval waar de controleauteur vraag de status terugkeert die het Apparaat van de Gebruiker NIET voor authentiek wordt verklaard, dan zou app op een gebruikersverzoek moeten wachten om login.
- Wanneer de gebruiker om direct login (b.v. selecteert login knoop) of onrechtstreeks login (b.v. selecteert beschermde inhoud wanneer niet reeds voor authentiek verklaard), doet de Streaming Apparaat app een verzoek aan de Dienst van de Programmer om gebruikersauthentificatie in werking te stellen. De dienst van de Programmer verzoekt en ontvangt een unieke registratiecode (regcode) door de Dienst van Adobe Pass te roepen regcode API.
- De dienst van de Programmer wint ook de lijst van huidige MVPDs en attributen terug door de Dienst van Adobe Pass config API te roepen. Opmerking: deze API kan ook eerder in de flow en cache worden aangeroepen.
- De programmeerservice retourneert de regcode naar de app Streaming Device en de verwerkte MVPD-lijst die is aangevraagd in stap #7. Opmerking: de verwerkte MVPD-lijstindeling wordt opgegeven door de programmeur en kan worden gefilterd om specifieke MVPD's (dat wil zeggen allow- of block-lists) expliciet toe te staan of te blokkeren.
- Als het apparaat van AuthN (d.w.z. "tweede scherm"), of door keus of behoefte (d.w.z. het Streaming Apparaat steunt geen Agent van de Gebruiker) verschillend is, dan zou het Streaming Apparaat de regcode en URI voor de gebruiker moeten tonen om tot de Toepassing van AuthN toegang te hebben. De gebruiker typt URI in de Agent van de Gebruiker op het Apparaat AuthN om de Toepassing te lanceren AuthN, en typt dan regcode in die toepassing. Als het Streaming Apparaat het zelfde als het Apparaat AuthN is, dan kan regcode programmatically tot de Module worden overgegaan AuthN.
- De module AuthN stelt de gebruikersauthentificatie met MVPD door een Plukker te tonen MVPD in werking. Nadat de gebruiker MVPD selecteert, verklaart de Module AuthN met regcode voor authentiek, die de Agent van de Gebruiker aan MVPD IdP opnieuw richt. Wanneer de gebruiker met succes met MVPD voor authentiek verklaart, wordt de Agent van de Gebruiker opnieuw gericht terug door de Dienst van Adobe Pass, waar de succesvolle authentificatie met regcode wordt geregistreerd, en dan opnieuw gericht terug naar de Module AuthN.
- Als het streamingapparaat verschilt van het AuthN-apparaat, geeft het AuthN-apparaat een succesvol verificatiebericht weer aan de gebruiker en worden de stappen uitgevoerd (bijvoorbeeld "Success!! U kunt nu terugkeren naar uw gameconsole om door te gaan met […]"). Als het streamingapparaat hetzelfde is als het AuthN-apparaat, kan het streamingapparaat de voltooiing van de verificatie programmatisch detecteren.
Het volgende diagram illustreert de authentificatiestroom:
Autorisatie (authZ)
De machtigingsstroom wordt gebruikt om te bepalen of een gebruiker toegang heeft tot gevraagde inhoud.
- Telkens wanneer de gebruiker beveiligde inhoud probeert te bekijken op de Streaming Device-app, roept de Streaming Device-app de Programmer Service aan om de inhoud te identificeren en om toestemming en informatie te vragen die nodig zijn om de stream te starten.
- De dienst van de Programmer roept Adobe Pass API goedkeurt die identiteitskaart van het Middel samen met andere vereiste parameters overgaat. De dienst van Adobe roept de Dienst MVPD AuthZ met identiteitskaart van het Middel en ontvangt en vergunningsbesluit dat dan aan de Dienst van de Programmer wordt overgegaan. Dit vergunningsbesluit zal door de Dienst van Adobe Pass voor een configureerbare periode in het voorgeheugen ondergebracht worden. Op verdere machtigt vraag van de Dienst van de Programmer aan de Dienst van Adobe Pass, zal de caching waarde zijn teruggekeerd zolang het geldig is.
- Als de vergunning wordt verleend, zou de Dienst van de Programmer Adobe Pass /tokens/media API moeten roepen, die een ondertekend media teken zal terugkeren. De programmeerservice moet het mediatoken valideren met behulp van de JAR (Media Token Verifier Library). Indien geldig, zou de Dienst van de Programmer toestemming en nodig moeten terugkeren om de stroom (b.v. stroom URL) te beginnen die in stap #1 wordt gevraagd.
- Als de vergunning wordt ontkend, goedkeurt vraag zal een foutencode en een beschrijving aan de Dienst van de Programmer terugkeren. De dienst van de Programmer zou de foutencode en de beschrijving (of een programma gewijzigd bericht) aan het verzoek in stap #1 moeten terugkeren.
In het volgende diagram wordt de stroom van de autorisatie weergegeven:
Afmelden
Met de afmeldingsstroom kan de gebruiker de huidige identiteit verwijderen
is gekoppeld aan de toepassing.
- Wanneer de gebruiker om logout (d.w.z. verwijder van het apparaat de huidige rekening MVPD verbonden aan de toepassing) verzoekt, roept het Streaming Apparaat app de Dienst van de Programmer die het vertelt om het apparaat te logout.
- De dienst van de Programmer zou de Adobe Pass logout API moeten roepen.
Het volgende diagram illustreert de logout flow:
[Optioneel] Voorafgaande toestemming (ook bekend als voor de vlucht)
Voortoestemming kan worden gebruikt om van een reeks middelen snel te bepalen degenen een gebruiker toegang zou kunnen hebben. Het resultaat van deze vraag wordt typisch gebruikt om UI voor een individuele gebruiker aan te passen.
-
Zodra de gebruiker voor authentiek wordt verklaard, kan het Steaming Apparaat de Dienst van de Programmer roepen om de inhoud te verzoeken waarop de gebruiker gerechtigd is te stromen.
-
De dienst van de Programmer zou Adobe Pass moeten roepen pre goedkeurt API met een lijst van Middel IDs, die een eenvoudig koord zijn dat typisch een kanaal vertegenwoordigt een gebruiker zou kunnen gerechtigd zijn om te stromen. Nota: Momenteel, machtigt vraag vooraf om de lijst tot vijf (5) Middel IDs te beperken. Wanneer meer dan vijf middelen nodig zijn, machtigt het veelvoud vraag kan worden gemaakt, of de vraag kan worden gevormd om meer dan vijf middelen met een overeenkomst van MVPDs goed te keuren. De uitvoerders zouden in mening de kosten van a moeten houden pre machtigt vraag zowel aan middelen MVPD evenals de reactietijd aan de Programmer en structureren hun gebruik van de vraag oordeelkundig.
-
De pre autoriseert vraag zal aan de Dienst van de Programmer met een voorwerp JSON antwoorden die een WAAR of VALS waarde voor elke identiteitskaart van het Middel in het verzoek bevatten die erop wijst of de gebruiker aan het bijbehorende kanaal of niet gerechtigd is. Nota: Als een MVPD geen antwoord voor bepaalde identiteitskaart van het Middel (b.v. wegens netwerkfouten of onderbrekingen) verstrekt, zal de waarde aan VALS in gebreke blijven.
-
De dienst van de Programmer zou vraagreactie moeten gebruiken preauthorize om tot een programmeur-bepaalde douanerespons aan het Streaming Apparaat te leiden, typisch om de presentatie aan de gebruiker te personaliseren die op hun rechten wordt gebaseerd.
In het volgende diagram wordt de stroom voorafgaand aan de autorisatie weergegeven:
Metagegevens [optioneel]
De meta-gegevens kunnen worden gebruikt om gebruikersinformatie terug te winnen die door MVPD wordt gedeeld.
Voorbeelden hiervan kunnen gebruikers-id, postcode enzovoort zijn.
-
Zodra de gebruiker voor authentiek wordt verklaard, kan de Dienst van de Programmer Adobe Pass gebruikersmeta-gegevens API roepen om informatie over de voor authentiek verklaarde gebruiker te verzoeken.
-
De reactie omvat alle metagegevens die beschikbaar zijn voor de opgegeven gebruiker. De specifieke gebieden worden gevormd afzonderlijk voor elke integratie Programmer/MVPD.
In het volgende diagram wordt de stroom voorafgaand aan de autorisatie weergegeven:
Omgevingen en functionele vereisten environments
Een programmeur moet ten minste twee omgevingen maken: een voor productie en een of meer voor staging.
Productie
De productieomgeving moet in hoge mate beschikbaar zijn en op passende wijze worden geschaald voor grote of onverwachte pieken (bv. live sporten, breken
nieuws).
De Adobe Pass-service wordt uitgevoerd op meerdere datacenters die geografisch over de hele VS zijn verspreid. Om de beste reactietijd (d.w.z. laagste latentie) van de dienst van Adobe Pass te bereiken, zou de Programmer ook een gelijkaardige geografisch verspreide dienst moeten creëren
infrastructuur.
De dienst van de Programmer zou het DNS geheime voorgeheugen tot maximaal 30 s moeten beperken voor het geval de Adobe verkeer moet terugleiden. Dit kan zich voordoen als een datacenter niet beschikbaar is.
De programmeur zou de openbare IP waaier van het productiemilieu moeten verstrekken. Deze zullen in een toegestane lijst van IPs in de infrastructuur van Adobe Pass voor toegang worden ingegaan en door het Fair API gebruiksbeleid van Adobe worden beheerd.
Staging
De het opvoeren omgeving kan minimaal zijn, maar zou alle systeemcomponenten en bedrijfslogica moeten omvatten. Het moet op dezelfde wijze functioneren als de productie en het moet mogelijk maken om emissies buiten de productie te testen. In het ideale geval kan de testomgeving worden verbonden met de Adobe Pass-testomgevingen voor gebruik door de programmeur en door Adobe wanneer dat nodig is, zodat we hulp kunnen bieden bij het testen en oplossen van problemen.
Functionele vereisten
De dienst van de Programmer moet nauwkeurige apparatenidentificatieinformatie over het apparaat overgaan waarvoor zij de stromen uitvoeren. Bovendien, moet de dienst van de Programmer IP van het apparaat overgaan waarvoor zij de stromen (in x-door:sturen-voor kopbal) samen met de haven van de verbindingsbron (op het gebied van apparateninfo) uitvoeren:
**X-Door:sturen-voor: \<client\_ip \>*
waar \ <client\_ip \> het cliënt openbare IP adres
is de kopbal moet op **regcode* en ​** autorze* vraag
Voorbeelden worden toegevoegd:
POST /reggie/v1/{req\_id}/regcode HTTP/1.1
x-Door:sturen-voor:203.45.101.20
GET /api/v1/autoriseer HTTP/1.1
x-Door:sturen-voor:203.45.101.20
De programmeerservice moet gegevens en opmaak verzenden die vereist zijn voor afzonderlijke MVPD's of geïntegreerde apps (bijvoorbeeld apparaat-IP, bronpoort, apparaatinformatie, MRSS, optionele gegevens zoals ECID).
De dienst van de Programmer moet authN en authZ TTLs respecteren wanneer het caching en maakt authN of authZ zittingen onbruikbaar wanneer op de hoogte gebracht.
De programmeur moet certificaten onderhouden die met Adobe worden gedeeld.