सेल्फ़-होस्टेड Duende छोड़ना: क्या माइग्रेट होता है, और किसे ऑपरेट करना बंद कर देते हैं

Duende IdentityServer सचमुच एक बेहतरीन सॉफ़्टवेयर है — अगर आप अपनी identity layer को शुरू से अंत तक ख़ुद संभालना चाहते हैं, तो .NET में यही मानक है। लेकिन "इसे संभालना" ही पूरी क़ीमत है: आप इसे host करते हैं, patch करते हैं, scale करते हैं, और इसके आस-पास सब कुछ बनाते हैं — admin UI, MFA, audit logs, branding, एक status page, user और role management। किसी मोड़ पर एक टीम तय करती है कि वह बजाय एक IdP ऑपरेट करने के और कुछ करना चाहती है, और तब एकमात्र सवाल जो मायने रखता है, वह है कि माइग्रेट करना कितना तकलीफ़देह है। यहाँ बताया गया है कि असल में क्या माइग्रेट होता है।

आप असल में क्या चला रहे हैं

Duende को सेल्फ़-होस्ट करने पर आप token endpoints से कहीं ज़्यादा के लिए ज़िम्मेदार हो जाते हैं:

• IdP ख़ुद — hosting, scaling, patching, और license (SAML इसके ऊपर एक paid add-on है)।
• इसके आस-पास की हर चीज़ जो आपने ख़ुद बनाई — admin portal, MFA enrolment, audit logging, custom branding, एक status page, user/role management।

वह दूसरी सूची ही आम तौर पर असली समय खा जाती है।

क्या माइग्रेट होता है — और यह ज़्यादातर यांत्रिक है

Duende अपना config SQL में रखता है (ConfigurationDb) और अपने users को ASP.NET Identity में। एक माइग्रेशन दोनों को पढ़ता है:

• Clients → OAuth clients, जिनमें redirect और logout URIs, CORS origins, grant types, refresh-token usage/expiration semantics, और device-code lifetimes शामिल हैं। Disabled clients disabled के रूप में import होते हैं; expired secrets को एक चेतावनी के साथ छोड़ दिया जाता है।
• Scopes → ApiScopes और IdentityResources सीधे मैप होते हैं। Duende की ApiResource मध्य परत (एक audience के साथ एक साझा claims सूची) सरल मॉडल पर समतल हो जाती है: resource name हर उस client पर एक audience बन जाता है जो किसी member scope का उपयोग करता है, और उसके claims उन scopes पर मिल जाते हैं।
• Users → अच्छी ख़बर: ASP.NET Identity V3 password hashes (और legacy bcrypt) मूल रूप से verify होते हैं और पहली बार sign-in पर rehash होते हैं। कोई password reset नहीं, कोई support ticket नहीं, ऐसा कुछ नहीं जो आपके उपयोगकर्ता नोटिस करें। (यही वह हिस्सा है जो Auth0 छोड़ते समय सचमुच मुश्किल होता है — Duende के साथ यह बस काम कर जाता है, क्योंकि यह वही hashing है जो आपका app पहले से इस्तेमाल करता है।)
• Roles और assignments, external logins, और OIDC identity providers सब आ जाते हैं। SAML providers को दूसरी तरफ़ फिर से कॉन्फ़िगर करने के लिए आपके सामने चिह्नित कर दिया जाता है।

identity-स्थिरता वाला हिस्सा

किसी भी IdP माइग्रेशन की तरह, जिसे सही करना है वह है user sub या client_id को न बदलना — downstream refresh tokens, ग्राहक IdPs में SCIM rows, और आपके अपने database में संग्रहीत user IDs सब इन्हें संदर्भित करते हैं। importer दोनों को बनाए रखता है। और अगर आपका कोई portal owner एक अलग ID के तहत Duende user के रूप में भी मौजूद है, तो यह उन्हें (Duende sub पर rotate करते हुए) चरणबद्ध, recoverable क़दमों के ज़रिए मेल कराता है, बजाय एक आधा-माइग्रेटेड owner छोड़ने के जो sign in न कर सके।

माइग्रेशन की टेस्टिंग पर एक बात (एक .NET गड़बड़ी)

हम importer को एक असली, seeded Duende database के ख़िलाफ़ टेस्ट करते हैं, mocks के ख़िलाफ़ नहीं — और इसका फ़ायदा हुआ। ASP.NET Identity AspNetUsers.LockoutEnd को एक datetimeoffset के रूप में संग्रहीत करता है, और इसे reader.GetDateTime() से पढ़ने पर उस type पर एक InvalidCastException आता है। तो एक अकेला locked-out उपयोगकर्ता पूरे user import को फ़ेल कर देता। आप इसे केवल असली डेटा के ख़िलाफ़ importer चलाकर ही पाते हैं, ऐसे डेटा के ख़िलाफ़ जिसमें एक locked-out उपयोगकर्ता हो। अगर आप किसी माइग्रेशन टूल को तौल रहे हैं, तो पूछने लायक़ सवाल यही है: क्या इसे एक भरे हुए database के ख़िलाफ़ टेस्ट किया गया है, या बस source API के ख़िलाफ़ mock किया गया है?

आप क्या करना बंद कर देते हैं

माइग्रेट करने का मक़सद माइग्रेशन नहीं है — मक़सद है उसके बाद की हर चीज़। SAML, SCIM, MFA, audit logs, custom domains और branding शामिल हैं, न कि ऐसी चीज़ें जिन्हें आप बनाते और ऑपरेट करते हैं, और IdP को patch और scale करना आपकी समस्या नहीं रह जाती। अगर Duende को सेल्फ़-होस्ट करना एक जानबूझकर लिया गया "हमें पूरा नियंत्रण चाहिए" वाला फ़ैसला था और अब भी है, तो रुके रहें — यह एक बिल्कुल सही चुनाव है। यह तब के लिए है जब एक IdP चलाना अब वह जगह नहीं रही जहाँ आप अपना समय बिताना चाहते हैं।

अगर आप इस पर विचार कर रहे हैं

माइग्रेशन ज़्यादातर यांत्रिक है, passwords बिना reset के आ जाते हैं, और preview read-only है — इसे अपने Duende database की ओर इंगित करें और यह आपको ठीक-ठीक दिखा देता है कि कुछ भी लिखे जाने से पहले क्या import होगा।

→ Duende से माइग्रेट करें