如题
单点登录的精髓在哪里

解决方案 »

  1.   

    嗯。单点登录,比如你进入一幢大楼,只要在大门保安让你进,里面随便逛。如果不是,则每进一层,还有个保安要检查一次(每次的password可能不同)
    统一身份认证,就是你进一座大楼,任意检查点的password都一样哎,不知道这个比方对不对权当笑话吧
      

  2.   

    我觉得SSO和本地保存用户信息(Cookie?)是2个层次上的东西,
    SSO是实现多个WEB应用统一权限验证的理念,它可以有多种不同的实现方式, 像CAS,Kerberos等等,而Cookie只是实现用户验证的基本手段,Cookie不能跨域,而SSO则正是把不同域内的应用统一注册,统一管理。从实现上来看,SSO也是需要用到Cookie的, 就像CAS为了保存用户的信息票据(ticket)专门设计了TGC,然后就是因为这样的机制导致了SSO有一种门槛效应,就是一旦黑客获得了cookie,他就可以伪造出假的票据,然后自由穿梭于你的那些web应用, 你的验证服务器就挂了,所以说SSO即需要cookie又因为cookie变得脆弱。
      

  3.   

    sso认证中心已经成功认证了,应用系统还是需要认证啊
    这地方需要对应用系统做什么改造吗
      

  4.   

    应用系统验证的一般不是用户名密码,而是权限。用户有没有权限,有什么样的权限,不是用户名密码输入正确了系统就可以访问了,SSO很好的把Authentication和Authorization分开了
      

  5.   

    单点登陆的概念: 当一个大系统中存在多个子系统,时,用户只需要正确登陆其中任何一个子系统,就可以在各个子系统中来回自由切换和使用. 
    这个登陆系统是一个共有的。单点登陆也就是用一个统一的用户管理系统(包括部分权限控制模块) 
    登出的逻辑:用户确定登出系统,或者用户登入的所有的子系统的session都超时。 单点登陆的模式 
    一种是DNN模式。也就是把各个子系统的界面都集成到一起,当到一个类似DNN一样UI的容器管理器里面,用这样的方式,来实现一次登陆,然后在各个其他系统中继续享有这个用户登录服务。 其实这是采用一个WebApplication的方式。 
    第二种,类似微软的passport,一次登陆之后,就可以在msn,hotmail,或者space中任其切换而不需要重新登陆。这一中模式就不是一个WebApplication了,而是在多个Application上的控制 单点登录(SSO)的实现原理 
        (1) 登陆点。理想的情况是用户通过任何应用系统都能进行登陆,而且效果一样。这种单一的登陆点在整个系统的设计中是唯一认证用户的地方,由登陆点将相应的用户信息传递给应用系统,应用系统利用这些信息来进行用户的验证。     (2) 应用系统的单点登录(SSO)集成。并不是任何系统都能够使用SSO,只有那些符合SSO规范,使用SSO API的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统,屏蔽已有的应用系统的用户认证模块,使用系统提供的SSO API来验证用户,以及对用户的操作进行授权。     (3) 统一的认证,权限信息库。通常SSO要求有统一的认证,权限存放库。但现实中,有的系统无法使用外部的认证,授权信息库,所以就需要在应用系统和SSO认证系统之间进行认证,同时进行授权信息的数据同步。 
    实现描述:在用户成功通过SSO认证系统认证之后,系统提供的映射授予权限来为用户登录到其有权可以使用的应用系统。系统提供的映射取消用户权限来实现用户的注销功能。 
      

  6.   

    你说的那是用户权限结构简单的系统,假设系统里一共有128个角色,65536个权限,1024个用户,你能规定这1024个用户都具有相同权限吗?实际中是这样的:在A系统中,用户x是管理员,用户y是消防员,在B系统中,用户x是老师,用户y是猪,在不同系统中角色不同,拥有的权限也不会一样,如果要在SSO Server端进行统一的权限认证也是可以的,那就需要有个很大的数据库把不同应用的用户,角色,权限统一在一起,还要区分出每个用户在不同系统中的不同角色,概括起来就是 A, B, x, y管理员,消防员,老师,猪混在一起放在一个数据库里,你觉得这样好管理吗?所以现在普遍的实现方式都是统一验证,分开管理。
    你说的单点登录和非单点登录的区别再给你举个例子,比如你有3个邮箱gmail hotmail yahoo,然后为了方便你用thunderbird管理邮件,这样就只用登录一次thunderbird就可以浏览3个邮箱里的邮件了,然后突然有一天微软和yahoo倒闭了,你只有gmail可以用了,那你还希望天天登录thunderbird看着2个已经没用的邮箱吗?这时候也许你就会删掉thunderbird改用web mail了直接登录gmail了吧。
      

  7.   

    楼上这位兄弟说的很形象也很有道理我的疑问点是web1、web2两个系统
    经过认证中心认证成功之后,web1就可以成功登录了,同时web2也可以成功登录了
    这个成功登录是怎样完成的,需要对web1和web2的认证方式改造吗
      

  8.   

    我看有人这样实现
    例如,老系统的登录页面和主页面分别是login.jsp,main.jsp(login.jsp负责验证用户是否合法,合法则将用户
           数据存入该系统的session对象当中,main.jsp负责分配用户在该系统内的访问权限及页面的初始化),为了不影
           响老系统的正常访问,尽可能保证独立性可以实现两个仅供portal.jsp调用的类似页面(cas-login.jsp,cas-main.jsp).
           cas-login.jsp中可以获得cas server传递给我们的用户名称。String username = (String)session.getAttribute(CASFilter.CAS_FILTER_USER);         根据获得的用户名称再去本地数据库查找用户信息,完成验证及角色权限初始化的工作。
      

  9.   

    上面你说的就是用CAS实现SSO,对于web1,web2你要做的就是把他们的用户名密码验证部分废掉,仅保留权限赋予验证,然后再部署一个SSO的实现(CAS, Kerberos, jOSSO)作为认证中心,然后让web1, web2分别实现SSO认证端口,你可以搜一下叫SSO in Action的文章,写的比较详细
      

  10.   

    web1、web2实现认证端口
    意思是不是通过sso保护web1、web2的被访问的资源,访问web1和web2的时候要通过sso的认证中心
      

  11.   

    另外我想还想使用以前的用户名密码认证方式,把密码保存在cookies中,可行不
      

  12.   

    最简单的方式就是用cookies啦,如果复杂点的可以看看
     josso
      

  13.   

    现在在用cas,但是有一点想不明白就是认证中心通过后,应用系统再怎样做自己的认证,应用系统所需的信息从哪获得?有没有类似自动填表的策略?