सेवा खाते

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

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

1. ओपन प्लेटफॉर्म → एक्सेस और सुरक्षा → एक्सेस → सेवा खाते (उपयोगकर्ताओं के बगल में) पर जाएं और नया सेवा खाता चुनें।
2. इसे एक ऐसा पता दें जो यह बताए कि यह किस लिए है (nightly-export@service.yourcompany), एक नाम दें और एक वाक्य में बताएं कि यह क्या करता है।
3. इसकी भूमिकाओं पर निशान लगाएँ। इसे वह सबसे सीमित भूमिका दें जो काम को पूरा करती हो: केवल परचेज़ ऑर्डर प्रदर्शित करने वाली भूमिका का मतलब है एक ऐसी कुंजी जो केवल परचेज़ ऑर्डर पढ़ सकती है और कुछ नहीं।
4. आप चाहें तो इसे पतों तक सीमित कर सकते हैं (जैसे कि एक आईपी या एक आईपीवी4 रेंज जैसे 203.0.113.0/24), इसके टोकन की समय सीमा कम कर सकते हैं या इसे एक समाप्ति तिथि दे सकते हैं।
5. इसे बनाएं। गुप्त कोड केवल एक बार दिखाया जाता है — इसे उस प्रोग्राम में कॉपी करें जो इसका उपयोग करेगा। यह केवल फिंगरप्रिंट के रूप में संग्रहीत होता है और इसे वापस पढ़ा नहीं जा सकता।

यह प्रोग्राम गुप्त जानकारी को कुछ मिनटों तक वैध रहने वाले टोकन के बदले में देता है, और अन्य सभी बियरर टोकन की तरह ही हर कॉल पर टोकन भेजता है:

POST /api/auth/service-token
{ "client_id": "nightly-export@service.yourcompany", "secret": "txs_…" }

→ { "token": "…", "expires_in": 3600, "companies": [ … ] }

GET /api/scm/purchase-orders
Authorization: Bearer <token>
X-Company: <company id>

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

सहायता डेस्क का खाता

प्रत्येक डिप्लॉयमेंट में एक सर्विस अकाउंट होता है जिसे बनाने की आवश्यकता नहीं होती: support-desk@service.tranxact। यह डिप्लॉयमेंट द्वारा स्वयं ही एक गुप्त आईडी से प्रोविज़न किया जाता है जिसे डिप्लॉयमेंट इंस्टॉल करते समय वेंडर द्वारा सेट किया जाता है, इसलिए आपकी कंपनी में किसी को भी आपके टिकटों का उत्तर देने के लिए कुछ भी जारी करने की आवश्यकता नहीं है। यह प्रत्येक कंपनी में सपोर्ट डेस्क की भूमिका निभाता है, जो सपोर्ट टिकटों और उनके अटैचमेंट्स को पढ़ता और उनका उत्तर देता है - और कोई मॉड्यूल या अन्य स्क्रीन नहीं खोलता है। इसे "डिप्लॉयमेंट द्वारा सेट किया गया" के रूप में सूचीबद्ध किया गया है; इसे रद्द करना आपका निर्णय है और डिप्लॉयमेंट इसे ओवररूल नहीं करेगा।