iOS/tvOS SDK概述 iostvos-sdk-overview

简介 intro

iOS AccessEnabler是一个Objective C iOS/tvOS库，它使移动应用程序能够将Adobe Pass身份验证用于TV Everywhere的授权服务。 该实现包括定义权利API的​ AccessEnabler ​接口，以及描述库触发的回调的​ EntitlementDelegate ​和​ EntitlementStatus ​协议。 接口和协议在一个常用名称AccessEnabler库下被引用。

iOS和tvOS要求 reqs

有关iOS和tvOS平台以及Adobe Pass身份验证的当前技术要求，请参阅平台/设备/工具要求，并查阅SDK下载随附的发行说明。 在本页面的其余部分中，您会看到一些章节，其中记录了适用于特定SDK版本及更高版本的更改。 例如，以下是关于1.7.5 SDK的合理说明：

了解本机客户端工作流 flows

本机客户端工作流通常与基于浏览器的Adobe Pass身份验证客户端的工作流相同或非常相似。 但是，有一些例外，如下所述。

初始化后工作流 post-init

AccessEnabler支持的所有授权工作流都假定您之前已调用setRequestor()来建立您的身份。 进行此调用以仅提供一次请求者ID，通常在应用程序的初始化/设置阶段进行。

使用iOS Native Client，在首次调用setRequestor()后，您可以选择如何继续：

您可以选择让应用等待setRequestor()成功通知，或者依赖AccessEnabler的呼叫队列机制。 由于所有后续授权和身份验证请求都需要请求者ID和相关配置信息，因此setRequestor()方法会在初始化完成之前有效地阻止所有身份验证和授权API调用。

通用初始身份验证工作流 generic

此工作流的目的是使用用户的MVPD登录用户。 成功登录后，后端服务器会向用户颁发身份验证令牌。 虽然身份验证通常作为授权过程的一部分完成，但下面描述了身份验证如何单独工作，并且不包括任何授权步骤。

请注意，虽然此工作流对于本机客户端与典型的基于浏览器的身份验证工作流不同，但步骤1-5对于本机客户端和基于浏览器的客户端均相同。

注销工作流 logout

对于本机客户端，注销的处理方式与上面描述的身份验证过程类似。

注销流与身份验证流的不同之处在于，用户不需要以任何方式与UIWebView/WKWebView or SFSafariViewController控制器交互。 因此，Adobe建议您在注销过程中使控件不可见（即隐藏）。

令牌 tokens

定义和使用情况 definitions

Adobe Pass身份验证权利解决方案围绕Adobe Pass身份验证在成功完成身份验证和授权工作流后生成的特定数据段（令牌）的生成。 这些令牌存储在客户端的iOS设备本地。

令牌的生命周期有限；过期时，需要通过重新启动身份验证和/或授权工作流重新颁发令牌。

在授权工作流中颁发了三种类型的令牌：

身份验证和授权成功后，Adobe Pass身份验证将颁发身份验证、授权和短期媒体令牌。 这些令牌应缓存在用户设备上，并在其相关生命周期内使用。

缓存准则 caching

身份验证令牌

授权令牌

在任何给定时刻，AccessEnabler只缓存每个RESOURCE的一个授权令牌。 可以缓存多个授权令牌，但它们与不同的资源相关联。 每当发出新的授权令牌并且​ 同一资源 ​已存在旧的授权令牌时，新令牌将覆盖现有的缓存值。

媒体令牌

短时间的媒体令牌根本不应缓存。 每次调用授权API时，应该从服务器检索媒体令牌，因为它仅限于一次性使用。

持久性 persistence

令牌需要在同一应用程序的连续运行中保持持久性。 这意味着，一旦获取了身份验证和授权令牌并且用户关闭了应用程序，当用户重新打开应用程序时，应用程序可以使用相同的令牌。 此外，还希望这些令牌能够在多个应用程序中持续存在。 换言之，当用户使用一个应用程序与特定的身份提供者登录后（成功获取身份验证和授权令牌），可以通过不同的应用程序使用相同的令牌，并且在通过同一身份提供者登录时不再提示用户输入凭据。 正是这种无缝的身份验证/授权工作流程使Adobe Pass身份验证解决方案成为了无处不在的真正电视节目
实现。

iOS

iOS AccessEnabler库通过将令牌数据存储到名为​ 粘贴板 ​的“类似剪贴板”数据结构来解决跨应用程序数据共享问题。 此系统级共享资源提供支持实施所需永久令牌用例的关键组件：

一旦特定令牌放入令牌缓存中，AccessEnabler库将在不同时间检查其有效性。 有效的令牌定义为：

tvOS

由于粘贴板在tvOS上不可用，因此tvOS AccessEnabler库使用NsUserDefaults作为存储选项。 这解决了持久化身份验证和授权令牌的问题，但是所存储的信息不能在不同应用程序之间共享。

iOS 10粘贴板更改 — ​从以前版本的iOS升级时，将擦除粘贴板。 这意味着所有应用程序都需要重新进行身份验证。

iOS 7粘贴板更改 — ​由于粘贴板在iOS 7上的功能发生了更改，在iOS 7上运行的应用程序之间的跨SSO将受限。 具有相同<Bundle Seed ID>（也称为<Team ID>）的应用程序将共享令牌，这意味着来自同一程序员X的应用程序A1和A2将共享令牌，而应用程序A1 （程序员X）和应用程序A3 （程序员Y）将不共享令牌。

请阅读此技术说明，了解有关在iOS 7和更高版本上配置SSO的更多信息（此技术说明适用于Access Enabler v1.8和更高版本）： https://tve.zendesk.com/entries/58233434-Configuring-Pay-TV-pass-SSO-on-iOS

令牌存储(AccessEnabler 1.7)

从AccessEnabler 1.7开始，令牌存储可以支持多个Programmer-MVPD组合，依赖于可以保存多个身份验证令牌的多级嵌套映射结构。 此新存储不会以任何方式影响AccessEnabler公共API，并且不需要程序员进行更改。 下面是一个示例，
说明了此新功能：

在旧版AccessEnabler中，步骤6会将用户呈现为“未验证”，因为以前令牌存储仅支持一个身份验证令牌。

从某个程序员/MVPD会话注销将清除整个底层存储，包括设备上的所有其他程序员/MVPD身份验证令牌。 另一方面，取消身份验证流程（调用setSelectedProvider(null)）将不会清除基础存储，但只会影响当前的程序员/MVPD身份验证尝试（通过清除当前程序员的MVPD）。

令牌导入器(AccessEnabler 1.7)

AccessEnabler 1.7中包含的另一个与存储相关的功能允许从旧存储区域导入身份验证令牌。 此“令牌导入器”有助于在连续的AccessEnabler版本之间实现兼容性，即使在存储版本升级时也能保持SSO状态。 导入程序在setRequestor()流期间执行，并在以下两种情况下运行（假设当前存储中不存在当前程序员的有效身份验证令牌）：

导入操作对程序员是透明的，不需要在客户端应用程序中进行任何代码更改。

令牌清理器(AccessEnabler 1.7.5)

从AccessEnabler 1.7.5开始，此服务在setRequestor(). 上运行。它是通过iOS 7从WiFi MAC地址切换到IDFA进行跟踪而开发的。 清理器可确保当前存储仅包含有效的身份验证令牌(根据设备ID有效，以前使用MAC地址计算，在iOS7之前)。 令牌清理器会删除所有无效令牌。

在iOS 6上使用AccessEnabler 1.7.5应用程序，然后用户更新到iOS 7时，“令牌清理器”服务最有用。 发生这种情况时，在iOS 6上获取的所有身份验证令牌现在都将无效(因为设备ID算法已由使用MAC地址更改为IDFA)。 清理器将清除所有无效令牌，然后用户将进行未经身份验证。

如果没有令牌清理器删除无效令牌，AccessEnabler将无法获取授权，因为存在无效的身份验证令牌。 这将证明最终用户很难调试，因为授权错误消息可能很隐秘，并且对于确定导致问题的原因没有太大帮助。

格式 format

请注意，此处包含的AuthN和AuthZ令牌格式仅供背景信息使用。 Adobe Pass身份验证可随时更改这些令牌的结构。 程序员无需知道AuthN和AuthZ令牌的确切结构即可实施其应用程序，因为AuthN和AuthZ令牌不会公开在本地设备上。 短媒体令牌​ 对程序员的应用程序公开。

身份验证令牌 authn_token

下表显示了身份验证令牌的格式：

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

授权令牌 authz_token

以下列表显示了授权令牌的格式：

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

短媒体令牌 short_token

以下列表显示了短媒体令牌的格式。 此令牌向程序员的应用程序公开。 在成功的权利流程结束时，它会传递给程序员应用程序：

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

设备绑定 device_binding

在上面的XML列表中，记下标题为simpleTokenFingerprint的标记。 此标记用于保存本机设备ID个性化信息。 AccessEnabler库能够获得此类个性化信息，并在授权调用期间将其提供给Adobe Pass身份验证服务。 该服务将使用此信息并将其嵌入到实际令牌中，从而有效地将令牌绑定到特定设备。 这样做的最终目标是使令牌无法跨设备传输。

由于这显然是安全相关功能，因此从安全的角度来看，此信息本身就具有“敏感性”。 因此，需要保护此信息不被篡改和窃听。 通过通过HTTPS协议发送身份验证/授权请求，解决了窃听问题。 通过数字签名设备标识信息来处理篡改保护。 AccessEnabler库根据设备提供的信息计算设备ID，然后将设备ID“完全清除”作为请求参数发送到Adobe Pass身份验证服务器。 Adobe Pass身份验证服务器使用Adobe的私钥对设备ID进行数字签名，并将其添加到返回到AccessEnabler的身份验证令牌。 因此，设备ID与身份验证令牌绑定。 在授权流期间，AccessEnabler再次发送清除的设备ID以及身份验证令牌。 验证过程失败将自动导致身份验证/授权工作流失败。 Adobe Pass身份验证服务器将私钥应用于设备ID，并将其与身份验证令牌中的值进行比较。 如果二者不匹配，则权利流将失败。

关于AccessEnabler 1.7.5中的设备绑定的注意： ​从AccessEnabler 1.7.5开始，设备ID的计算方式发生了变化，从而为iOS设备提供个性化信息。 此更改反映了iOS 7中的更改：从iOS 7开始，Apple不再提供WiFi MAC地址作为跟踪选项，而是提供其广告商标识符(IDFA)。 由于在iOS 7上运行的应用程序的个性化信息基于IDFA，并且该信息嵌入在权利流令牌中，这意味着此更改可能会对用户体验产生许多不同的影响。 不同的可能效果取决于用户从中升级的iOS版本，以及程序员从中升级的AccessEnabler版本。 有关此更改的详细信息，请参阅AccessEnabler SDK 1.7.5中包含的发行说明。