spring 多租户
本文将解释我们的方法和实现。
我们需要为Saas应用程序建立身份验证机制。 每个客户都通过专用子域访问该应用程序。 由于该应用程序将部署在云上，因此很明显，无状态会话是首选，因为它使我们能够轻松部署其他实例。
在项目词汇表中，每个客户都是一个站点。 每个应用程序都是一个应用程序。 例如，站点可以是Microsoft或Google。 应用可以是Gmail，GooglePlus或Google云端硬盘。 用户用于访问应用程序的子域将包括应用程序和网站。 例如，它可能看起来像microsoft.mail.somedomain.com或google.map.somedomain.com
用户一旦登录到一个应用程序，就可以访问同一站点的任何其他应用程序。 在一定的非活动时间后，会话将超时。
具有超时的无状态应用程序并不是什么新鲜事物。 Play框架从2007年的第一个版本开始就一直是无状态的。很多年前，我们也切换到了无状态会话。 好处很明显。 您的负载均衡器不需要粘性； 因此，它更易于配置。 在浏览器中进行会话时，我们可以简单地引入新服务器以立即增加容量。 但是，缺点是您的会话不太大，也不是那么机密。
与会话存储在服务器中的有状态应用程序相比，无状态应用程序将会话存储在HTTP cookie中，该cookie不能超过4KB。 此外，由于它是cookie，因此建议开发人员仅将文本或数字存储在会话中，而不要存储复杂的数据结构。 会话存储在浏览器中，并在每个单个请求中传输到服务器。 因此，我们应该使会话尽可能小，并避免在其上放置任何机密数据。 简而言之，无状态会话迫使开发人员改变应用程序使用会话的方式。 应该是用户身份，而不是方便存储。
Security Framework背后的想法非常简单，它有助于确定执行代码的原理，检查他是否有权执行某些服务，如果用户没有权限则抛出异常。 在实现方面，安全框架以AOP样式体系结构与您的服务集成。 每次检查都将在调用方法之前由框架进行。 实现权限检查的机制可以是过滤器或代理。
通常，安全框架会将主体信息存储在线程存储中（Java中的ThreadLocal）。 这就是为什么它可以随时为开发人员提供静态方法访问主体的原因。 我认为这是开发人员应该知道的一些事情； 否则，他们可能会在单独线程中运行的某些后台作业中实施权限检查或获取委托人。 在这种情况下，很明显，安全框架将无法找到主体。
单一登录主要使用身份验证服务器来实现。 它独立于实现会话（无状态或有状态）的机制。 每个应用程序仍保持自己的会话。 首次访问应用程序时，它将与身份验证服务器联系以对用户进行身份验证，然后创建自己的会话。
由于无状态会话是标准，因此我们最大的顾虑是使用或不使用安全框架。 如果使用的话，那么Spring Security是最便宜，最快的解决方案，因为我们已经在应用程序中使用了Spring Framework。 为了利益，任何安全框架都为我们提供了快速和声明性的方式来声明评估规则。 但是，它不是业务逻辑感知的访问规则。 例如，我们可以定义仅代理可以访问产品，而不能定义一个代理只能访问属于他的某些产品。
在这种情况下，我们有两种选择，从头开始构建我们自己的业务逻辑许可权检查，或者构建两层许可权检查，一种仅基于角色，一种是业务逻辑感知。 比较两种方法之后，我们选择了后一种方法，因为它更便宜且构建速度更快。 我们的应用程序的功能将
