Visão geral do SDK do iOS/tvOS iostvos-sdk-overview

Introdução intro

O iOS AccessEnabler é uma biblioteca Objetive-C iOS/tvOS que permite que aplicativos móveis usem os serviços de direito da Adobe Pass Authentication for TV Everywhere. A implementação consiste na interface AccessEnabler que define a API de direito e nos protocolos EntitlementDelegate e EntitlementStatus que descrevem os retornos de chamada acionados pela biblioteca. A interface junto com o protocolo é mencionada com um nome comum: a biblioteca AccessEnabler.

Requisitos do iOS e do tvOS reqs

Para obter os requisitos técnicos atuais relacionados à plataforma iOS e tvOS e à autenticação da Adobe Pass, consulte Requisitos de plataforma/dispositivo/ferramenta e consulte as notas de versão incluídas no download do SDK. Ao longo do restante desta página, você verá seções que observam alterações que se aplicam a versões específicas do SDK e superiores. Por exemplo, esta é uma observação legítima em relação ao SDK 1.7.5:

Noções básicas sobre fluxos de trabalho de clientes nativos flows

Os workflows do cliente nativo normalmente são os mesmos ou muito semelhantes aos dos clientes de Autenticação do Adobe Pass baseados em navegador. No entanto, há algumas exceções, conforme descrito abaixo.

Fluxo de trabalho de pós-inicialização post-init

Todos os fluxos de trabalho de direito suportados pelo AccessEnabler supõem que você tenha chamado anteriormente setRequestor() para estabelecer sua identidade. Você faz essa chamada para fornecer a ID do solicitante apenas uma vez, normalmente durante a fase de inicialização/configuração do aplicativo.

Com um cliente nativo do iOS, após sua chamada inicial para setRequestor(), você tem uma escolha sobre como proceder:

É sua escolha fazer com que seu aplicativo aguarde a notificação do sucesso de setRequestor() ou que ele dependa do mecanismo de fila de chamadas do AccessEnabler. Como todas as solicitações de autorização e autenticação subsequentes precisam da ID do solicitante e das informações de configuração associadas, o método setRequestor() bloqueia efetivamente todas as chamadas de API de autenticação e autorização até que a inicialização seja concluída.

Fluxo de trabalho genérico de autenticação inicial generic

A finalidade desse fluxo de trabalho é fazer logon em um usuário com seu MVPD. Após um logon bem-sucedido, o servidor de back-end emite um token de autenticação para o usuário. Embora a autenticação seja normalmente feita como parte do processo de autorização, a seguir está uma descrição de como ela pode funcionar isoladamente, sem incluir nenhuma etapa de autorização.

Observe que, embora esse fluxo de trabalho seja diferente para clientes nativos do fluxo de trabalho típico de autenticação baseada em navegador, as etapas 1 a 5 são as mesmas para clientes nativos e clientes baseados em navegador.

Fluxo de trabalho de logout logout

Para clientes nativos, o logout é tratado de forma semelhante ao processo de autenticação descrito acima.

O fluxo de logout difere do fluxo de autenticação na medida em que o usuário não é obrigado a interagir com o controlador UIWebView/WKWebView or SFSafariViewController de nenhuma maneira. Portanto, o Adobe recomenda que você torne o controle invisível (ou seja, oculto) durante o processo de logout.

Tokens tokens

Definições e uso definitions

A solução de direito de autenticação da Adobe Pass gira em torno da geração de dados (tokens) específicos que a autenticação da Adobe Pass gera após a conclusão bem-sucedida dos fluxos de trabalho de autenticação e autorização. Esses tokens são armazenados localmente no dispositivo iOS do cliente.

Os tokens têm uma duração limitada; após a expiração, os tokens precisam ser reemitidos por meio da reinicialização dos workflows de autenticação e/ou autorização.

Há três tipos de tokens emitidos durante os workflows de direito:

Após a autenticação e a autorização bem-sucedidas, a Autenticação do Adobe Pass emitirá tokens de autenticação, autorização e de mídia de vida curta. Esses tokens devem ser armazenados em cache no dispositivo do usuário e usados pela duração de suas vidas associadas.

Diretrizes de armazenamento em cache caching

Token de autenticação

Token de autorização

A qualquer momento, somente UM token de autorização POR RECURSO é armazenado em cache pelo AccessEnabler. Pode haver vários tokens de autorização em cache, mas eles estão associados a recursos diferentes. Sempre que um novo token de autorização for emitido e já existir um antigo para o mesmo recurso, o novo token substituirá o valor em cache existente.

Token de mídia

O token de mídia de vida curta NÃO deve ser armazenado em cache. O token de mídia deve ser recuperado do servidor sempre que uma API de autorização for chamada, pois está restrita ao uso único.

Persistência persistence

Os tokens precisam ser persistentes em execuções consecutivas do mesmo aplicativo. Isso significa que após a aquisição dos tokens de autenticação e autorização e o usuário fechar o aplicativo, os mesmos tokens ficarão disponíveis para o aplicativo quando o usuário reabrir o aplicativo. Além disso, é desejável que esses tokens sejam mantidos em vários aplicativos. Em outras palavras, depois que um usuário usa um aplicativo para fazer logon com um provedor de identidade específico (obtendo com êxito tokens de autenticação e autorização), os mesmos tokens podem ser usados por meio de um aplicativo diferente, e o usuário não recebe mais a solicitação de credenciais ao fazer logon por meio do mesmo provedor de identidade. Esse tipo de fluxo de trabalho de autenticação/autorização ininterrupta é o que torna a solução de autenticação da Adobe Pass uma verdadeira TV em qualquer lugar
execução.

iOS

A biblioteca do iOS AccessEnabler resolve os problemas de compartilhamento de dados entre aplicativos, armazenando os dados do token em uma estrutura de dados "semelhante à área de transferência" chamada de quadro de colagem. Esse recurso compartilhado no nível do sistema fornece os principais ingredientes que permitem a implementação do caso de uso de tokens persistentes desejado:

Depois que um token específico for colocado no cache de token, sua validade será verificada em momentos diferentes pela biblioteca do AccessEnabler. Um token válido é definido como:

tvOS

Como no tvOS a área de transferência não está disponível, a biblioteca tvOS AccessEnabler usa o NsUserDefaults como uma opção de armazenamento. Isso resolve o problema da persistência dos tokens de autenticação e autorização, mas as informações armazenadas não podem ser compartilhadas entre aplicativos diferentes.

Alterações da área de transferência do iOS 10 - Ao atualizar de uma versão anterior do iOS, a área de transferência será apagada. Isso significa que todos os aplicativos precisam ser reautenticados.

Alterações na área de transferência do iOS 7 - Devido a alterações em como as áreas de transferência funcionam no iOS 7, haverá um SSO cruzado limitado entre os aplicativos em execução no iOS 7. Aplicativos com o mesmo <Bundle Seed ID> (também conhecido como <Team ID>) compartilharão tokens, o que significa que os aplicativos A1 e A2 do mesmo Programador X compartilharão tokens, enquanto o aplicativo A1 (Programador X) e o aplicativo A3 (Programador Y) não compartilharão tokens.

Leia esta nota técnica para obter mais informações sobre como configurar o SSO no iOS 7 e superior (a nota técnica se aplica ao Access Enabler v1.8 e superior): https://tve.zendesk.com/entries/58233434-Configuring-Pay-TV-pass-SSO-on-iOS

Armazenamento de token (AccessEnabler 1.7)

A partir do AccessEnabler 1.7, o armazenamento de token pode suportar várias combinações de Programador-MVPD, dependendo de uma estrutura de mapa aninhada de vários níveis que possa conter vários tokens de autenticação. Esse novo armazenamento não afeta a API pública do AccessEnabler de nenhuma maneira e não requer alterações por parte do programador. Veja um exemplo de
O ilustra essa nova funcionalidade:

Nas versões anteriores do AccessEnabler, a Etapa 6 renderizava o usuário como não autenticado, pois o armazenamento do token anteriormente só tinha suporte para um token de autenticação.

Fazer logoff de uma sessão de Programador / MVPD limpará todo o armazenamento subjacente, incluindo todos os outros tokens de autenticação de Programador / MVPD no dispositivo. Por outro lado, cancelar o fluxo de autenticação (invocando setSelectedProvider(null)) NÃO limpará o armazenamento subjacente, mas afetará somente a tentativa de autenticação atual do Programador/MVPD (apagando o MVPD do Programador atual).

Importador de token (AccessEnabler 1.7)

Outro recurso relacionado ao armazenamento incluído no AccessEnabler 1.7 permite importar tokens de autenticação de áreas de armazenamento mais antigas. Esse "Importador de tokens" ajuda a obter compatibilidade entre versões consecutivas do AccessEnabler, mantendo o estado do SSO mesmo quando a versão de armazenamento é atualizada. O importador é executado durante o fluxo setRequestor() e é executado nos dois cenários a seguir (supondo que nenhum token de autenticação válido para o Programador atual esteja presente no armazenamento atual):

A operação de importação é transparente para o Programador e não requer nenhuma alteração de código no aplicativo cliente.

Limpeza de token (AccessEnabler 1.7.5)

A partir do AccessEnabler 1.7.5, este serviço é executado em setRequestor(). Ele foi desenvolvido como resultado da mudança do iOS 7 do endereço do MAC WiFi para o IDFA para rastreamento. A limpeza garante que o armazenamento atual contenha apenas tokens de autenticação válidos (válidos em termos da ID do dispositivo, antes calculada usando o endereço do MAC, antes do iOS7). O Limpador de tokens remove todos os tokens inválidos.

O serviço de Limpeza de token é mais útil quando um aplicativo AccessEnabler 1.7.5 é usado no iOS 6 e, em seguida, o usuário atualiza para o iOS 7. Quando isso acontecer, todos os tokens de autenticação obtidos no iOS 6 serão inválidos (devido ao algoritmo da ID do dispositivo, que mudou de usar o endereço do MAC para o IDFA). A limpeza apagará todos os tokens inválidos e o usuário não será autenticado.

Sem a remoção de tokens inválidos pela Limpeza de token, o AccessEnabler não conseguiria obter autorizações devido à presença de tokens de autenticação inválidos. Isso seria complicado para o usuário final depurar, já que as mensagens de erro de autorização podem ser criptografadas e não muito úteis para determinar a causa do problema.

Formato format

Observe que o formato dos tokens AuthN e AuthZ é incluído aqui apenas para obter informações de fundo. A estrutura desses tokens pode ser alterada pela Autenticação Adobe Pass a qualquer momento. Os programadores não precisam saber a estrutura exata dos tokens AuthN e AuthZ para implementar seus aplicativos, pois os tokens AuthN e AuthZ não são expostos no dispositivo local. O token de Short Media está exposto ao aplicativo do Programador.

Token de autenticação authn_token

A listagem abaixo apresenta o formato do token de autenticação:

  <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 de autorização authz_token

A lista abaixo apresenta o formato do token de autorização:

  <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 de mídia curta short_token

A lista abaixo apresenta o formato do token de mídia curta. Esse token é exposto ao aplicativo do Programador. Ele é transferido para o aplicativo do Programador ao final de um processo de qualificação bem-sucedido:

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

Vinculação de dispositivo device_binding

Nas listagens de XML acima, observe a marca intitulada simpleTokenFingerprint. A finalidade dessa tag é manter informações de individualização de ID de dispositivo nativas. A biblioteca do AccessEnabler pode obter essas informações de individualização e disponibilizá-las para os serviços de autenticação da Adobe Pass durante as chamadas de qualificação. O serviço usará essas informações e as incorporará aos tokens reais, vinculando, assim, efetivamente os tokens a um dispositivo específico. O objetivo final disso é tornar os tokens intransferíveis entre dispositivos.

Como esse é obviamente um recurso relacionado à segurança, essas informações são inerentemente "confidenciais" do ponto de vista da segurança. Como resultado, essas informações precisam ser protegidas contra violações e espionagem. O problema de espionagem é resolvido enviando as solicitações de autenticação/autorização pelo protocolo HTTPS. A proteção contra violação é tratada assinando digitalmente as informações de identificação do dispositivo. A biblioteca do AccessEnabler calcula uma ID de dispositivo a partir das informações fornecidas pelo dispositivo e, em seguida, envia a ID de dispositivo "em branco" para os servidores de autenticação da Adobe Pass como um parâmetro de solicitação. Os servidores de Autenticação do Adobe Pass assinam digitalmente a ID do dispositivo com a chave privada Adobe e a adicionam ao token de autenticação retornado ao AccessEnabler. Assim, a ID do dispositivo é vinculada ao token de autenticação. Durante o fluxo de autorização, o AccessEnabler envia novamente a ID do dispositivo sem criptografia, juntamente com o token de autenticação. A falha do processo de validação resultará automaticamente na falha dos workflows de autenticação/autorização. Os servidores de Autenticação do Adobe Pass aplicam a chave privada à ID do dispositivo e a comparam com o valor no token de autenticação. Se não corresponderem, o fluxo de direitos falhará.

Observação sobre Associação de Dispositivo no AccessEnabler 1.7.5: A partir do AccessEnabler 1.7.5, houve uma alteração na forma como a ID do dispositivo é calculada para fornecer informações de individualização para um dispositivo iOS. Esta alteração reflete uma mudança no iOS 7: a partir do iOS 7, a Apple não mais fornece o endereço WiFi MAC como uma opção de rastreamento, em favor do seu Identificador para anunciantes (IDFA). Como as informações de individualização de um aplicativo executado no iOS 7 são baseadas no IDFA e essas informações são incorporadas aos tokens de fluxo de direito, isso significa que há vários efeitos possíveis diferentes na experiência do usuário que resultam dessa alteração. Os diferentes efeitos possíveis são baseados em qual versão do iOS o usuário está atualizando combinada com qual versão do AccessEnabler o programador está atualizando. Para obter detalhes sobre essa alteração, consulte as Notas de versão incluídas com o AccessEnabler SDK 1.7.5.