越来越多的组织转向了软件即服务（SaaS），把它做为解决企业需求的一种方法，而不必承担管理和维护应用的负担。作为SaaS的用户，你必须得到供应商的保证，他们是否充分保护你财产中的数据。但是一旦涉及到使用本地应用集成基于云的应用时，一致性和访问管理就是你的责任了。

　　集成SaaS和本地应用不会改变安全实践太多，随着更广泛的治理的产生。这成为了一个问题“你怎样建立一个规则，规定谁可以使用云资源，以及怎样使用，”Jason Bloomberg说，Dovel技术公司ZapThink的总裁。

　　“最初的考虑与身份管理有关。如果你有第三方的SaaS应用，那么你就不会发现所有内部用户的身份和权限，”Bloomberg说。例如，SaaS应用可能提供了访问权限控制，但它们不控制组织内部的使用权限。

　　另外，集成SaaS应用和本应用的组织冒着“暴露访问凭证，给恶意软件提供访问本地资源的权限”的风险，Scott Crawford说，他是企业管理协会（Enterprise Management Associates）的管理研究主管。“你想要保护凭证不受那样的利用。”

　　当本地应用需要与基于的应用交互是，本地应用就需要“告诉”基于云的应用，用户确实是得到正确的授权来做所有他或她想做的。这是通过授权标记到云上的一件事，Bloomberg解释说。然而，这并不如听起来那么简单，因为云不能总是理解用户使用的授权方式。

　　“云供应商对于用户供给品的细粒度控制有不同的支持，因此可以给各种不同的功能建议权限。通常，一个SaaS供应商给一个用户只提供一个登录，或允许你进入他们的系统和提供用户。它会根据内部用户的环境不同而设置不同。这变成了一项挑战。你怎样扩展你的身份管理到云中？” Bloomberg说。

　　在某些情况下，SaaS提供商可能提供功能使用企业身份访问他们的应用程序。例如，SalesForce最近介绍的SalesForce Identity，它提供了一个单一可靠的身份，可以用于访问所有企业应用。尽管如此，不是所有的SaaS供应商都提供这一功能，而且责任在于用户。

　　“从SaaS供应商的角度来看，所见即所得，”Bloomberg说。“面临的挑战是从根本上提供给内部用户产品用于使用第三方应用，然后建立和加强规范，规定谁可以使用那个应用，并在本质上联合身份到云上，”他说。

　　第三方解决方案就像来自于Okta和Symplified所提供给SaaS应用的单点登录服务一样。这些联合身份验证技术依赖于一个标识，代表成功识别个人与企业注册，并且把这个标识传递给应用程序，而不用暴露，Crawford解释道。

　　联合身份验证技术位于本地非军事区（demilitarized zone），并管理着所有本地应用向SaaS应用的请求。“来自于本地的所有请求必须受到控制。而唯一的办法就是通过这个备用的治理工具。该是治理工具来决定是否所有请求得到正确授权，” Bloomberg说。

　　这些联合身份验证工具，也被称为云治理工具，云治理应用和身份管理即服务，是单点登录的产物。客观说，用户有单独的用户名和密码对于他们的本地应用程序。IT组织试图在这些资源中充分利用单点登录，并且已经成功地以一个用户名和登录，使用Microsoft Active Directory来支持用户访问微软资源。同样，联合身份验证允许用户登录到一个Web应用程序和进行其它访问。“我们现在来看看，通过更加无缝给用户受权，来扩展SaaS环境到一个更广的功能上，” Crawford说。