新云APP账号未通过sso服务器验证是什么意思
发布网友
发布时间：2022-04-24 11:07
共1个回答
热心网友
时间：2023-10-10 19:20
摘要SSO指的是单点登录(Single Sign On)，当用户在身份认证服务器上登录了一次以后，即可获得访问单点登录系统中其他联邦系统和应用软件的权限。同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用系统中，用户只需一次登录就可以访问所有相互信任的应用系统。单点登录是多个相关但的软件系统的访问控制的属性。使用此属性，用户使用单个ID和密码登录，以便在不使用不同用户名或密码的情况下访问已连接的系统，或者在某些配置中在每个系统上无缝登录。单点登录通常使用轻量级目录访问协议（LDAP）和（目录）服务器上存储的LDAP数据库来完成，可以使用cookie在IP网络上实现简单版本的单点登录。图为一种SSO系统：扩展资料实现机制当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。SSO的优势1、降低访问第三方站点的风险（未在外部存储或管理的用户密码）。2、从不同的用户名和密码组合减少密码疲劳。3、减少重新输入相同身份的密码所花费的时间。4、由于关于密码的IT服务台呼叫数量减少，降低了IT成本。5、SSO共享所有其他应用程序和系统用于身份验证的集中身份验证服务器，并将其与技术相结合，以确保用户不必多次主动输入其凭据。咨询记录 · 回答于2021-12-04新云APP账号未通过sso服务器验证是什么意思SSO指的是单点登录(Single Sign On)，当用户在身份认证服务器上登录了一次以后，即可获得访问单点登录系统中其他联邦系统和应用软件的权限。同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用系统中，用户只需一次登录就可以访问所有相互信任的应用系统。单点登录是多个相关但的软件系统的访问控制的属性。使用此属性，用户使用单个ID和密码登录，以便在不使用不同用户名或密码的情况下访问已连接的系统，或者在某些配置中在每个系统上无缝登录。单点登录通常使用轻量级目录访问协议（LDAP）和（目录）服务器上存储的LDAP数据库来完成，可以使用cookie在IP网络上实现简单版本的单点登录。图为一种SSO系统：扩展资料实现机制当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。SSO的优势1、降低访问第三方站点的风险（未在外部存储或管理的用户密码）。2、从不同的用户名和密码组合减少密码疲劳。3、减少重新输入相同身份的密码所花费的时间。4、由于关于密码的IT服务台呼叫数量减少，降低了IT成本。5、SSO共享所有其他应用程序和系统用于身份验证的集中身份验证服务器，并将其与技术相结合，以确保用户不必多次主动输入其凭据。怎么解决呢？1、首先打开I电脑桌面，单击此电脑右键选择属性按钮。2、进入系统属性设置界面，选择远程按钮。3、然后需要单击选择用户选项。4、然后需要选择添加选项按钮。5、单击高级选项，选择立即查找选项。6、找到你授权远程的用户。7、选择你需要的用户单击确定即可。一旦用户注册之后，用户信息就保存在服务器端（DB/Cache）。关键在于用户需要提供身份凭证，一般是用户名和密码。即常见的登陆页面：用户输入username和password，勾选Remember Me（可选，一般是记住一周），点击登陆，提交请求到服务端（这里一般是走HTTPS）。服务端根据用户名和密码到数据库查询是否匹配，如果匹配的话，说明身份认证成功。这是一次普通的身份认证过程。非常好理解。关键在于HTTP是无状态的，用户登陆过一次，但是如果你没有做一些状态管理操作的话，用户登陆后请求同一个页面，服务器仍然要求其登陆。这时候就需要做一些状态处理了。一般是通过服务器颁发一个登陆凭证(sessionkey/token/ticket)实现的。那么这个登陆凭证是怎么生成的？又是怎样安全的颁发给客户端呢？方案一：session集群 + 随机sessionId用户登陆成功之后，服务器为其随机生成的一个sesionId，保存在session服务器中，将这个sessionId与用户关联起来：sessionId=>userId。然后通过cookies方式将sessionId颁发给客户端，浏览器下次请求会自动带上这个sessionId。服务器根据sessionId从session服务器中拿到关联的userId，比较是否与请求的userId相同，如果是则认为是合法请求。sessionId是随机生成的，基本来说是不可能被猜测出来的，所以这方面的安全还是有一定保障的。方案二：session-less + 加密算法上面的Authentication方式其实是用到了session和cookies。我们知道session这东西是服务端状态，而服务端一旦有状态，就不是很好线性扩展。其实对于身份验证来说，服务端保留的也这是一个简单的value而已，一般是userId，即session['sessionId']==>userId。然后再根据userId去DB获取用户的详细信息。如果我们把userId作为一个cookies值放在客户端，然后把用几个cookies值（比如userId）做一个特殊的签名算法得到的token也放在cookie中，即f(userId, expireTime)==>token。这样服务端得到用户请求，用同样的签名算法进行计算，如果得到的token是相等，那么证明这个用户是合法的用户。注意这个签名算法的输入因子必须包含过期时间这样的动态因子，否者得到的token永远是固定的。这种实现方式其实是仿造CSRF防御机制anti-csrf.md。是笔者自己想出来的，不清楚有没有人用过，个人感觉行得通。然而上面的做法安全性取决于签名算法的隐蔽性，我们可以更进一步的，可以参考API中的签名验证方式，把password作为secretKey，把userId, expireTime, nonce, timestamp作为输入参数，同样用不公开的算法（这个与API签名不同）结合password这个secretKey进行计算，得到一个签名，即f(userId, expireTime, nonce, timestamp, password)==>sign。每次客户端传递userId, expireTime, nonce, timestamp和sign值，我们根据userId获取到password，然后进行f(userId, expireTime, nonce, timestamp, password)==>sign计算，然后比较两个sign是否一致，如果是，表示通过。这种方式比起上面的方式其实区别在于增加了password作为输入参数。这样首先增加签名的破解难度。还带来一个额外的好处，就是当用户修改了password之后，这个token就失效了，更合理安全一些。好的，我试试，谢谢 1. 客户端 >>>用户输入userId和password，form表单提交到后台进行登录验证（这里最好走HTTPS）。2. <<< 服务端服务端根据userId，从用户信息表中得到用户注册时保存的密码签名：S=md5(password)。服务器验证用户信息：userId == DB.userId; md5(password) == DB.S。如果验证通过，说明用户身份认证通过。这时候服务器会为客户端分配一个票据(签名)：token=md5(userId;tokenExpiryTime;S;secretKey)。其中secretKey是一个后台统一的密钥，而且跟DB是分开的，一般是写在配置文件中。目的很明显，就是避免将鸡蛋放在同一个篮子中。然后服务端将这个token值存放在cookies中。同样放入cookies中的还有userId和tokenExpiryTime。这些cookies的过期时间都是tokenExpiryTime。3. 客户端 >>>客户端每次请求都要带上这个三个cookies(浏览器自动会带上)。4. <<< 服务端服务器首先检查tokenExpiryTime是否过期了，如果过期就要求用户重新登录。否则，根据userId cookie从用户信息表中获取用户信息。然后计算expectedToken=md5(userId;tokenExpiryTime;S;secretKey)。然后比较expectedToken是否跟用户提交的token相同，如果相同，表示验证通过；否则表示验证失败。说明为了增加安全性，可以进一步将userId, tokenExpiryTime; token 这个三个cookies进行一次对称加密: ticket=E(userId:tokenExpiryTime:token)。虽然cookies的值是没有加密的，但是由于有签名的校验。如果黑客修改了cookie的内容，但是由于他没有签名密钥secretKey，会导致签名不一致。google了一下，发现这篇文章跟我的观点不谋而合Sessionless_Authentication_with_Encrypted_Tokens。另外看了一下Spring Security的Remember Me实现，原来这种方式是5
