Web应用程序Kerberos身份验证:与cookie结合的正确方法是吗? [英] Web application Kerberos authentication: Is the proper way to combine with cookies?

问题描述

场景:

• 企业级防火墙Python Web应用程序.
• 应该使用Kerberos对用户进行身份验证.
• 我有工作代码，可以从服务器(Negotiate标头等)发送正确的响应，并使用kerberos-sspi包获取访问应用程序的用户的Windows用户名

• An enterprise, behind-the-firewall Python web application.
• Kerberos should be used to authenticate the users.
• I have working code that sends the correct responses from the server (the Negotiate header etc.) and get the Windows user name of the user accessing the application, using the kerberos-sspi package

我对Kerberos的了解很少，但是对Web应用程序的了解.

I have little experience with Kerberos, but some experience with web applications.

在我创建的使用内置用户数据库的其他Python Web应用程序中，身份验证流程通常如下:

In other Python web apps I have created that use a built-in user database, the authentication flow is typically as follows:

• 对于每个请求，请检查该请求是否具有包含用户ID的(签名)cookie(或某些变体，例如，使用flask-login，其中用户ID存储在flask.session中)
• 如果cookie存在，则正常响应.
• 如果不存在这样的cookie，请重定向到显示用户名/密码形式的/login/. POST到/login/验证正确的用户名/密码，设置安全cookie并重定向到?next=查询参数中指定的URL.

• For each request, check if the request has a (signed) cookie containing the user id (or some variation - for instance using flask-login where the user id is stored in flask.session)
• If the cookie exists, respond normally.
• If the no such cookie exists, redirect to /login/ displaying a username/password form. POST to /login/ verifies correct username/password, sets the secure cookie and redirects to the URL specified in the ?next= query param.

我的问题是:

• 在经过Kerberos身份验证的Web应用程序中，身份验证流程是否相似?

• 即我应该执行以下操作:

• In the Kerberos-authenticated web app, is the authentication flow similar?

• I.e. should I do the following:

• 对于每个请求，请检查该请求是否具有包含用户ID的(签名)cookie
• 如果cookie存在，则正常响应.
• 如果不存在这样的cookie，请重定向到/login/. /login/做必要的工作来弄清楚用户是谁(即发送Negotiate标头，使用kerberos_sspi查找用户名等)，然后设置安全cookie并重定向到?next=查询参数.

• For each request, check if the request has a (signed) cookie containing the user id
• If the cookie exists, respond normally.
• If the no such cookie exists, redirect to /login/. /login/ does the necessary stuff to figure out who the user is (i.e. sending the Negotiate header, use kerberos_sspi to find the user name etc.), then set the secure cookie and redirect to the URL specified in the ?next= query param.

还是应该以其他方式处理?

Or should it be handled some other way?

推荐答案

是的，建议的流程似乎可行.

Yes, your suggested flow seems viable.

如果Kerberos表示是"，您可以首先登陆/login/进行Kerberos协商，然后将用户重定向回会话.这甚至可以是在后台的XMLHttpRequest，如果会话不再有效，则重定向到/login/.如果在后台检查会话，则cookie的生存期可能比Kerberos令牌短得多，并且在任何给定时间，您担心的有效会话都更少.

You could perform the Kerberos Negotiation as first thing landing on /login/ and redirect the user back to the session, if Kerberos said yes. This could even be an XMLHttpRequest on the background and redirect to /login/ if a session ceases to be valid. If the session is checked in the background, the cookies can have a significantly shorter lifetime than Kerberos tokens and you have less of valid sessions to worry about at any given time.

如果会话不存在，请为用户提供Kerberos和其他可能的登录方法.

If a session does not exist, offer Kerberos and potential other login methods for the user.

如果用户通过Kerberos拥有有效的会话，但没有用户配置文件，请将该用户配置到应用程序中.在这里，您可以当场轮询用户以获取更多信息，根据组和角色进行决定，或者将用户创建为具有一组默认权限，已知丢失值的存根，从而推迟该过程.

If a user has a valid session through Kerberos, but no user profile, provision the user into the application. Here, you can poll the user for more information on the spot, decide based on groups and roles, or create the user as a stub with a set of default permissions, known missing values and thus defer the process.

这都是非常笼统的.您可能应该查看要针对三A或 AAA映射目标的方法(如身份验证，授权和计费).显然，Kerberos正在执行身份验证，其余角色需要确定.

This was all very general. You should probably review what you are trying to map your goals against triple-A or AAA as in Authentication, Authorization and Accounting. It seems clear that Kerberos is doing authentication and the remaining roles need to be decided.

关于cookie:在您的应用程序上将任何Authentication转换为cookie确实确实有意义.这样一来，您以后就可以在不更改整个应用程序的情况下，在侧面添加其他一些SSO方法.

About cookies: It indeed does make sense to transform any Authentication into a cookie on your application. That way you could later add some other methods of SSO on the side without changing the whole application.

这篇关于Web应用程序Kerberos身份验证:与cookie结合的正确方法是吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！