我有一个Web应用程序A，用户必须通过用户名/传递方法（ https：//server.local/webappA ）进行身份validation。 与服务器Abuild立安全连接（HTTPS）。
然后，这些家伙想要使用相同的身份validation用户打开一个不同的URL（ https：//server.local：8080 / webappB /？param1 = PID ），并确保身份validation不被破坏。 换句话说，他们不希望用户再次为webappBinput他的凭证。 另外，这个新的webappB不应该被非authentication用户访问。
WebappB在Tomcat中运行，可以在不同的端口号上的同一台服务器上运行。 如果webappA有一个众所周知的authentication系统，比如LDAP，但是他们没有，那么我们的工作可能会容易得多。 WebappA来自A公司，WebappB来自B公司。
有没有可能这可以工作？ 我个人看不出来，所以我可能会和你们一起尝试。 我可以自由地安装任何我需要的apache mod或服务器。
这不是太棘手，假设两个应用程序都可以访问类似的会话数据。 但是，只有当你可以混淆代码一点。 既然你在谈论不同的公司提供的软件，第二部分可能是不可能的。
基本上，当使用AppA启动会话时，用户名/密码会针对某个源（数据库，IMAP服务器，LDAP服务器等）进行检查，但实际上这并不是该过程的重要部分。 在第一次用户名/密码收集之后，发出会话令牌 。 AppA在访问时检查会话令牌 ，如果有效的话; 加载会话（所以每次你做什么都不需要用户名/密码）。
为此，您需要AppB （a）能够访问该会话令牌 （很容易，它可能存储为cookie）; （b）访问会话数据，列出有效令牌和用户的相关（如果用户不是“ t包含在cookie中的令牌中）; （c）在AppB创build一个没有用户名/密码启动的会话，或者针对现有会话进行validation。
会话令牌访问：
这应该只是读取提供给AppB的Cookie。 只要AppA发行的Cookie没有限制性的path值（由于公司A无法知道AppA可以运行的所有文件夹， AppA风险较低）。
会话数据访问：
通常，应用程序会将会话信息存储在某种数据库表中。 唯一的技巧可能是学习与会话相关联的用户名（令牌可能包括用户名，或某种types的ID，或者两者都不）。 AppA应遵循AppB定义的会话有效性
创buildAppB会话：
可能是最AppB部分，如果AppB在authentication模块上具有dependency injection（包括会话启动，会话检测和会话终止），那么只是让应用程序读取与AppA相同的会话令牌，与会话进行比较/validation数据，如果需要翻译和扩展。 注意，除非这两个应用程序都被修改，否则您还需要AppB推迟login，并可能注销到AppA
安全：
如果AppA使用cookie来存储/检索没有path值的会话信息， AppA通知同一网站的任何其他部分也可以看到这个cookie。 如果某些网站是在http下提供的 – 包括图片，样式表和javascript – 这个会话cookie将被公开并可以通过嗅探软件（如firesheep）或硬件获得。 从不同服务器（或不同名称的同一台服务器）提供静态内容有助于缓解这种情况。