Login SaaS登录URL

参考本论坛中有关SSL安全SaaS应用程序URL设计的问题，并假设使用选项C，即每个帐户在公共域名下都有唯一的子目录；问题是：对于处理高度敏感数据的SaaS应用程序（银行或医疗记录应用程序），这是为特定公司设计客户登录页面入口点的更好方法：

使用唯一的逻辑和可设置关键字的URL，例如，对于名为ABC的公司：

使用依赖于公司密钥的更神秘的url作为url参数，例如：“232323355AAc”

设计系统以允许使用上述两种方法进行访问，并允许客户根据自己的公司安全策略选择与风险级别一致的方法

---

使用方法一与方法二的权衡是简单性优于安全性。此外，考虑到猜测的URL可能会减少黑客获取访问权限所需跳转的范围，并且可能更容易受到社会工程实践的影响，使用这种方法是否可以接受？

您可以提供一个全局登录页面，在验证后将用户重定向到可读的URL路径变量（人类可以阅读的内容看起来至少更可信）-但对于没有有效会话的请求，始终阻止对URL路径变量的访问

因此，您不必在一些安全性方面投入精力，您可以考虑在需要保护的URL前面额外放置一个web应用程序防火墙

---

（顺便说一句，companykey方法必须以某种方式通过邮件分发？它将被添加到书签中，不容易记住。）

全局登录页面的问题在于，该应用程序的方向是允许用户ID在公司中是唯一的，而不是在系统中是全局的，因此在允许显示登录页面之前，需要识别公司。对于compkey，有两种方法可以分发URL：通过电子邮件发送，或assume公司将在Intranet门户上提供链接（如果存在的话）。compkey不容易记住这一事实可以被视为是一种安全级别，这确实是这个问题的关键。我认识的一家公司也会这样做，只要求用户在UID前面加上一个带分隔符的公司标识符，如“

公司/12345

"。之后，重定向就没有问题了。请注意，如果某个内容不容易记住，它会放在键盘下，写在桌子旁边的一张纸上，等等。通过使用web app防火墙或代理，您可以将信息隐藏结果或任何类型的http stati返回给请求未经授权的客户端。您的建议在userid前面加上company是一个很好的前缀，但是，作为设计的一部分，登录页面提供了特定于公司的信息，因此必须排除全局登录页面。您写复杂URL的目的也是一个值得注意的考虑因素。然而，我不清楚如何将web应用防火墙或代理应用于此设计，你能给我指一个关于这个的案例研究或白皮书吗？谢谢。好的，有很多。这里有一个我处理过的：对于几乎每一个请求，你都可以定义规则或操作，用加密可靠的会话管理来屏蔽你自己的会话管理，等等。Haproxy允许你定义基于regexp的头控制。