क्या कोई कारण है कि सॉफ्टवेयर डेवलपर्स प्राधिकरण को बाहरी नहीं कर रहे हैं?

Question

बाह्यकरण पहचान का मूल्य प्रस्ताव बढ़ाना शुरू हो रहा है जहां कई साइटें अब ओपनआईडी, कार्डस्पेस या संघीय पहचान स्वीकार करती हैं। हालांकि, कई डेवलपर्स ने अभी तक प्राधिकरण को बाहरी करने और XACML के आधार पर दृष्टिकोण का उपयोग करने के लिए अगला कदम नहीं उठाया है।

क्या जागरूकता की कमी या कुछ और कारण है? आप सॉफ्टवेयर विकास के लिए XACML-आधारित दृष्टिकोण के बारे में कैसे सीखेंगे?

कृपया ध्यान दें कि मैं प्राधिकरण के बारे में पूछ रहा हूं, प्रमाणीकरण नहीं।

Answer 1

मुझे लगता है कि प्राधिकरण को बाहरीकरण की संभावना प्रमाणीकरण (ओपनआईडी, कार्डस्पेस इत्यादि) को बाहरी करने की तुलना में कहीं अधिक कठिन बात है। यह मुख्य रूप से इस तथ्य के कारण है कि प्राधिकरण बहुत अधिक विशिष्ट अनुप्रयोग है। मेरे आवेदन में क्या व्यक्ति ए को अधिकृत करने के लिए अधिकृत किया गया है, वह आपके आवेदन में ऐसा करने में सक्षम नहीं हो सकता है, और यह भी मान रहा है कि मेरे आवेदन और आपके बीच कुछ सामान्य पैरारल है, जो संभवतः वहां नहीं होगा।

मैं यह नहीं कहना चाहता कि बाहरीकरण प्राधिकरण कभी भी नहीं किया जाएगा, लेकिन मुझे ईमानदारी से एक कठिन समय आ रहा है कि आप वास्तव में ऐसा क्यों करना चाहते हैं। हो सकता है कि अनुप्रयोगों के एक सूट के लिए जो एक तरफ काम करते हैं, लेकिन फिर से, संभवतः बाहरी रूप से आंतरिक रूप से समर्थित किया जाएगा।

Answer 2

मुझे लगता है कि यह उस प्रोजेक्ट के प्रकार पर निर्भर करता है जिस पर आप काम करते हैं। यदि ग्राहक प्राधिकरण को स्टोर करना चाहता है तो ओपनआईडी का उपयोग करने का कोई तरीका नहीं है ... मैं Google Apps इंजन का उपयोग करके एक छोटी परियोजना विकसित करता हूं और इसके लिए मैं प्राधिकरण करने के लिए Google का उपयोग करता हूं। तो यह परियोजना के प्रकार पर दृढ़ता से निर्भर करता है।

Answer 3

हमारा मुख्य कारण यह है कि हम खुद को रोल करना जारी रखते हैं कि ओपनिड एट अल जैसे विकल्प केवल तकनीकी साइटों द्वारा समर्थित हैं। हम एक छोटे खिलाड़ी हैं, इसलिए हम एक बाहरी प्रदाता का उपयोग शुरू नहीं करेंगे जब तक कि अधिक उपयोगकर्ता स्वीकृति न हो।

हम नहीं चाहते हैं कि किसी उपयोगकर्ता को दूसरी साइट पर जाने के लिए हमारी साइट पर क्या करना है।

Answer 4

अधिकांश परियोजनाएं जो मैंने की हैं, बड़ी कंपनियों के भीतर उपयोग के लिए मालिकाना अनुप्रयोग हैं, और उन मामलों में बाहरी प्रमाणीकरण सेवाएं शायद ही कभी एक विकल्प हैं, लेकिन प्रमाणीकरण को कुछ आंतरिक सेवा (जैसे सक्रिय निर्देशिका) द्वारा नियंत्रित किया जाता है।

क्या मुझे ऐसी परियोजना का हिस्सा बनना चाहिए जो सार्वजनिक वेबसाइट का निर्माण करे, मैं निश्चित रूप से अपने स्वयं के प्रमाणीकरण की मेजबानी के बजाय ओपनआईडी जैसे कुछ का उपयोग करने की कोशिश करता हूं।

Answer 5

इसके अलावा, उस प्राधिकरण को याद रखें! == प्रमाणीकरण। सिर्फ इसलिए कि उपयोगकर्ता प्रमाणित है इसका मतलब यह नहीं है कि आपने अपनी साइट के प्राधिकरण भाग को हल किया है। आपको अभी भी यह निर्धारित करने की आवश्यकता है कि कौन और कब करना है।

Answer 6

एक समस्या यहां खोज की गई कुछ संयोजन नहीं है और बाह्य अधिकारियों के अविश्वास (यहां तक ​​कि छद्म) पहचान के अविश्वास है। एक अच्छा लेख यहाँ है:

• Do You Trust your Identity Provider?

इसके अलावा, मैं यह जड़ता हो सकता है लगता है। इसे मारने के लिए एक हत्यारा ऐप के बिना, लोग माइग्रेट करने में धीमे होते हैं। फेसबुक-इंटीग्रेशंस की संख्या में वृद्धि को देखते हुए मैंने हाल ही में देखा है कि मुझे लगता है कि हम उस दुनिया में प्रवेश करने के बारे में एक ढेर ढलान के शीर्ष पर हैं।

Answer 7

मैं गलतफहमी दूसरों है कि में गिर गए हैं लगता है - प्रश्न बाहरी प्राधिकरण के बारे में था। निजी तौर पर, मैं केवल स्थानीय नेटवर्क पर वितरित प्राधिकरण पर भरोसा करता हूं जहां मेरा प्रमाणीकरण और प्रमाणीकरण सर्वर पर नियंत्रण होता है। मैं किसी वेब साइट पर बाहरी प्राधिकरण का कभी भी उपयोग नहीं करूंगा।

नीचे ओपनआईडी पर प्रमाणीकरण सेवा के रूप में मेरी टिप्पणियां हैं।

1) जैसा कि बताया गया था, प्रमाणीकरण! = प्रमाणीकरण। ओपनआईडी प्रमाणीकरण संभालती है, लेकिन वेब ऐप मालिक के पास अभी भी उस लॉगिन को दिए गए अधिकारों पर पूर्ण नियंत्रण है। यह एक सकारात्मक है, लेकिन इसके बारे में भ्रम एक नकारात्मक है।

2) मुझे लिंक नहीं मिल रहा है, लेकिन ओपनआईडी मध्य/फ़िशिंग हमलों में सामाजिक इंजीनियरिंग/मुख्य के लिए खुला है। प्रदाता इस (आईडी छवियों, ब्राउज़र प्रमाण पत्र, कॉल बैक सत्यापन आदि) को रोकने की कोशिश करते हैं, लेकिन यह मदद नहीं करता है जब ब्लैक टोपी साइट एक संवाद/पृष्ठ को पॉप अप करती है जो कहती है "अपना ओपनआईडी उपयोगकर्ता नाम और पासवर्ड दर्ज करें" और प्रतिभा उपयोगकर्ता का पालन करता है।

3) संघीय आईडी के प्रत्येक प्रदाता के पास उनके उपयोगकर्ताओं की सभी गतिविधियों को ट्रैक करने की क्षमता है (और कुछ जिम्मेदारी कहेंगे), चाहे वे किस साइट का उपयोग करते हैं। यह वह जगह है फ़ेडरेटेड आईडी प्रदान करने के लिए क्यों गूगल और याहू गुंग-हो रहे हैं, लेकिन उपभोक्ता उन्हें के बारे में बहुत उत्साहित नहीं।

4) उपर्युक्त टिप्पणी के विपरीत, आमतौर पर यह मामला है कि ओपनआईडी का उपयोग करके बाधा को पंजीकरण में कम कर दिया जाता है, खासकर जब एक उपयोगी यूआई बताता है कि एक नए उपयोगकर्ता के पास पहले से ही एक ओपनआईडी है। जब आप एक संयुक्त ओपनआईडी/ओएथ समाधान जैसे आरपीएक्स का उपयोग करते हैं तो यह और भी सत्य होता है।

तो, देखने की मेरी बात से, OpenID का उपयोग करके के जोखिम को उपयोगकर्ता, नहीं वेब साइट पर कर रहे हैं। मैं उपयोगकर्ता को अभी तक किसी अन्य उपयोगकर्ता आईडी & पासवर्ड को याद रखने की कोशिश करके फ़िश होने से नहीं रोक सकता। इसके अलावा, ब्लैक हैट को उपयोगकर्ता के अन्य खातों तक पहुंच प्राप्त करने के लिए सादे पाठ में अपनी साइट के लिए स्टोर उपयोगकर्ता पासवर्ड की तुलना में और अधिक घृणित करने की आवश्यकता नहीं है। लॉग इन की हर वेबसाइट के लिए कितने लोग एक अलग पासवर्ड का उपयोग करते हैं?

Answer 8

मेरे लिए व्यक्तिगत रूप से, यह पहली बात है जिसे मैंने बाहरी प्राधिकरण के बारे में कभी सुना है .. तो यह केवल जागरूकता की कमी हो सकती है।

अब Googling ..

Answer 9

के रूप में एक और पोस्टर संकेत दिया, प्राधिकरण आम तौर पर आवेदन विशेष है। आप एक आवेदन में क्या कर सकते हैं जो आप दूसरे में क्या कर सकते हैं उससे महत्वपूर्ण रूप से भिन्न होता है। विशेष रूप से ग्राहक ऑफ-द-शेल्फ अनुप्रयोगों में, प्राधिकरण आमतौर पर आवेदन द्वारा अधिक स्वाभाविक रूप से संभाला जाता है।

प्रदर्शन एक और चिंता है। यह सूर्य के XACML कार्यान्वयन को प्राप्त करके देखा जा सकता है, और इसका उपयोग कुछ प्राधिकरण को बाहरी बनाने के लिए किया जा सकता है। आप अनुरोध के दोनों तरफ नेटवर्क लागत लेते हैं कि (जिस तरह से आप आर्किटेक्ट अनुरोध/प्रतिक्रिया इत्यादि के आधार पर) प्राधिकरण निर्णय की वास्तविक लागत से कहीं अधिक हो सकते हैं। इसे एक सीओटीएस आवेदन में बनाएं, जहां आपके पास प्रदर्शन अनुकूलन के लिए कम स्वतंत्रता है और चीजें और भी बदतर हो जाती हैं।

हालांकि, मुझे लगता है कि होनहार क्षेत्रों में से कुछ नियामक अनुपालन के आसपास हैं। कुछ प्राधिकरण हैं जो आवेदन द्वारा भिन्न नहीं होते हैं। उदाहरण के लिए, स्वामित्व या वर्गीकृत जानकारी या सामग्री का स्थानांतरण। इन मामलों में, प्रत्येक आवेदन में मौजूद एक ही नियंत्रण के लिए एक मजबूत मामला बनाया जा सकता है, क्योंकि बातचीत बहुत खराब है। समान पहुंच नियंत्रण के लिए कई कार्यान्वयन और नियम होने के कारण प्रबंधन दुःस्वप्न है।XACML जैसे नियंत्रण ढांचे के साथ शुरू करने के लिए एक आसान स्थान किसी व्यक्ति को देख सकता है, और उसके बाद कोई भी कर सकता है।

Answer 10

कई कारणों से:

1. प्रदर्शन किया टिप्पणियों में से कुछ के रूप में, वहाँ एक आम धारणा है कि है जिसका मतलब है की फिर से उपयोग से थोड़ा संभावित है कि "प्राधिकरण स्थानीय है" महंगा करने के लिए बनाए रखने के-पर महत्वपूर्ण पहुंच निर्णयों के लिए आवश्यक उच्च गुणवत्ता वाले "विषय विशेषताओं"। (मेरा मानना ​​है कि है कि वहाँ उच्च पुन: उपयोग के संभावित के बाद से कुछ कानून/regs व्यापक रूप से लागू होते हैं, लेकिन इस की पूरी चर्चा इस प्रारूप के लिए बहुत लंबा है।)
2. डेटा बुनियादी सुविधाओं का अभाव: संगठनों के बीच नीति-आधारित अभिगम नियंत्रण लागू करने के लिए (मुझे का उपयोग करते हुए/मेरे डेटा तक पहुँच अनलॉक करने के लिए) की आवश्यकता है, कम से कम कुछ अन्य संगठन के प्राधिकरण ("authz") पर भरोसा डेटा, कि मैं विशेषता का अर्थ विज्ञान (क्या एक "कानून-enforcemment अधिकारी" क्या एक "अमेरिका है समझते हैं नागरिक "।) उसके बाद, गुण गुणवत्ता मानकों और तृतीय पक्ष प्रमाणन को समझना आसान होगा। (कुछ को देख सकते हैं कि इन आवश्यकताओं को PKI अंतर के लिए आवश्यकताओं के अनुरूप हैं: तरीका बताया गया है कि साथ आने वाले और यह बस एक डेटा का एक टुकड़ा, प्लस सामान समर्थन करने के लिए है?।) पर भूमिकाओं/जिम्मेदारियों
3. प्रभाव: externalizing प्राधिकरण, करना है कि क्या " भूमिकाएं "या" विशेषताओं "या" डिजिटल नीति के साथ विशेषता "के लिए, इसका अर्थ है कि स्थानीय" डेटा स्वामी "संसाधन का नियंत्रण खो देता है। वह उपयोगकर्ता सूचियों को बनाए रखने के लिए काफी काम और ज़िम्मेदारी भी ऑफ़लोड करता है। इस तरह के बदलाव से बाहरी एथजेड को तकनीकी समस्या से राजनीति के पक्ष में संगठनात्मक मामले में कार्यान्वित किया जाता है।
4. अधिकांश संगठन नहीं जानते हैं और उनकी नीतियां क्या नहीं लिखी हैं। एक्सेस "जो भी पूछता है" या "जो भी पूछता है और मुझे पसंद है" या "जो भी मुझे कुछ दे सकता है, जैसे उनके डेटा तक पहुंच।" आवेदन किए गए वास्तविक नियम बहुत बदसूरत हो सकते हैं जब उन्हें नीति भाषा में व्यक्त करके खुले में मजबूर किया जाता है। और डिजिटल नीतियों में लिखित नीतियों की अच्छी प्रतिपादन के लिए कौशल सेट पेड़ पर नहीं बढ़ता है, या तो। वास्तव में, कौशल सेट व्यवसाय विश्लेषक या वकील है, आईटी लड़का नहीं है, और उन लोगों के लिए उपकरण मौजूद नहीं हैं।
5. जब आप एक ठोस नीति नियम है, आप की संभावना की खोज करेंगे गुण यह अस्तित्व में नहीं है पर कार्रवाई करने की जरूरत है कि - वे आम तौर पर आप पहले से ही ई में मिल कुछ ऐसी बातें नहीं हैं। फोन नंबर AuthZ विशेषता के रूप में उपयोगी नहीं है, और यहां तक ​​कि "संगठन" शायद अधिकांश कानून या regs के लिए उपयुक्त नहीं है जो आप वास्तव में दस्तावेज़ कर सकते हैं। यह "संभावित कारण" जैसी नीति आवश्यकताओं को व्यक्त करने के लिए आपको कार्य-आसपास और अनुमानों को लागू करने (और अनुमोदित) का भी उल्लेख नहीं कर रहा है।
6. अपेक्षाकृत विनयशील, लेकिन अभी भी असली, कि कई बहुत बड़े पैमाने पर तख्त क्षुधा बाहरी प्राधिकरण का समर्थन नहीं करते, और कई एप्लिकेशन-डेवलपर्स बाह्यीकरण कर करने के लिए इस्तेमाल नहीं कर रहे हैं, और इसलिए होगा (क) आप इससे बाहर बात करने की कोशिश है, या (बी) इसे अपने डाइम पर सीखें, और इसे बुरी तरह से करें।

---

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

गुड लक!