यह आलेख उन सभी के लिए दिलचस्प होगा जो वास्तविक जीवन के उदाहरण का उपयोग करते हुए भयानक शब्द "एक्टिव डायरेक्ट्री फेडरेशन सर्विसेज" का अर्थ जानना चाहते हैं, साथ ही उन सभी के लिए जो SharePoint पर आधारित कस्टम सिस्टम विकसित कर रहे हैं और यह निर्णय लेने की प्रक्रिया में है कि कौन सा प्राधिकरण और प्रमाणीकरण मॉडल चुनना है, या ADFS के लिए मौजूदा समाधान स्विच करने के लिए जा रहा है।
और सबसे महत्वपूर्ण बात, यह उन लोगों के लिए उपयोगी है जो एक आईटी उत्पाद के उपभोक्ता गुणों, उसके मूल्य और अंतिम उपयोगकर्ता को सुविधा प्रदान करते हैं।
हाल ही में, हमने ADFS पोर्टल को अपने एक ग्राहक की वफादारी कार्यक्रम में स्थानांतरित कर दिया। यह सिस्टम में बुनियादी ढांचे में बदलाव की एक बड़ी प्रक्रिया का हिस्सा बन गया है। व्यावसायिक लक्ष्यों के संबंध में जटिल चीजों के बारे में बात करना हमेशा अधिक दिलचस्प होता है जो इन जटिल तकनीकी चीजों की सेवा करते हैं। इसलिए - निष्ठा कार्यक्रम का एक छोटा विवरण।
यह कैशियर के लिए एक वफादारी प्रणाली है जो हमारे ग्राहक की सेवाएं बेचते हैं। इसे MS SharePoint पर निष्पादित किया जाता है। पोर्टल के माध्यम से, कैशियर बोनस जमा करते हैं और उनके लिए उपहार (स्मारिका, यात्रा पैकेज, उपहार कार्ड, आदि) प्राप्त करते हैं। इस प्रकार, कंपनी लचीले ढंग से आवश्यक "पदों" की बिक्री का प्रबंधन कर सकती है, कैशियर और एजेंसियों के काम का विश्लेषण कर सकती है और बहुत कुछ।
हम शुरू से ही एक वफादारी कार्यक्रम विकसित कर रहे हैं। पहली रिलीज़ फरवरी 2013 में हुई। सिस्टम का विकास जारी है। उदाहरण के लिए, हमने अभी पोर्टल का पूरा नया स्वरूप पूरा किया है। लेकिन यह ADFS के आधुनिकीकरण से पहले आधुनिकीकरण के सबसे महत्वपूर्ण चरण के रूप में था। इस पर आगे चर्चा की गई है।
संक्षेप में, ADFS ऑपरेशन योजना को निम्नानुसार वर्णित किया जा सकता है:
क्लाइंट पोर्टल पर जाता है, पोर्टल वेब सर्वर क्लाइंट को प्राधिकरण के लिए ADFS सेवा पर पुनर्निर्देशित करता है। यहां, ग्राहक प्राधिकरण पारित करता है और सीएलएआईएम प्राधिकरण सेवा (टोकन) से प्राप्त करता है, फिर इस टोकन की मदद से, वह पोर्टल पर अधिकृत होता है।
ADFS के लिए पलायन
लॉयल्टी प्रोग्राम SharePoint पर आधारित एक जटिल समाधान का हिस्सा है, जिसमें विभिन्न उप-प्रणालियाँ होती हैं जो विभिन्न साइटों पर रहती हैं। प्रवेश को सरल और ब्रांड बनाने के लिए, इन सभी उत्पादों में सिंगल साइन ऑन प्रदान करना आवश्यक था, ताकि उपयोगकर्ताओं को अधिक परिचित बनाया जा सके।
इस मामले में, खरोंच से समाधान बनाने की आवश्यकता नहीं थी, लेकिन "क्लासिक ntlm" से ADFS को "प्राधिकरण का प्रवास"। और हम
हस्तांतरण के लिए पूरी की गई बहु-स्तरीय तैयारी के अपने
क्लासिक तरीके से चले गए:
- हमने अपनी परीक्षण साइट पर एक समाधान का एक प्रोटोटाइप तैनात किया और त्रुटियों को दूर करना शुरू कर दिया।
- यह सुनिश्चित करने के बाद कि सब कुछ काम करता है, उन्होंने समाधान को तैनात करने के लिए दस्तावेज तैयार किया और ग्राहक को भेजा ताकि वह घर पर समाधान तैनात करे।
- परीक्षण कॉन्फ़िगरेशन पर ग्राहक पर परीक्षण किया गया।
- सफलतापूर्वक एक माइग्रेशन माइग्रेशन किया गया।
हम अपने स्वयं के समाधान का विश्लेषण करते हैं
इसलिए, शुरुआत के लिए, हम विश्लेषण करते हैं कि हमें संक्रमण के लिए क्या चाहिए:
- हमारे पास साइट उपयोगकर्ताओं (कई हजार) की एक सूची है जिन्हें दावे की प्रविष्टियों के साथ बदलने की आवश्यकता है।
- हमारे पास कस्टम अनुमतियों के साथ दस्तावेजों की सूची और पुस्तकालय हैं। और यह आवश्यक है कि नए उपयोगकर्ताओं के प्रवास के बाद अधिकार समान रहें।
- हमारे पास कस्टम कोड (वेब पार्ट्स, पेज, हैंडलर इत्यादि) का एक गुच्छा है, जो AD के माध्यम से उपयोगकर्ता की पहुंच के स्तर की जांच करता है। इस बात को सभी को ध्यान में रखना चाहिए और इस तथ्य को फिर से लिखना चाहिए कि उपयोगकर्ताओं को कलंकित किया जा सकता है।
- चूंकि हम ADFS के लिए नहीं पूरे पोर्टल पर स्विच कर रहे हैं, लेकिन केवल एक अलग साइट है, इसलिए हमें एक अलग वेब एप्लिकेशन में साइट का चयन करना होगा। लेकिन डेटा का हिस्सा रूट नोड से उपयोग किया जाता है, इसलिए WCF सेवा में डेटा परत को रखना आवश्यक है, जिसके साथ हम अपने नए एप्लिकेशन में यह डेटा प्राप्त करेंगे।
हम प्रक्रिया शुरू करते हैं:
- हमने 4 बिंदुओं के साथ शुरुआत की - एक अलग सेवा में रूट नोड से डेटा प्राप्त करने और हमारे नोड के बाद के अलगाव को एक अलग एप्लिकेशन में आवंटित करने का।
पहले भाग में, कोई विशेष समस्या उत्पन्न नहीं हुई - साधारण कोड रीफैक्टरिंग और एक WCF सेवा स्थापित करना। कुछ हफ़्ते - और सब कुछ काम करता है।
नोड के एक अलग अनुप्रयोग में अलग होने के साथ, कुछ कठिनाइयां थीं। मूल रूप से, वे इस तथ्य से जुड़े थे कि आयात / निर्यात करते समय यह सुनिश्चित करना आवश्यक था कि सभी डेटा सहेजे गए थे, उपयोगकर्ताओं को खींच लिया गया था, अधिकार बने रहे। लेकिन चूंकि नोड पर बहुत अधिक डेटा था, इसलिए आयात / निर्यात प्रक्रिया में लगभग 3 घंटे लगे, और यदि परिणाम विफल रहा, तो पूरी बात को फिर से शुरू करना पड़ा और फिर से डाल दिया गया।
कुछ समय के लिए सबसे लंबी और समझ से बाहर की समस्या उपयोगकर्ताओं को आयात करने में समस्या थी। वे सामान्य रूप से आयात किए गए लग रहे थे, लेकिन उपयोगकर्ता प्रकार के साथ सूचियों और पुस्तकालयों और क्षेत्रों के अधिकारों को बहाल नहीं करना चाहते थे।
कारणों की लंबी और दर्दनाक खोज के बाद, यह पता चला: समस्या यह है कि पोर्टल को पहले SharePoint 2007 से SharePoint 2010 में माइग्रेट किया गया था, और उपयोगकर्ता प्रकार फ़ील्ड का विवरण सूची योजना में अपूर्ण था। पहले मुझे उपयोगिता (अपने द्वारा लिखित) को चलाना था, फिर निर्यात / आयात करना था। उसके बाद, आयात सफल रहा। - अब आप नए एप्लिकेशन को ADFS में बदल सकते हैं। हम मानक प्रक्रिया का पालन करते हैं:
एक। PowerShell स्क्रिप्ट के माध्यम से विश्वसनीय ADFS सर्वर और प्रमाणपत्र स्थापित करें
$map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $map2 = New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming $map3 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UserPrincipalName" -SameAsIncoming $signingTokenCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$signingTokenCertPath") $webServerCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$webServerCertPath") $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS Federated Server" -Description "ADFS Federated Server" -Realm $realm -ImportTrustCertificate $signingTokenCert -ClaimsMappings $map1,$map2,$map3 -SignInUrl $signinurl -IdentifierClaim $map3.InputClaimType New-SPTrustedRootAuthority "ADFS Token Signing" -Certificate $signingTokenCert New-SPTrustedRootAuthority "ADFS web server" -Certificate $webServerCert
ख। एप्लिकेशन प्रमाणीकरण सेटिंग बदलें
सी। हम उपयोगकर्ताओं को माइग्रेट करते हैं ताकि सभी अनुमतियां क्लेम के माध्यम से (फिर से पॉवरशेल स्क्रिप्ट के माध्यम से) बनें
$webAppUrl = "..." $account = "..." $account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString() $webApp = get-SPWebApplication $webAppUrl $policy = $webApp.ZonePolicies("Default").Add($account,"PSPolicy") $fullControlRole=$webApp.PolicyRoles.GetSpecialRole("FullControl") $policy.PolicyRoleBindings.Add($fullControlRole) $webApp.Update() $webApp.MigrateUsers($true) $webApp.ProvisionGlobally()
घ। उसके बाद, हम सभी मौजूदा खातों को अपडेट करते हैं और उन्हें फॉर्म के क्लेम रिकॉर्ड में लाते हैं I: 0e.t | ADFS Federated Server। उपयोगकर्ता @ कंपनी
उसके बाद, सब कुछ एक पूरे के रूप में काम किया। फिर हमने स्थानीय स्तर पर और परीक्षण सर्वर पर लंबे समय तक प्रशिक्षण लिया।
मुकाबला स्विचिंग और चुनौतियां
मुकाबला स्विच शनिवार को किया गया था, क्योंकि निर्यात / आयात का समय केवल लगभग 5 घंटे था। नतीजतन, सभी छोटी समस्याओं के साथ सुबह 9 बजे शुरू हुआ, रात में 12 बजे समाप्त हुआ :)
सामान्य तौर पर, सब कुछ ठीक काम करता था, इससे पहले कि सभी ने परीक्षण वातावरण पर प्रशिक्षित और परीक्षण किया था। लेकिन एक बग यह निकल गया कि हमने कभी भी परीक्षण एक पर दोहराया नहीं (और अभी भी नहीं दोहराता) - इंटरनेट एक्सप्लोरर में लॉगआउट समस्या।
नीचे पंक्ति है:बाहर निकलने के लिए, विज्ञापन के ADFS सर्वर पृष्ठ पर
adfs.ru/adfs/ls/?wa=wsignout1.0&Source=yoursiteurl के रीडायरेक्ट का उपयोग करें
पृष्ठ का अनुरोध करते समय, सर्वर हैंडलर ADFS से सत्र हटाता है, और SharePoint में प्राधिकरण कुकीज़ और सत्र को हटाने के लिए, उसी पृष्ठ में एक अदृश्य iframe होता है जिसमें SharePoint पोर्टल का निकास पृष्ठ लोड होता है।
इसलिए, सही ढंग से काम करने के लिए SharePoint से बाहर निकलने के लिए, आपको प्राधिकरण कुकीज़ FedAuth / पास करना होगा
जैसा कि यह निकला, यह हमेशा IE में नहीं होता है, और प्रभाव तब होता है जब हम निकास को दबाते हैं, लेकिन बाहर नहीं निकल सकते।
नतीजतन, मुझे एग्जिट यूआरएल को थोड़ा मोड़ना पड़ा, ताकि एडीएफएस लॉगआउट पेज से काम करने के बाद, SharePoint लॉगआउट पेज को सीधे कॉल किया गया, और इसके बाद एडीएफएस प्राधिकरण पृष्ठ वापस आ गया:
https://myadfs.ru/adfs/ls/?wa=wsignout1.0&Source=https%3a%2f%2fmysharepoint%2f_trust%2f%3fwa%3dwsignoutcleanup1.0%26wreply%3dhttps%3a%2f%2fmyadfs.ru%2f(यह एमएस बॉक्स के बाहर के लिए प्रदान किया गया है)।
निष्कर्ष
ग्राहक के लिए ADFS के प्रति वफादारी कार्यक्रम का प्रवास महत्वपूर्ण क्यों था?
- ADFS आपको भयावह मानक विंडोज ऑथेंटिकेशन फॉर्म के बजाय एक अनुकूल लॉगिन पासवर्ड का उपयोग करके पोर्टल में लॉग इन करने की अनुमति देता है। इसके अलावा, यदि उपयोगकर्ता पासवर्ड भूल गया है, तो सिस्टम उसे बताएगा, व्यवस्थापक की तलाश करने और उसे साबित करने की कोई आवश्यकता नहीं होगी कि आप ऊंट नहीं हैं।
- इस तरह के प्रवेश को कॉर्पोरेट रंगों और प्रतीकों के साथ ब्रांड किया जा सकता है और एकीकृत कॉर्पोरेट दृश्य मानकों के अनुरूप बनाया जा सकता है।
- ADFS प्राधिकरण पर एकल साइन को कॉन्फ़िगर करना संभव बनाता है, और उपयोगकर्ता खाते नहीं बना पाएंगे, लेकिन सामाजिक नेटवर्क पर अपने खातों का उपयोग करने में लॉग इन करेंगे। लेकिन यह उनके भावनात्मक संतुलन और काम के प्रति सकारात्मक दृष्टिकोण को प्रभावित नहीं कर सकता है :)
- ADFS हमारे ग्राहक जैसे जटिल सिस्टम में उपयोग के लिए एकदम सही है एक सत्र में विभिन्न वेब अनुप्रयोगों के लिए एकल साइन-ऑन कार्यक्षमता प्रदान करता है।