我们有几个Grails应用程序使用共享插件，其中包括为其提供基本安全性。我们将来会添加其他类型的身份验证，因此使用Spring Security插件的想法已经出现。但是，我想知道它是否对我们相当基本的需求来说太强大了。
目前，我们使用在访问任何URL之前运行的Grails过滤器并执行安全检查。初始身份验证通过查找特定的加密POST变量或cookie（从另一个已关闭的源应用程序发送）来处理，并在解密后验证我们数据库中的详细信息。如果一切都检查出来，我们会考虑用户登录（并且还有来自加密数据的数字用户ID）。除少数拥有更多访问权限的用户外，所有用户都具有相同的访问权限。这些是在包含其数字ID的表中定义的。
但是，我们希望通过使用Active Directory凭据，封闭源系统的LDAP服务器提供的凭据以及通过CAS服务器在不太远的将来，直接登录这些Grails应用程序。
我最初的方法是寻找允许共享插件与这些不同系统连接的库，并对它们进行简单的身份验证。但是，我注意到Spring Security似乎有所有这些不同类型的身份验证的插件，这将加快开发速度。但是，模块本身看起来相当复杂，并且面向更高级的设置，这意味着我们可能花费大量时间来设置Spring Security以节省使用LDAP，CAS等插件的时间。
任何想法/评论等。非常感谢。
此外，如果我们要使用Spring Security插件，有人可以发表评论并告诉我是否可以进行以下设置......
我们希望避免为各种应用程序创建数据库表以进行身份验证。我们基本上想告诉Spring Security，如果用户通过了身份验证，则会对其进行身份验证。没有角色，没有组，没有什么花哨的东西（除了少数几个具有一个额外角色/组的应用程序，为用户提供额外的权限......对于这些应用程序，显然需要数据库表）。
我们还希望默认始终要求所有内容的安全性，并仅添加额外的代码以禁止此操作以允许非经过身份验证的访问。这背后的想法是，如果开发人员忘记将Spring Security标记代码添加到控制器或操作，它将默认为始终需要身份验证。
此外，我们仍然需要通过从另一个应用程序或加密的cookie发送加密的POST变量来保留原始身份验证方法。是否有可能将其构建到Spring Security中？
最后，Spring Security插件可以存储在身份验证后检索的数字用户ID，以识别用户而不是存储在身份验证期间使用的实际用户名吗？
答案 0 :(得分：1)
嗯，你的帖子中有很多问题。我会尽力回答我记得的那些。
首先，Spring Security很复杂。那是因为真正的安全很难。但是，Spring Security和Grails插件在某种程度上都是非常可配置和可定制的。一旦你完成了高学习曲线，这将对你有利。
由于您的需求不断增长并且变得越来越复杂，您现在可以通过投资Spring Security来节省很多麻烦，最终节省时间和精力。
我建议您阅读Spring Security documentation，Spring Security Grails documentation以及尽可能多的使用spring-security标记的SO帖子。投资一些涵盖Spring Security的书籍也不是一个坏主意。
这些是我的高级思想/评论。
就Spring安全性而言（你的其他问题）。
interceptUrlMap，则只需更改哪些URL没有安全性或安全性与默认值IS_AUTHENTICATED_FULLY不同。< / LI>
UserDetailsService和UserDetails，您可以在principal中使用数字ID或任何其他详细信息。总而言之，通过对Spring Security的正确努力和理解，您可以满足您的需求。然而，这不是一个简短而快速的过程，需要大量阅读。
答案 1 :(得分：0)
Well Springs Security是目前最好的安全插件之一。这是高度可定制和可配置的。
默认情况下，每个网址都会被弹簧安全锁定。但您可以通过在config.groovy
中添加配置来解锁所有网址grails.plugin.springsecurity.controllerAnnotations.staticRules = ['/**' : ['permitAll']]
以上将使您的所有网址都可以访问而无需登录。不，您可以在控制器级别上对所有网址的明细性进行限制。
对此，他们也是春天安全的良好支持。您可以在外部源完成身份验证，并使用sprinfsecurity配置它。此外，我们仍需要保留原始身份验证方法 通过加密的POST变量发送从另一个应用程序或 加密的cookie。是否有可能将其构建到Spring Security中？