.NET कोर आइडेंटिटी सर्वर 4 ऑथेंटिकेशन वीएस आइडेंटिटी ऑथेंटिकेशन

Question 1

मैं ASP.NET कोर में प्रमाणीकरण करने के उचित तरीके को समझने की कोशिश कर रहा हूँ। मैंने कई संसाधन देखे हैं (जिनमें से अधिकांश दिनांकित हैं)।

कुछ लोग क्लाउड आधारित समाधान जैसे कि एज़्योर एडी, या आइडेंटिटीसेवर 4 का उपयोग करने के लिए और मेरे स्वयं के टोकन सर्वर को होस्ट करने के लिए अल्टनेटिव समाधान प्रदान करते हैं।

प्रमाणीकरण के सरल रूपों में से एक .Net के पुराने संस्करण में, एक कस्टम Iprinciple बनाना और अतिरिक्त प्रमाणीकरण डेटा को अंदर संग्रहीत करना होगा।

public interface ICustomPrincipal : System.Security.Principal.IPrincipal
{
    string FirstName { get; set; }

    string LastName { get; set; }
}

public class CustomPrincipal : ICustomPrincipal
{
    public IIdentity Identity { get; private set; }

    public CustomPrincipal(string username)
    {
        this.Identity = new GenericIdentity(username);
    }

    public bool IsInRole(string role)
    {
        return Identity != null && Identity.IsAuthenticated && 
           !string.IsNullOrWhiteSpace(role) && Roles.IsUserInRole(Identity.Name, role);
    }

    public string FirstName { get; set; }

    public string LastName { get; set; }

    public string FullName { get { return FirstName + " " + LastName; } }
}

public class CustomPrincipalSerializedModel
{
    public int Id { get; set; }

    public string FirstName { get; set; }

    public string LastName { get; set; }
}

तब आप एक कुकी में अपने डेटा को सीरियल करेंगे और इसे क्लाइंट को वापस कर देंगे।

public void CreateAuthenticationTicket(string username) {     

    var authUser = Repository.Find(u => u.Username == username);  
    CustomPrincipalSerializedModel serializeModel = new CustomPrincipalSerializedModel();

    serializeModel.FirstName = authUser.FirstName;
    serializeModel.LastName = authUser.LastName;
    JavaScriptSerializer serializer = new JavaScriptSerializer();
    string userData = serializer.Serialize(serializeModel);

    FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(
    1,username,DateTime.Now,DateTime.Now.AddHours(8),false,userData);
    string encTicket = FormsAuthentication.Encrypt(authTicket);
    HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket);
    Response.Cookies.Add(faCookie);
}

मेरे प्रश्न हैं:

मैं पिछले संस्करण के .Net में किए गए तरीके के समान कैसे प्रमाणित कर सकता हूं वह अभी भी काम करने का पुराना तरीका है या एक नया संस्करण है।
अपने स्वयं के कस्टम सिद्धांत बनाने के लिए अपने स्वयं के टोकन सर्वर छंद का उपयोग करने के पेशेवरों और विपक्ष क्या हैं?
क्लाउड आधारित समाधान या एक अलग टोकन सर्वर का उपयोग करते समय आप अपने वर्तमान अनुप्रयोग के साथ कैसे एकीकृत करेंगे, क्या मुझे अभी भी अपने आवेदन में एक उपयोगकर्ता तालिका की आवश्यकता होगी आप दोनों को कैसे जोड़ेंगे?
होने के नाते इतने सारे अलग-अलग समाधान हैं कि मैं एक उद्यम आवेदन कैसे बना सकता हूं, जीमेल / फेसबुक के माध्यम से लॉग इन करने की अनुमति देने के लिए, जबकि अन्य एसएसओ के लिए विस्तार करने में सक्षम होने के बावजूद
इन तकनीकों के कुछ सरल कार्यान्वयन क्या हैं?

Question 2

टी एल; डॉ

पहचानकर्ता = OAuth 2.0 / OpenId- कनेक्ट के माध्यम से टोकन एन्क्रिप्शन और सत्यापन सेवाएं

ASP.NET पहचान = ASP.NET में वर्तमान पहचान प्रबंधन रणनीति

मैं पिछले संस्करण के .Net में किए गए तरीके के समान कैसे प्रमाणित कर सकता हूं वह अभी भी काम करने का पुराना तरीका है या एक नया संस्करण है।

मुझे कोई कारण नहीं है कि आप ASP.NET Core में पुराने तरीके को प्राप्त नहीं कर सके, लेकिन सामान्य रूप से, उस रणनीति को ASP.NET पहचान के साथ बदल दिया गया था, और ASP.NET पहचान जीवित है और ASP.NET Core में अच्छी तरह से है।

https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity

ASP.NET पहचान उपयोगकर्ता नाम, पासवर्ड (हैशेड), ईमेल, फोन जैसी उपयोगकर्ता जानकारी रखने के लिए SQL सर्वर जैसे एक बैकिंग स्टोर का उपयोग करता है और आसानी से FirstName, LastName या अन्य कुछ भी रखने के लिए बढ़ाया जा सकता है। तो, वास्तव में कुकी में उपयोगकर्ता जानकारी को एन्क्रिप्ट करने का कोई कारण नहीं है और इसे क्लाइंट से सर्वर पर आगे और पीछे से पास करें। यह उपयोगकर्ता के दावे, उपयोगकर्ता के टोकन, उपयोगकर्ता की भूमिका और बाहरी लॉगिन जैसी धारणाओं का समर्थन करता है। यहाँ ASP.NET पहचान में संस्थाएँ हैं:

AspNetUsers
AspNetUserRoles
AspNetUserClaims
AspNetUserLogins (बाहरी पहचान प्रदाताओं को जोड़ने के लिए, जैसे Google, AAD)
AspNetUserTokens (access_tokens और रीफ्रेश_tokens जैसी चीजों को स्टोर करने के लिए)

अपने स्वयं के कस्टम सिद्धांत बनाने के लिए अपने स्वयं के टोकन सर्वर छंद का उपयोग करने के पेशेवरों और विपक्ष क्या हैं?

एक टोकन सर्वर एक प्रणाली होगी जो प्राधिकरण और / या प्रमाणीकरण जानकारी युक्त एक सरल डेटा संरचना उत्पन्न करती है। प्राधिकरण आमतौर पर access_token नामक टोकन के लिए लेता है । यह "घर की चाबियाँ" होगी, इसलिए बोलने के लिए, आपको द्वार के माध्यम से और एक संरक्षित संसाधन के निवास में, आमतौर पर एक वेब एपी। प्रमाणीकरण के लिए, id_tokenउपयोगकर्ता / व्यक्ति के लिए एक विशिष्ट पहचानकर्ता होता है। हालांकि इस तरह के पहचानकर्ता को access_token में रखना आम है, अब ऐसा करने के लिए एक समर्पित प्रोटोकॉल है: OpenID- कनेक्ट ।

आपकी स्वयं की सुरक्षा टोकन सेवा (एसटीएस) का कारण, क्रिप्टोग्राफी के माध्यम से आपकी सूचना परिसंपत्तियों की सुरक्षा करना होगा, और उन संसाधनों को एक्सेस करने वाले ग्राहकों (अनुप्रयोगों) को नियंत्रित करना होगा। इसके अलावा, पहचान नियंत्रण के मानक अब OpenID- कनेक्ट विनिर्देशों में मौजूद हैं। IdentityServer एक OAuth 2.0 प्राधिकरण सर्वर का एक उदाहरण है जो एक OpenID- कनेक्ट प्रमाणीकरण सर्वर के साथ संयुक्त है।

लेकिन इसमें से कोई भी आवश्यक नहीं है यदि आप अपने आवेदन में केवल एक उपयोगकर्ता तालिका चाहते हैं। आपको एक टोकन सर्वर की आवश्यकता नहीं है- बस ASP.NET पहचान का उपयोग करें। ASP.NET पहचान सर्वर पर एक ClaimsIdentity ऑब्जेक्ट के लिए अपने उपयोगकर्ता को मैप करता है- एक कस्टम IPrincipal वर्ग के लिए कोई ज़रूरत नहीं है।

क्लाउड आधारित समाधान या एक अलग टोकन सर्वर का उपयोग करते समय आप अपने वर्तमान अनुप्रयोग के साथ कैसे एकीकृत करेंगे, क्या मुझे अभी भी अपने आवेदन में एक उपयोगकर्ता तालिका की आवश्यकता होगी आप दोनों को कैसे जोड़ेंगे?

किसी एप्लिकेशन के साथ अलग-अलग पहचान समाधानों को एकीकृत करने के लिए ये ट्यूटोरियल देखें: https://identityserver4.readthedocs.io/en/latest/quickstarts/0_overview.html https://auth0.com/docs/quickstart/webapp/aspnet-core

कम से कम आपको बाहरी प्रदाता के उपयोगकर्ता पहचानकर्ता को उपयोगकर्ता नाम मैप करने के लिए दो कॉलम तालिका की आवश्यकता होगी। यह ASP.NET पहचान में AspNetUserLogins तालिका क्या करता है। हालाँकि, उस तालिका की पंक्तियाँ AspNetUsers में उपयोगकर्ता रिकॉर्ड होने पर निर्भर हैं।

ASP.NET पहचान Google, Microsoft, फेसबुक जैसे किसी भी प्रदाता का समर्थन करती है, कोई भी OpenID- कनेक्ट प्रदाता, Azure AD पहले से ही हैं। (Google और Microsoft ने OpenID- कनेक्ट प्रोटोकॉल को पहले ही लागू कर दिया है, इसलिए आपको उनके कस्टम एकीकरण पैकेज की आवश्यकता नहीं है , उदाहरण के लिए, इस तरह से )। इसके अलावा, ADFS अभी ASP.NET कोर आइडेंटिटी पर उपलब्ध नहीं है।

ASP.NET पहचान में बाहरी प्रदाताओं के साथ आरंभ करने के लिए यह दस्तावेज़ देखें:

https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/

होने के नाते इतने सारे अलग-अलग समाधान हैं कि मैं एक उद्यम आवेदन कैसे बना सकता हूं, जीमेल / फेसबुक के माध्यम से लॉग इन करने की अनुमति देने के लिए, जबकि अन्य एसएसओ के लिए विस्तार करने में सक्षम होने के बावजूद

जैसा कि ऊपर बताया गया है, ASP.NET आइडेंटिटी पहले से ही ऐसा करता है। "बाहरी प्रदाता" तालिका बनाना और आपकी बाहरी लॉगिन प्रक्रिया को डेटा करना काफी आसान है। इसलिए जब एक नया "एसएसओ" आता है, तो बस प्रदाता के यूआरएल, क्लाइंट आईडी और गुप्त जैसे गुणों के साथ एक नई पंक्ति जोड़ें। ASP.NET पहचान में पहले से ही विजुअल स्टूडियो टेम्प्लेट में निर्मित UI है, लेकिन कूलर बटन के लिए सामाजिक लॉगिन देखें ।

सारांश

अगर आपको क्षमताओं में पासवर्ड साइन और उपयोगकर्ता प्रोफ़ाइल के साथ बस एक उपयोगकर्ता तालिका की आवश्यकता है, तो ASP.NET पहचान एकदम सही है। बाहरी अधिकारियों को शामिल करने की आवश्यकता नहीं है। लेकिन, यदि कई एप्स को कई एप्स तक पहुंचने की आवश्यकता है, तो पहचान और एक्सेस टोकन को सुरक्षित और मान्य करने के लिए एक स्वतंत्र प्राधिकरण समझ में आता है। IdentityServer एक अच्छा फिट है, या देखना openiddict कोर , या Auth0 एक बादल समाधान के लिए।

मेरी क्षमा याचना यह निशान नहीं मार रहा है या अगर यह बहुत ही परिचयात्मक है। आप जिस बैल की तलाश में हैं, उसे पाने के लिए कृपया बेझिझक बातचीत करें।

परिशिष्ट: कुकी प्रमाणीकरण

कुकीज़ के साथ नंगे हड्डियों का प्रमाणीकरण करने के लिए, इन चरणों का पालन करें। लेकिन, मेरी जानकारी में एक कस्टम दावा प्रिंसिपल समर्थित नहीं है। उसी प्रभाव को प्राप्त करने के लिए, ClaimPrincipalवस्तु की दावा सूची का उपयोग करें ।

डायलॉग में "नो ऑथेंटिकेशन" का चयन करते हुए विज़ुअल स्टूडियो 2015/2017 में एक नया ASP.NET Core 1.1 वेब एप्लिकेशन बनाएं। फिर पैकेज जोड़ें:

Microsoft.AspNetCore.Authentication.Cookies

इस (पहले ) जगह Configureमें विधि के तहत :Startup.csapp.UseMvc

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationScheme = "MyCookieMiddlewareInstance",
    LoginPath = new PathString("/Controller/Login/"),
    AutomaticAuthenticate = true,
    AutomaticChallenge = true
});

फिर एक लॉगिन यूआई बनाएं और html फॉर्म को इस तरह एक्शन विधि में पोस्ट करें:

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Login(String username, String password, String returnUrl = null)
{
    ViewData["ReturnUrl"] = returnUrl;
    if (ModelState.IsValid)
    {
        // check user's password hash in database
        // retrieve user info

        var claims = new List<Claim>
        {
            new Claim(ClaimTypes.Name, username),
            new Claim("FirstName", "Alice"),
            new Claim("LastName", "Smith")
        };

        var identity = new ClaimsIdentity(claims, "Password");

        var principal = new ClaimsPrincipal(identity);

        await HttpContext.Authentication.SignInAsync("MyCookieMiddlewareInstance", principal);

        return RedirectToLocal(returnUrl);
    }

    ModelState.AddModelError(String.Empty, "Invalid login attempt.");

    return View();
}

HttpContext.User ऑब्जेक्ट में आपके कस्टम दावे होने चाहिए और आसानी से ClaimPrincipal के सूची संग्रह को पुनर्प्राप्त करने योग्य हैं।

मुझे उम्मीद है कि यह पूरी तरह से समाधान / परियोजना एक StackOverflow पोस्ट के लिए थोड़ा सा लगता है।

Question 3

टी एल; डॉ

मैं वास्तव में IdentityServer4 को ठीक से लागू करने के तरीके पर एक पूर्ण पोस्टिंग दिखाना चाहूंगा लेकिन मैंने पाठ के सभी को फिट करने की कोशिश की, लेकिन यह स्टैकऑवरफ्लो स्वीकार करने की सीमा से परे था इसलिए मैं इसके बजाय कुछ टिप्स और चीजें सीख गया हूं जिन्हें मैंने सीखा है।

टोकन सर्वर बनाम एएसपी पहचान का उपयोग करने के क्या लाभ हैं?

एक टोकन सर्वर में बहुत अधिक लाभ है, लेकिन यह सभी के लिए सही नहीं है। यदि आप एक उद्यम जैसे समाधान को लागू कर रहे हैं, जहाँ आप चाहते हैं कि कई ग्राहक लॉगिन करने में सक्षम हों, तो टोकन सर्वर आपकी सबसे अच्छी शर्त है, लेकिन यदि आप केवल एक साधारण वेबसाइट बना रहे हैं जो बाहरी लॉगिन का समर्थन करना चाहते हैं, तो आप एएसपी पहचान के साथ दूर हो सकते हैं और कुछ मिडलवेयर।

पहचान सर्वर 4 युक्तियाँ

पहचान सर्वर 4 बहुत अच्छी तरह से अन्य रूपरेखाओं की तुलना में प्रलेखित है जिसे मैंने देखा है, लेकिन खरोंच से शुरू करना और पूरी तस्वीर देखना मुश्किल है।

मेरा पहला मिस्टेक OAuth को प्रमाणीकरण के रूप में उपयोग करने की कोशिश कर रहा था, हाँ, ऐसा करने के तरीके हैं लेकिन OAuth प्राधिकरण के लिए है प्रमाणीकरण नहीं है, यदि आप OpenIdConnect (OIDC) का उपयोग प्रमाणित करना चाहते हैं

मेरे मामले में मैं एक जावास्क्रिप्ट क्लाइंट बनाना चाहता था, जो एक वेब एपीआई से जुड़ता है। मैंने बहुत सारे समाधानों को देखा, लेकिन शुरू में मैंने आइडेंटिटी सर्वर के खिलाफ ऑथेंटिकेट को कॉल करने के लिए वेबैपी का उपयोग करने की कोशिश की और बस उस टोकन को जारी रखने वाला था क्योंकि यह सर्वर के खिलाफ सत्यापित था। यह प्रवाह संभावित रूप से काम कर सकता है लेकिन इसमें बहुत सारी खामियां हैं।

अंत में उचित प्रवाह जब मैंने जावास्क्रिप्ट क्लाइंट नमूना पाया तो मुझे सही प्रवाह मिला। आप क्लाइंट लॉग इन करते हैं और एक टोकन सेट करते हैं। फिर आपके पास अपना वेब एप है जो OIdc क्लाइंट का उपभोग करता है, जो सत्यापित करेगा कि आप IdentityServer के खिलाफ टोकन एक्सेस कर रहे हैं।

स्टोर और माइग्रेशन से जुड़ना मुझे पहले से माइग्रेशन के साथ कुछ गलतफहमी थी। मैं इस धारणा के तहत था कि माइग्रेशन चलाने से SQL को आंतरिक रूप से dll से उत्पन्न किया जाता है, उपयोग करने के बजाय आप कॉन्फ़िगर करते हैं कि कैसे एसक्यूएल को बनाया जाए।

माइग्रेशन के लिए दो सिंटैक्स होते हैं, जिनके बारे में जानना कि आपका कंप्यूटर कौन सा उपयोग करता है:

dotnet ef migrations add InitialIdentityServerMigration -c ApplicationDbContext

Add-Migration InitialIdentityServerDbMigration -c ApplicationDbContext

मुझे लगता है कि माइग्रेशन के बाद पैरामीटर नाम है, आपको नाम की आवश्यकता क्यों है मुझे यकीन नहीं है, ApplicationDbContextएक कोड-फर्स्ट डीबोनटेक्स्ट है जिसमें आप बनाना चाहते हैं।

माइग्रेशन कुछ ऑटो-मैजिक का उपयोग करते हैं ताकि आप यह जान सकें कि आपके स्टार्ट अप को कैसे कॉन्फ़िगर किया गया है, से कनेक्शन स्ट्रिंग है, मैंने बस यह मान लिया था कि यह सर्वर एक्सप्लोरर से कनेक्शन का उपयोग करता है।

यदि आपके पास कई परियोजनाएं हैं, तो सुनिश्चित करें कि आपके पास स्टार्ट अप के रूप में ApplicationDbContext सेट के साथ परियोजना है।

प्राधिकरण और प्रमाणीकरण को लागू करते समय बहुत सारे चलती भागों होते हैं, उम्मीद है, यह पोस्ट किसी की मदद करती है। प्रमाणों को पूर्ण रूप से समझने का सबसे आसान तरीका यह है कि सब कुछ एक साथ करने के लिए उनके उदाहरणों को अलग-अलग चुना जाए और यह सुनिश्चित किया जाए कि आपके दस्तावेज पढ़ें

Question 4

ASP.NET आइडेंटिटी - यह आपके एप्लिकेशन को प्रमाणित करने के लिए एक तरह से बिल्ड है, चाहे वह बियरर हो या बेसिक ऑथेंटिकेशन, यह हमें रेडीमेड कोड देता है ताकि यूजर रजिस्ट्रेशन, लॉगिन, पासवर्ड को बदल सकें और सभी।

अब विचार करें कि हमारे पास 10 अलग-अलग एप्लिकेशन हैं और सभी 10 ऐप्स में एक ही काम करना संभव नहीं है। यह बहुत नाजुक और बहुत बुरा अभ्यास है।

इस समस्या को हल करने के लिए जो हम करने में सक्षम हैं, वह हमारे प्रमाणीकरण और प्राधिकरण को केंद्रीकृत करता है, इसलिए जब भी इसके साथ कोई भी परिवर्तन सभी 10 ऐप्स को प्रभावित नहीं करेगा।

पहचान सर्वर आपको वही करने की क्षमता प्रदान करता है। हम एक नमूना वेब ऐप बना सकते हैं जो सिर्फ आइडेंटिटी सेवा के रूप में उपयोग किया जाता है और यह आपके उपयोगकर्ता को मान्य करेगा और कुछ JWT एक्सेस टोकन प्रदान करेगा।

Question 5

मैंने हमेशा ASP.NET आइडेंटिटी (और पहले की सदस्यता) प्राधिकरण / प्रमाणीकरण में निर्मित का उपयोग किया है, मैंने Auth0 को हाल ही में लागू किया है ( https://auth0.com ) और इसे कोशिश करने के लिए कुछ और के रूप में सुझाता हूं ।

Question 6

सामाजिक लॉगिन पहचान के साथ लागू करना मुश्किल नहीं है, लेकिन इसमें कुछ प्रारंभिक सेटअप शामिल है और कभी-कभी डॉक्स में आपके द्वारा ऑनलाइन पाए जाने वाले चरण समान नहीं होते हैं, आमतौर पर आप उस मंच के डेवलपर्स अनुभाग के तहत मदद प्राप्त कर सकते हैं जिसे आप सेटअप करने का प्रयास कर रहे हैं। के लिए सामाजिक लॉगिन पहचान .net फ्रेमवर्क की विरासत संस्करणों में पाई जाने वाली पुरानी सदस्यता कार्यक्षमता का प्रतिस्थापन है। मुझे जो आश्चर्यजनक लगा है, वह यह है कि किनारे के उपयोग के मामले, जैसे कि एक jwt टोकन को पास करना जो आपके पास पहले से ही एक वेब एपीआई के उदाहरणों में कहीं भी शामिल नहीं हैं। प्लुरलिटी पर भी, मुझे यकीन है कि आपको ऐसा करने के लिए अपने स्वयं के टोकन प्राधिकरण की आवश्यकता नहीं है, लेकिन मुझे इस बात का एक भी उदाहरण नहीं मिला है कि किसी ऐसे डेटा को कैसे प्राप्त करें या पोस्ट करें जो स्वयं-होस्ट किए गए सर्वर के साथ काम नहीं कर रहा है।