2011-11-02 11 views
6

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

मेरे मन में आता है या तो के लिए है:

  1. मेरी .net आवेदन के लिए अपने ही प्राधिकरण तंत्र और एसक्यूएल टेबल लागू
  2. उपयोग/एक मानक तंत्र, एक सॉफ्टवेयर है कि XACML लागू किया गया है की तरह लागू (उदाहरण के लिए Axiomatics)

पहली विधि के साथ समस्या यह है कि यह केंद्रीकृत नहीं है और न ही मानक है इसलिए अन्य सिस्टम प्राधिकरण के लिए इसका उपयोग नहीं कर सकते हैं।

दूसरे दृष्टिकोण के साथ समस्या यह है कि यह संभावित रूप से धीमी है (प्रत्येक संसाधन के लिए आवश्यक अतिरिक्त कॉल के कारण)। साथ ही मुझे यकीन नहीं है कि भविष्य में एकीकरण को आसान बनाने के लिए एक्सएसीएमएल जैसे मानक प्रमाणीकरण बाजार में अनुप्रयोगों द्वारा समर्थित है।

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

+0

क्या एक्सेस अनुमतियां नीतियों (एक सामान्य नियम जो कई परिस्थितियों को शामिल करती हैं) के रूप में व्यक्त की जा सकती हैं या उपयोगकर्ताओं द्वारा किए गए साझाकरण निर्णयों को एक दूसरे के बीच और मूल रूप से मनमाने ढंग से कर सकते हैं? – kgilpin

+0

@kgilpin: एक्सेस अनुमतियां सामान्य और विशिष्ट दोनों हो सकती हैं। "केवल समूह ए में चालान पढ़ सकते हैं" और विशिष्ट "उपयोगकर्ता एक्स ने खाता अल्फा तक पहुंच पढ़ी है" के रूप में सामान्य। – kaptan

+0

मुझे लगता है कि इन दिनों कुछ भ्रम है कि वास्तव में भूमिका-आधारित पहुंच नियंत्रण (आरबीएसी) क्या है। इसकी औपचारिक कल्पना में, आरबीएसी आपकी इच्छाओं को करने में बहुत सक्षम है। आपने दो भूमिकाओं का वर्णन किया है: "चालान पाठक" और "खाता अल्फा के पाठक"। आपके पास नीचे दो जवाब हैं जो विशेषता-आधारित अभिगम नियंत्रण के विक्रेताओं से हैं, लेकिन ऊपर वर्णित नियमों में मुझे विशेषता-आधारित विशेषता नहीं है। एक धारणा है कि "आरबीएसी ऐसा नहीं कर सकता", क्योंकि लोग आरबीएसी की औपचारिकता को आरबीएसी के कुछ कमजोर कार्यान्वयन के साथ भ्रमित करते हैं। – kgilpin

उत्तर

8

मैं निश्चित रूप से बाहरी प्राधिकरण के लिए जाना होगा। इसका मतलब यह धीमा नहीं होगा। इसका मतलब है कि आपने व्यवसाय तर्क से स्पष्ट रूप से एक्सेस नियंत्रण को अलग कर दिया है।

अवलोकन XACML जाने का एक अच्छा तरीका है। टीसी बहुत सक्रिय है और बोइंग, ईएमसी, वयोवृद्ध प्रशासन, ओरेकल और एक्सामैटिक्स जैसी कंपनियां सभी सक्रिय सदस्य हैं।

एक्सएसीएमएल आर्किटेक्चर गारंटी देता है कि आप जो प्रदर्शन चाहते हैं उसे प्राप्त कर सकते हैं। चूंकि प्रवर्तन (पीईपी) और निर्णय इंजन (पीडीपी) कम से कम युग्मित होते हैं, आप चुन सकते हैं कि वे कैसे संवाद करते हैं, वे किस प्रोटोकॉल का उपयोग करते हैं, चाहे कई निर्णयों का उपयोग करें, आदि ... इसका मतलब है कि आपके पास एकीकरण के लिए जाने का विकल्प है आपकी प्रदर्शन आवश्यकताओं को फिट बैठता है।

XACML के लिए SAML प्रोफ़ाइल में परिभाषित एक मानक पीडीपी इंटरफ़ेस भी है। यह आपको 'भविष्य-सबूत' पहुंच नियंत्रण की गारंटी देता है जहां आप किसी विशेष विक्रेता समाधान में बंद नहीं होते हैं। webapps के लिए

अभिगम नियंत्रण आप बस ISAPI और ASP.NET में HTTP फिल्टर का उपयोग करके नेट webapps के लिए एक पीईपी में छोड़ सकते हैं। इसके लिए एक्साइमेटिक्स को एक ऑफ-द-शेल्फ मिला है।

वर्तमान कार्यान्वयन आप axiomatics के ग्राहकों पेज की जाँच हैं, तो आप वे Paypal, बेल हेलीकाप्टर, और अधिक है देखेंगे। तो एक्सएसीएमएल वास्तव में एक वास्तविकता है और यह बहुत बड़ी तैनाती से निपट सकता है (लाखों उपयोगकर्ताओं)।

इसके अलावा, एक अग्रणी वित्तीय सेवा प्रदाता डेटव ईजी अपनी सेवाओं/ऐप्स के लिए एक्सीमैटिक्स के .NET पीडीपी कार्यान्वयन का उपयोग कर रहा है। चूंकि नेट पीडीपी उस मामले में एम्बेडेड है, प्रदर्शन इष्टतम है।

अन्यथा, आप हमेशा ऑफ-द-शेल्फ पीईपी से चुन सकते हैं। किसी भी पीडीपी के साथ एकीकरण - उदाहरण के लिए एक एसओएपी-आधारित XACML प्रमाणीकरण सेवा।

XACML गार्टनर "उत्प्रेरक" सम्मेलन में पिछली जुलाई के साथ प्रदर्शन के उच्च स्तर, axiomatics अपने नवीनतम उत्पाद की रिहाई की घोषणा की, axiomatics रिवर्स क्वेरी जो आपकी मदद करता है 'अरब रिकॉर्ड चुनौती' से निपटने। यह डेटा स्रोतों के साथ-साथ आरआईए के लिए अभिगम नियंत्रण को लक्षित करता है। यह एक शुद्ध XACML समाधान का उपयोग करता है ताकि यह अन्य समाधानों के साथ अंतःक्रियाशील रहे।

तथ्य की बात के रूप में, Kuppinger कोल बहुत जल्द ही विषय पर एक वेबिनार की मेजबानी करेगा: http://www.kuppingercole.com/events/n10058

axiomatics ARQ प्रेस विज्ञप्ति भी यहाँ की जाँच करें: http://www.axiomatics.com/latest-news/216-axiomatics-releases-new-reverse-query-authorization-product-a-breakthrough-innovation-for-authorization-services.html

3

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

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

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

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