单点登录基于Web的身份验证系统

时间:2012-10-10 07:14:01

标签: php security authentication single-sign-on

我希望得到有关我设计的身份验证系统的反馈。

要求是在Web环境中创建一个封闭的单一登录,一旦我们的一名员工访问我们的某个Web应用程序,就会要求他们使用我们的LDAP支持的凭据登录。登录后,他们会在指定时间段或浏览器会话以及所有Web应用程序中保留此登录信息。很多Google的网站资源如何与Google帐户配合使用,但适用于我们的内部系统。

用户自己使用windows,mac或linux,有些只是平板电脑,所以这个认证环境只需要在线存在,kerberos和mod_auth_kerb等不会削减它。

我们当前的所有Web应用程序都使用PHP。

到目前为止我的系统工作如下。

存在一个中央身份验证系统,我将其称为身份验证处理程序,或简称为“处理程序”,以及一个或多个身份验证“客户端”Web应用程序,我将其称为身份验证请求程序,或简称为“请求程序”。我会将用户和他们的浏览器称为“用户”。

此外,要使其工作,请求者需要在处理程序中预先配置一个唯一的requestor_id并返回该ID的URL。 生成处理程序的私钥,并且手动提供给所有请求者的公钥。

用户访问请求者

  1. 用户输入请求者的URL。
  2. 此用户在请求者上没有会话,因此请求者在PHP中创建了一个新的SESSION_ID(使用内置的会话处理程序和session_start)。
  3. 会话没有身份验证,因此请求者将生成一个配置处理程序的URL,该处理程序由两部分组成,authrequest令牌和envelope
    1. 请求者首先为客户端的此auth请求重新生成一个新的session_id(PHP中为session_regenerate_id)。
    2. 请求者然后生成随机密码,在这种情况下使用PHP的openssl_random_pseudo_bytes并将其存储在会话数据中
    3. 请求者然后使用SESSION_ID使用AES256使用authrequest中的openssl_encrypt的随机密码加密requestor_id
    4. 请求者然后通过连接它的唯一openssl_public_encrypt,':'和base64编码的随机密码来生成包络数据。
    5. 请求者的信封数据然后使用PHP中的location:处理程序的预共享公钥进行加密。
  4. 请求者然后向用户发送envelope标头,其中包含加密的authrequestrequestor_id作为处理程序的URL参数。
  5. 处理程序将使用它的私钥解密信封,并将clientID和密码分开。
  6. 处理程序将检查authtoken以查看是否已配置此配置,如果没有,将通知用户请求者未被识别。
  7. 处理程序将对用户进行身份验证(在这种情况下,通过询问用户名和密码并检查LDAP和/或通过预先认证的会话)
  8. 然后,
  9. 处理程序将为请求者生成一个返回SESSION_ID
    1. 处理程序将使用信封中解密和解码的密码从authrequest解密SESSION_ID
    2. 处理程序将使用信封中解密和解码的密码加密包含location:的新字符串和登录凭据的ID(用户名,GUID等)
  10. 处理程序然后向用户发送authtoken标头,该标头包含requestor_id作为此SESSION_ID的预配置网址的网址参数。
  11. 请求者收到请求,并将使用用户会话中的密码解密令牌。
  12. 请求者将确认{{1}}与用户当前会话匹配,否则将重新启动身份验证。
  13. 然后,
  14. 请求者可以使用返回的crednetialID将本地用户标识为已通过身份验证。
  15. 可以在不同系统中重复此过程,以提供单点登录行为。

    所以,问题:

    1. 是否有人知道预先存在的标准化认证系统是否符合上述要求和预制件?
    2. 如果没有,并且鉴于我不是安全专家,那么上面有什么可以打破吗?即这个方法的弱点是什么?

2 个答案:

答案 0 :(得分:0)

您可以使用Kerberos:http://web.mit.edu/kerberos/www/
或者您实施内部OpenID系统:http://openid.net/
OpenID还有几个PHP库:http://openid.net/developers/libraries/

答案 1 :(得分:0)

加密之前密码的base64编码实际上没有任何意义(至少对我而言),因为它主要用于序列化要在其他地方传递的数据。但是,在信封加密后,您再次拥有二进制数据,因此您可能要做的是序列化密文。

此外,您可能想要检查是否可以在客户端进行凭证哈希处理(1000次迭代和盐渍MD5或SHA- *正常)。您可以查看RFC2617(HTTP摘要访问身份验证)以获取灵感。这是为了在服务器解密时解决密码的漏洞。