2010-04-08 1 views
9

나는 다른 질문을 읽었으며 보안에 관해 주로 이야기합니다. 웹 사이트가 브라우저 기반 게임이기 때문에 이것이 내 관심사가 아닙니다. 그러나 더 큰 문제는 사용자입니다. 모든 사용자가 OpenID를 충분히 이해할 수있는 것은 아닙니다. 물론 RPX를 사용하면 쉽게 사용할 수 있습니다.하지만 사용자가 Google이나 Facebook 등에서 계정을 갖고 있지 않거나 기존 계정으로 로그인 할 때 시스템을 신뢰하지 않으면 어떻게됩니까? 그들은 다른 제공에 계정을 가져야 할 것입니다 - 나는 가장 많은 사람들이 그것을 할 것을 성가 시게하지 않고하는 방법을 알 것입니다 확신합니다.OpenID를 유일한 인증 방법으로 사용하기

응용 프로그램에서 관리하는 방법의 문제도 있습니다. 사용자는 하나의 계정으로 여러 개의 ID를 사용하기를 원할 수 있으므로 처리 할 username + password만큼 간단하지는 않습니다. 데이터베이스에 사용자의 OpenID ID를 저장하려면 어떻게해야합니까? OpenID를 사용하면 나에게도 이익이됩니다. RPX는 광범위한 프로필 정보를 제공 할 수 있으므로 프로필 양식을 미리 채우고 필요한 경우 편집하도록 사용자에게 요청할 수 있습니다. 이러한 외래 키와

Users: 
------ 

ID  Email    Etc. 
--  --------------- ---- 
0  b[email protected]  ... 
1  [email protected] ... 

UserOpenIDs: 
------------ 

ID  UserID  OpenID 
--  ------  ------ 
0  0   0 
1  0   2 
2  1   1 

OpenIDs: 
-------- 

ID  Provider Identifier 
--  -------- ---------------- 
0  Yahoo  https:\\me.yahoo.com\bob#d36bd 
1  Yahoo  https:\\me.yahoo.com\alice#c19fd 
2  Yahoo  https:\\me.yahoo.com\bigbobby#x75af 

:

나는 현재이이

UserOpenIDs.UserID -> Users.ID 
UserOpenIDs.OpenID -> OpenIDs.ID 

가 오른쪽으로 데이터베이스에 오픈 ID 식별자를 저장하기 위해인가요? RPX가 데이터베이스에있는 식별자와 일치하면 어떻게 사용자에 로그인 할 수 있습니까 (식별자가 알려진 경우).

그래서 여기에 구체적인 질문은 다음과 같습니다

  • 가 어떻게 그것을 접근 오픈 ID를 가지고 있지 사용자 또는 하나를 사용하고자하지 만들 것
      ? (예 : 보안 문제로 인해 Google 계정으로 로그인)
    • 데이터베이스에 식별자를 저장하려면 어떻게해야합니까? (위의 표가 맞는지 확실하지 않습니다.)
    • 다른 사용자가 다른 사용자로 로그인하지 못하도록하고 계좌로 아무 것도하지 못하게하기 위해 취해야 할 조치는 무엇입니까? (RPX가 HTTP를 통해 식별자를 전송한다는 것을 이해하면 누구나해야 할 일은 "OpenID"필드에 입력하는 것입니다.
    • OpenID를 사용할 때 알아야 할 사항이 있습니까?
  • +0

    안녕하세요, OpenId 자신에게 새로운 것이지만 내 사이트에서 고려하십시오. 세 번째 질문 "조치 ... 누군가가 다른 사용자로 로그인하는 것을 방지하기 위해 ...", OpenId를 이해함에 따라 ** 신뢰할 수없는 출처에서 OpenId Url을 수락하지 마십시오. 구현시 귀하의 사이트가 제공 업체의 로그인을 호스팅하며 제공 업체의 사이트 **는 ** 직접 연락하므로 신뢰할 수있는 사이트에서 항상 OpenId URL을 수락합니다. –

    답변

    4

    이 오픈 ID가없는 접근

    먼저 관련된 사용자가 계정을 생성 (또는 심지어 일부 업체를 가리)하는 방법을 설명합니다 약간의 페이지를 만들 수 있습니다 만들기. 이렇게하면 일반 계정보다 OpenID 계정을 만드는 것이 더 어렵지 않습니다.

    OpenID를 사용하지 않으려는 사람들에게는 두 가지 선택 사항이 있습니다. 첫 번째 : OpenID 로그인 옆에 이전 스타일의 로그인을 구현하고 사용자가 원하는 방법을 선택할 수있게하십시오. 두 번째는 OpenID 만 사용하는 것입니다. 이렇게하면 작업이 단순 해집니다. 오픈 ID 공급자는 등 자주 암호화 된 연결을 사용할 때 일부 사용자가 로그인하는 것이 더에게 신뢰할 수있는 오픈 ID 공급자보다 웹 사이트를 신뢰 말하는,

    데이터베이스에 저장 ... 내 의견으로는 매우 이상하다

    johnny g이 제안한 스키마가 필요합니다.

    당신은 http://openid.test.com/abchttp://openid.test.com/abc/ 같은 일을 방지 할 수 있도록 사용하기 전에 URL을 정상화 할 수는 다른 URL로 처리되는 (역 슬래시 대신 슬래시와 함께 URL을 저장하는 이유를 모르겠어).

    추가 조치

    없음을 없습니다. http://openid.net/developers/libraries의 라이브러리 만 사용해야합니다.

    사용자의 신원을 확인하는 과정은 문제는 공급 업체의 문제입니다. 사용자와 웹 사이트에서만 계정의 암호를 알고 있습니다.

    누구나 OpenID URL (공개)이있는 경우 로그인 할 수 있으려면 그는 암호 (또는 SSL 인증서와 같은 다른 종류의 인증 방법)가 필요합니다.

    +0

    백 슬래시는 RPX에서 API를 통해 제공했기 때문에 사용했습니다. 너무 오래 문제가되지 않아 일관성이 있습니다. 라이브러리에 관해서는 일관된 API와 훌륭한 사용자 인터페이스를 갖춘 RPX를 사용하겠습니다. – CMircea

    +0

    고마워, 나는 왜 그런지 궁금해했다. 문제는 일관성이 있어야한다는 것이다. – Kru

    -1

    나는 첫 번째 질문에 한 대답을 발견 :

    사용자 또는 기존의 공급자와 함께 오픈 ID, 파트너를 사용하여 웹 사이트에 직접 등록하거나이되고 싶어하지 않는 수없는 경우 공급자 자신도 (이것은 고전적인 사용자 이름 + 암호 계정을 가지고 있음에도 불구하고 OpenID만을 사용하는 질문의 요점을 놓치고 있음을 의미합니다).

    3

    Arg, 위의 내 이전 의견에 답하십시오.

    OpenId를 이해하는대로 "다른 사용자로 다른 사람이 로그인하지 못하도록 조치합니다 ..." 신뢰할 수없는 출처의 OpenId Url을 수락하지 마십시오. 구현시 귀하의 사이트는 제공자의 로그인을 호스팅하고 제공자의 사이트는 이며 직접 신뢰할 수있는 사이트의 OpenId URL을 수락합니다.

    즉, 악의적 인 사용자가 Pokemon과 같은 OpenIds를 수집하더라도 시스템에 액세스 할 수있는 방법이 없습니다.

    "어떻게 저장해야합니까?"라는 두 번째 질문에서 스키마는 작동하지만 다소 여유가 있습니다. 예를 들어, many-to-many 매핑 [즉, UserID to OpenID]을 사용하면 사용자가 많은 OpenIds에 속하도록 허용하고 단일 OpenId는 많은 사용자에 속하게 할 수 있습니다. 당신은 후자없이 전자를 원한다.

    간단한 외래 키 제약 조건으로 충분합니다. 이것은 본질적으로 User 0 또는 많은 독특한 Identifier의 소유 상태, UserID을 제공

    UserID  Email   
    ------  --------------- 
    86000  [email protected] 
    86001  [email protected] 
    
    UserID  Identifier 
    ------  ---------------- 
    86000  https:\\me.yahoo.com\bob#d36bd 
    86000  https:\\me.yahoo.com\bigbobby#x75af 
    86001  https:\\me.yahoo.com\alice#c19fd 
    

    Users 테이블에 외래 키와 Identifier에 고유 키 제약 조건이있다. 원칙적으로, 나는 아마 그 테이블에 기본 키를 쳐야 하겠지만, 그것은 그 육즙이다.

    희망이 도움이 :)

    PS 당신이 통합 또는 오픈 ID를 활용에 대한 의심이있는 경우, 다음 구현을 통해 단계를. OpenId Url을 사용하는 모든 소스를 확인한 다음 악의적 인 사용자가 해당 진입 점에 액세스 할 수 있는지 스스로에게 질문하십시오. 이러한 진입 점이 하나만 있으면 좋겠지 만 신뢰할 수있는 OpenId 공급자를 제외한 모든 사용자가 액세스 할 수 없기를 바랍니다.

    +0

    두 번째 테이블에서 UserID를 잊어 버렸습니다. 결정된. – CMircea