Gerekli OpenID bilgilerinin saklanması

Question

Sitem için OpenID kimlik doğrulaması kullanmaya çalışıyorum. İşte senaryo:
Ben kullanıcı (. Sadece Openid sağlayıcı ziyaret ederek doğrulatabilirsiniz e-posta şifre ile özel bir hesap oluşturmak için gerek kullanıcıyı),

• giriş sadece OpenID kullanarak edebilmek istiyorum
• E-posta/şifre ile (kullanıcı bir formu doldurarak sitede kayıtlı)
• Açık hesapları kimlik bilgilerine ekleyin (bir hesap için openids + email).

Şimdi açık kimlik için hangi kimlik bilgilerinin saklanacağını bilmiyorum. ve DB şeması hakkında emin değilim. İşte veritabanı şeması var:

Table: Users 
UserId => PK 
... => Custom info. Not related to authentication. 

Table: Authentication 
AuthenticationId => PK 
LoginId => (when custom site membership => email address) (when openId => openid unique address) 

UserId => FK to Users. 
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address) 
Password => filled when using custom membership. empty when using open id. 

Şimdi bir kullanıcı olup olmadığını Openid/özel üyeliğini kullanarak, açtığında, sadece kimlik doğrulama masaya bakıp kimlik bilgilerini bakmak ve uygun kullanıcıyı olsun. Hiçbir kullanıcı yoksa, yeni bir kullanıcı oluşturur ve kimlik doğrulama tablosuna bir giriş ekledim.

• ana soru: Provider ve LoginId Openid kimlik depolamak için yeterli (bu alanlarda depolanan ne olduğunu görmek için yukarıdaki yorumları görmek) depolamak mı? Herhangi bir ek veri saklamalıyım, böylece kullanıcı ben döndüğünde kayıtlı verilerime göre onu doğrulayabilir miyim?

• Bunu uygulamak için başka (daha verimli) bir yaklaşım önerir misiniz?
  Teşekkür ederiz.

Answer 1

Mağaza Openid kullanıcı için ClaimedIdentifier - değil Sağlayıcı adresi. İddia Edilen Tanımlayıcı OpenID protokolünün doğruladığı, kullanıcı için benzersiz olan ve aynı zamanda OpenID Sağlayıcıları genelinde taşınabilirlik sağlayan potansiyeldir. Ayrıca, OpenID 2.0'ın İddia Edilen Tanımlayıcıları OpenID Connect (OpenID 2.0'a bitmemiş bir halefi olarak) tarafından kullanımdan kaldırılabileceğinden, OpenID Sağlayıcısı Son Nokta URI'sini ve e-posta adresinin verdiği e-posta adresini kaydetmek de sizin çıkarınıza olabilir. Kullanıcı kaydında sağlayıcı. Şimdilik, 'u, numaralı kimlik doğrulama akışınızın bir parçası olarak kullanmayın, ancak bunları kaydederek, daha sonra 'güvendiğiniz' e-posta adreslerini belirleyebileceksiniz (yani, Google'ın iddia ettiği e-posta adreslerine karar verdiğinizi varsayalım) ve Kullanıcının bu doğrulanmış e-posta adresini kullanarak hesaplarını OpenID Connect'e geçirmesine izin ver. Bu, web sitenizin Realm (genellikle http://yourdomainname.com) değişmesine ve tüm Google’ın İddia Edilen Tanımlayıcılarının değişmesine neden olacak ve bu da trajik bir şekilde yalnızca e-posta adreslerinden gerçekten kurtarılabilir.

Ayrıca, farklı kimlik doğrulama türleri için farklı tablolar kullanmanızı öneririz. Burada birkaç avantaj var. Bunlardan en önemlisi, web sitenize bir kullanıcı giriş alanı ve boş bir parola girmesi (örneğin) OpenID'ye girmesine izin verebilecek bir güvenlik deliği oluşturmayı daha da zorlaştırmasıdır. Herhangi bir gerçek kimlik doğrulama olmaksızın veritabanı eşleşmesi ve oturum açma. İkinci olarak, 'Kimlik Doğrulama' tablonuzun tüm kullanıcılar için yatay olarak büyümesini sağlamak yerine üçüncü bir kimlik doğrulama mekanizması eklemek istediğinizde daha esnek bir model sağlar. Örneğin, OAuth 2.0 ve "OpenID Connect" in her biri, yıllar içinde kendilerine destek eklediğinizde ve yeni veri türlerini daha iyi uyacak gibi görünüyorsa yeni tablolar eklediğinizde muhtemelen sitenize yeni kimlik doğrulama türlerini tanıtacaktır.

Answer 2

Sadece openid talep url'sini saklıyoruz. Sağlayıcıdan, kullanıcı adı gibi ek bilgi talep etmek isteyebilirsiniz. En önemli şey üyelik ve kimlik doğrulamayı ayırmaktır.

Bizim şema

Profiles 
-------- 
UserId 
FirstName 
LastName 
etc. 

Users 
----- 
Username 
Password 

Profiles.UserId onlar kayıtlı şekline bağlı olarak, kullanıcılar dahili kullanıcı adı veya onların OpenId iddia url ya depolayan bir dize özelliği basitçe oldu.

Başarılı bir kimlik doğrulama (iç kullanıcı adı/parola veya harici bir sağlayıcı kullanarak) aldıktan sonra, kimlik doğrulama çerezlerini kendi iç kullanıcı adlarını veya talep URL'lerini kullanarak ayarladık. Kullanıcının profilini almak sadece o zaman profiler bulmaktır (UserId == User.Identity.Name). Bu, bir kullanıcının herhangi bir noktada nasıl doğrulandığını (belki de bir iç hesaba geçerek veya farklı bir sağlayıcı kullanarak) değiştirmeyi seçebilmesi avantajına sahiptir.