dongyuzhu2244
2012-05-13 18:41
浏览 66
已采纳

对Web应用程序使用单点登录(sso)时的数据库检查(用于凭据),提示?

I would like to implement single sign-on (sso) in a management application we have but I would like to have a hint or two about it. In our current application, a client logs in our application with a typical user+pass combination (with CAPTCHA being an optional feature).

As far as I understand (if I did it correctly), what you do with sso is 'trust' an identity provider (namely... Google, Facebook, Yahoo!, Windows Live, etc.), so the client is performing the actual login in an external page and then it returns a value to me, so I know the client has been validated by the identity provider.

In my eyes, I would like to do something like this (zwibbler FTW!):

the intended authentication mechanism

But in our current application, we check the username and his/her password against our database and that's where my understanding of SSO fails miserably... how can I match the information returned by the identity provider against my user data?

Or better expressed... what fields (as in 'typical' ala user, pass, email, etc.) could I use in my user account data to match the external authentication? My concern is about this being a commercial application, so I want to provide with users with the ability to use their own login data, but I have to match it somehow with our data to let (or not) him/her log in, so... how can I do it?

图片转代码服务由CSDN问答提供 功能建议

我想在我们拥有的管理应用程序中实现单点登录(sso),但我想拥有 关于它的一两个暗示。 在我们当前的应用程序中,客户端使用典型的用户+密码组合登录我们的应用程序(CAPTCHA是可选功能)。

据我所知(如果我做得正确的话) ,你用sso做的是'信任'一个身份提供者(即谷歌,Facebook,雅虎,Windows Live等),所以客户端正在外部页面中执行实际登录,然后它返回一个值 对我来说,所以我知道客户已经被身份提供者验证了。

在我看来,我想做这样的事情(zwibbler FTW!): \ n

但在我们的 当前的应用程序,我们检查用户名和他/她的密码对我们的数据库,这是我对SSO的理解失败的地方...我怎样才能将身份提供者返回的信息与我的用户数据相匹配? \ n

或更好地表达......哪些字段(如'典型'ala用户,通行证,电子邮件等) 我可以在我的用户帐户数据中使用以匹配外部身份验证吗? 我担心这是一个商业应用程序,所以我想向用户提供使用他们自己的登录数据的能力,但是我必须以某种方式将它与我们的数据匹配以允许(或不)他/她登录,所以 ......我该怎么做?

  • 写回答
  • 好问题 提建议
  • 关注问题
  • 收藏
  • 邀请回答

3条回答 默认 最新

  • dongtun2572 2012-05-13 18:47
    已采纳

    As a general design you would have the following tables

    • Users
    • Roles
    • auth_OpenID
    • auth_Google
    • auth_Facebook
    • auth_Windows_Live

    (Roll any auth tables that share the same structure into a single table).

    The users table would identify all the accounts on your system. The roles table would identify all the sets of permissions you need to deal with. Then the auth_* tables would contain the information you need for the remote sign on (such as Google account id and auth token).

    You then have a many-to-many relationship between the users table and each of the other tables.

    If someone signs in with an unknown third party authentication system you prompt them to either link it to an existing account (in which case they have to sign in again with a recognised set of credentials) or create a new account.

    已采纳该答案
    评论
    解决 无用
    打赏 举报
  • dqk42179 2012-05-13 19:33

    If you use email address as username you can match that way. You'll probably still need to build a system whereby an authenticated user can associate his user account with other auth providers (while still logged in), though. If you do it this way the relationship will be implicit.

    评论
    解决 无用
    打赏 举报
  • doufan3958 2012-05-14 12:50

    You have a few options:

    • Roll your own solution (no fun).
    • Use a solution like HybridAuth. You need a couple extra fields or an extra table to map each provider + ID to a local user ID.
    • Change tactics slightly and let an entirely separate system manage your sign in and permissions assignments (i.e. tags) such as: Single Sign-On Server/Client

    I'm quite partial to the last approach. Especially if you have multiple, disparate login systems that need to talk to each other or if you even foresee that need.

    评论
    解决 无用
    打赏 举报

相关推荐 更多相似问题