نحن نقدم إدارة الهوية. عرض من مهندس التنفيذ

تحدثنا في وقت سابق عن ماهية إدارة الهوية ، والسبب وراء الحاجة إليها ، وكيفية إثبات تنفيذها ماليًا ، وما إلى ذلك. اليوم سوف نتحدث عن المخاطر التي يمكن أن تنشأ أثناء تنفيذ النظام ، وكيفية الالتفاف عليها وعدم الحصول على نفسك الكثير من المخاريط. افترض أننا نعلم أنه في شركتنا هناك بعض المشكلات التي يمكن أن نرغب في حلها باستخدام IdM. إن حل هذه المشكلات في شركتنا له ما يبرره اقتصاديًا ، لأنه سيخفف بشكل كبير من قسم تكنولوجيا المعلومات ، ويزيد من مؤشرات أداء الشركة ككل من خلال توفير الوقت والموارد اللازمة لإعداد مساحة العمل للموظفين الجدد ، وتنسيق وإدارة القوى القديمة. وسيكون موظفو IS بعد تنفيذ IdM في الجنة السابعة ، مما يولد الكثير من التقارير المتنوعة على الزر ، والتي تعمل على تبسيط حياتهم إلى حد كبير عند إجراء عمليات تدقيق الأمان ، مما يسعدهم أنفسهم والإدارة. واتخذ القرار - "خذ!".

نحن صياغة المتطلبات الوظيفية

أول ما يجب فعله هو إعداد مستند يسمى "المتطلبات الوظيفية". أعتقد أن أهمية توافر ومحو الأمية لمحتويات هذه الوثيقة أمر لا ريب فيه. من الناحية المثالية ، يجب أن يكون مستعدًا قبل اختيار حل معين. من الواضح أنه خلال الاختبار التجريبي وخلال أحداث ما قبل البيع عدة مرات ، تمت مناقشة أشخاص مختلفين وشرح ما يجب القيام به. ومع ذلك ، ينبغي تحديد نطاق المشروع بوضوح وثباته على الورق. المتطلبات الوظيفية هي نوع من نقطة الانطلاق التي سيتم بناء التفاهم المتبادل بين جميع المشاركين في العملية سواء من جانب العميل والمقاول.

يجب أن تكون وظيفة النظام المطلوبة مبررة منطقيا وماليا وتنفيذها ومتسقة مع قدراتها. هذا هو في الأساس وصف عالي المستوى لعمليات الأعمال التي تحتاج إلى أتمتة باستخدام تطبيق IdM.

النظر في مثال بسيط لوضوح. تخيل أنك تحتاج إلى أتمتة عمليات الموظفين التالية:

• قبول موظف جديد (إنشاء حسابات لها حقوق أساسية ، حسب المنصب والوحدة).
• طلب أوراق اعتماد جديدة للموظفين (التنسيق والتنفيذ التلقائي وشبه التلقائي للتطبيقات).
• نقل موظف إلى وظيفة (إصدار صلاحيات مقابلة لوظيفة جديدة أو تأكيد أو إلغاء صلاحيات قديمة)
• إقالة الموظف (حجب جميع حساباته مع التذكير بجميع الأدوار).

في المتطلبات الوظيفية لعملية قبول الموظف الجديد ، يجدر كتابة ما يلي: يقوم النظام بقراءة المعلومات حول الموظف الجديد من نظام الموظفين ، وإنشاء حساب في Active Directory (AD) ، وتعيين المجموعات اللازمة حسب الموقف ، وإنشاء حساب في CRM ، وتعيين ملف تعريف وأدوار وفقا للواجبات الرسمية.

ليست هناك حاجة للدخول إلى هناك شرط تحضير القهوة إلى المدير التنفيذي عند دخوله المكتب. هذه ليست ميزة IdM ، على الرغم من وجود واجهة برمجة التطبيقات (API) ، فإن أداة صنع القهوة قابلة للتحقيق أيضًا :)

نرسم رسم تخطيطي لتفاعل مكونات النظام

في هذه المرحلة ، بالإضافة إلى العمليات المؤتمتة فعليًا ، يتم تحديد الأنظمة الرئيسية القابلة للتكامل ، وتحديد الإدارات المعنية ، وتقدير مكان إدارة الهوية العالمي في بيئة المعلومات الداخلية للمشروع. يتم أيضًا تحديد الموارد اللازمة لدعم إدارة الهوية ، ويصبح نطاق المشروع مرئيًا ، ويتم تحديد مراحل وتواريخ التنفيذ تقريبًا.

لذلك ، أدركنا أنه لتنفيذ هذه العمليات الآلية في المرحلة الأولى ، تحتاج إلى الاندماج مع ثلاثة أنظمة فقط:

• مع نظام الموظفين 1C: ZUP ،
• مع Microsoft Active Directory كموفر أساسي لامتيازات المستخدم في البنية التحتية للمؤسسة ،
• باستخدام نظام أعمال CRM الرئيسي الذي تمت كتابته وصيانته بواسطة بائع طرف ثالث بموجب الطلب.

تحتاج إلى أن تتخيل على الفور مخطط تفاعل مكونات النظام المستقبلي.

كما ترون ، IdM في المركز ، وهذا ليس مصادفة. بعد التنفيذ ، ستكون IdM هي "alpha و omega" التي تحتوي على جميع المعلومات ذات الصلة حول موظفي الشركة ، وجميع حساباتهم في الأنظمة المتكاملة لـ IdM والأدوار والمجموعات والسلطات التي ينبغي أن يتمتع بها موظفو هذه الأنظمة. بفضل "مخالب" IdM التي تخترق جميع الأنظمة المرتبطة بها ، فإن نقل Ivanov Sergey Petrovich من قسم المحاسبة إلى القسم القانوني للشركة الذي يتم تسجيله تلقائيًا في نظام معلومات الموظفين سيغير تلقائيًا المجموعات والسمات الخاصة بحسابه في AD ويغير أدواره وملفاته الشخصية في أنظمة الشركة الأخرى ، مع الإطلاق التلقائي لجميع عمليات الموافقة والإخطار اللازمة. ولكن كل هذا لن ينجح إلا عندما تكون جميع مكونات النظام متكاملة بشكل صحيح وصحيح مع بعضها البعض. ولكي يحدث هذا ، أكرر ، تحتاج إلى التفكير بعناية وتصميم كل شيء.

مع هذه الأمتعة نذهب لشراء.

لذلك ، يتم تحديد الحل IdM ، يتم تعريف المقاول المنفذ ، يتم شراء التراخيص ، يتم دفع العمل ، لقد حان الوقت لتنفيذه. سنتحدث أكثر عن كيفية التأكد من أن جميع الأعمال الجيدة لا تموت ، دون أن تولد حقًا.

نقوم بإنشاء فريق مشروع وإجراء مسح ما قبل المشروع

أول شيء يجب القيام به مباشرة بعد شراء IdM (دون حساب الزيادة الرسمية للزجاج للصفقة) هو إنشاء فريق مشروع. نعم ، يجب أن يكون فريق المشروع من جانب العميل . يعتمد نجاح الحدث بأكمله على تكوينه. ينبغي أن يشمل ممثلين عن جميع الإدارات المهتمة التي لديها الصلاحيات اللازمة والكافية لحل المشكلات المختلفة ذات الطبيعة التقنية التي تنشأ أثناء التنفيذ بسرعة.

يأتي بعد ذلك وقت الاستقصاء المسبق للتصميم - المرحلة الأكثر أهمية ، التي تتطلب غمرًا كبيرًا في أنشطة التصميم من العميل بشكل أساسي.

هنا ، ستكون هناك حاجة إلى الصلاحيات الضرورية والكافية للمشاركين في فريق مشروع العميل لجمع وتزويد المقاول بجميع المعلومات اللازمة حول الهيكل الداخلي لعمليات الشركة. إنه يتعلق بالهيكل الداخلي لعمليات الشركة! كل عملية تلقائية موصوفة في المتطلبات الوظيفية تحتاج إلى التحقيق فيها بدقة من البداية إلى النهاية. من الذي ينفذ المجموعة الأولية للمعلومات ، وتكوينها وتنسيقها ، وفي أي نظام يتم إدخال المعلومات ، والتي يتم إرسالها فيها ، وكيف ، عن طريق البروتوكولات ، باستخدام أي برنامج؟ من الذي يحتاج إلى هذه المعلومات لمزيد من الأنشطة ، وفي أي شكل يحتاج إليها ، حيث ينبغي أن يكون هناك آثار للعمليات المنجزة ... باختصار ، كل شيء ، كل شيء ، كل ما يهم كل عملية تم التحقيق فيها.

نكتب المعارف التقليدية

عند إخراج الدراسة الاستقصائية لما قبل المشروع ، يجب الحصول على وثيقة واحدة أكثر أهمية من وجهة نظر التنفيذ (أكثر أهمية من المتطلبات الوظيفية) - الشروط المرجعية (TOR). ما ينبغي أن يكون في ذلك؟ من المهم عدم تفويت أي شيء والتفكير بعناية في كل شيء. لأن إغفال الفروق الدقيقة الصغيرة والتي تبدو ضئيلة الأهمية يمكن أن يؤدي إلى مشاكل كبيرة أثناء التنفيذ.

في هذا الصدد ، عند تصميم حل للتنفيذ في المعارف التقليدية ، فإن أول ما يجب فعله هو العمل بدقة على العمليات الآلية نفسها. كما هو الحال تقريبًا كما هو الحال في المتطلبات الوظيفية ، ولكن بمزيد من التفصيل ، مع التفاصيل ، والتي تغطي دورة حياة كاملة من المعلومات الواردة في إدخال كل عملية حتى يخرج.

على سبيل المثال ، عملية الموظفين ، سيبدو قبول موظف جديد في ToR كما يلي:

1. يقوم موظف موارد بشرية بإدخال معلومات حول موظف جديد في نظام 1C: ZUP HR. يملأ إلزامي في الحقول التالية: ... (يتم سرد أي منها).
2. تتلقى IdM بيانات حول موظف جديد من نظام شؤون الموظفين 1C: ZUP ، وتحدد موقف ووحدة الموظف الجديد. إنشاء ملف تعريف موظف جديد في IdM. يتم تشكيل تسجيل الدخول وفقا لهذه القواعد وهذه ، كلمة المرور وفقا لهذا وكذا. يتم إرسال معلومات تسجيل الدخول الخاصة بكلمة مرور الموظف الجديد إلى هناك وهناك عبر قنوات الاتصال هذه (يرجى الإشارة إلى أين تحصل إدارة الهوية على العنوان).
3. تقوم IdM تلقائيًا بإنشاء حساب في AD مع السمات (القائمة) في الدليل (OU - Organization Unit) المقابلة لوحدة الموظف الجديد. يتم تشكيل تسجيل الدخول وفقا لهذه القواعد وهذه ، كلمة المرور وفقا لهذا وكذا. يتم إرسال البيانات الخاصة بتسجيل الدخول وكلمة المرور للموظف الجديد إلى هناك وهناك عبر قنوات الاتصال هذه (يرجى الإشارة إلى أين يحصل IdM على المرسل إليه ومن معلمات قناة الاتصال).
4. يتم وضع حساب AD الذي تم إنشاؤه في مجموعات (نقوم بإدراج أو الإشارة إلى "وفقًا لنموذج الدور"). سيحتاج نموذج الدور أيضًا إلى التفكير فيه ووصفه في "الشروط المرجعية" في فصل منفصل. يتم تعيين مثل هذه المجموعات بالاتفاق مع هؤلاء الأشخاص (ندرجها). يولد النظام إخطارات بشأن تعيين السلطة للموظف الجديد (حدد خوارزمية تحديد هوية المستلم ؛ صف بشكل منفصل طرق الموافقة) ، بالإضافة إلى تذكيرات للمنسق حول الحاجة إلى تنسيق التطبيق (حدد خوارزميات تحديد المستلم ، وبدء ، ونهاية وتكرار التذكيرات).
5. بعد إنشاء حساب في AD ، يبدأ IdM في إنشاء صندوق بريد Exchange للموظف الجديد. يتم تخزين المعلومات حول صندوق البريد الجديد في IdM وعرضها على بطاقة الموظف.

في نفس السياق تقريبًا ، نصف تفاعل النظام مع CRM ...

وبالتالي ، أثناء النظر في العمليات الآلية بهذه الطريقة ، يصبح نموذج الكائن لكل نظام ، تكوين سمات كل نوع من الكائنات واضحًا ، ويتم تشكيل صورة لحركة البيانات وتحويلها بين سمات الكائنات المختلفة. أيضًا ، تصبح الاتصالات بين الكائنات مرئية ، ويتم الكشف عن عمليات إضافية ، مثل الحفاظ على تناسق البيانات في جميع الأنظمة.

مثال بسيط: عند تغيير اسم الموظف في نظام الموظفين ، يجب أن يتغير اسمه في ملفات التعريف الخاصة بجميع الأنظمة الأخرى المتصلة بـ IdM. لكنه قد لا يتغير ، لأنه في بعض الأنظمة لا يتم تخزين الاسم ببساطة.

مثال أكثر تعقيدًا: الشرط هو أنه يجب إنشاء حساب AD للموظف الجديد في الوحدة التنظيمية المقابلة لوحدته. السؤال الذي يطرح نفسه ، ماذا تفعل إذا تم إنشاء وحدة جديدة في نظام الموظفين ، ولكن لم يتم إنشاؤها في م؟ وبالتالي ، تم الكشف عن عملية منفصلة لإعادة إنتاج الهيكل التنظيمي المخزنة في نظام الموظفين في م ، والتي تستحق أيضًا وصفها في الشروط المرجعية.

يتكامل مع النظم

كما ترون ، فإن تكوين المعارف التقليدية عملية تكرارية. بعد تحديد الكائنات والإجراءات التي يتعين تنفيذها معها ، يصبح من الواضح مجموعة الوظائف التي يجب تنفيذها في الموصل للنظام المتكامل. وهنا اقتربنا بسلاسة من مرحلة هامة أخرى من مراحل تنفيذ إدارة الهوية - التكامل الفعلي مع الأنظمة . في الحقيقة ، يمكن أن تكون هذه المرحلة مؤلمة للغاية لكل من شركة IdM Integrator والشركة التي يتم تنفيذ IdM في بنيتها التحتية.

حتى لا يحدث أي شيء سيء ، تحتاج إلى فهم بعض المبادئ العامة التي تنطبق عند دمج منتجات البرامج المختلفة. أولاً ، يجب أن تفهم أهمية وجود واجهة برمجة التطبيقات (API) في نظام متكامل للتكامل مع IdM. الموصل و API هما شيئان مختلفان. إذا قال تكامله أن لديه موصلات لأنظمة مختلفة أو أنه مستعد لكتابة موصل لأي نظام ، فإن هذا لا يعني أن مشكلة التكامل قد تم حلها بالكامل وأن الشركة العميلة لا تحتاج إلى القيام بأي شيء حيال ذلك.

سأشرح مع مثال. من أجل توصيل محطة كهرباء بالحديد من أجل تسخين الأخير من أجل القيام بوظائفها المعروفة ، من الضروري أن تحتوي محطة الطاقة على مقبس والمكواة. المقبس والمكونات. 2 أشياء. ليس واحد. باستخدام منفذ على جانب محطة الطاقة ومكونات على جانب الحديد ، يتم دمج المكواة مع نظام الطاقة. في حالة تكامل IdM مع أي نظام آخر ، هناك حاجة أيضًا إلى أمرين: موصل على جانب IdM وواجهة برمجة التطبيقات من جانب النظام. هذا مهم! خلاف ذلك ، قد تحدث حوادث غير سارة مختلفة. الغرض من الموصل هو فقط استلام البيانات الضرورية من النظام بالشكل الذي يرسلها بها ، ونقلها إلى IdM بالشكل الذي يمكن لـ IdM استلامها به. يعمل الموصل نفسه في الاتجاه المعاكس: يتلقى أمرًا ومجموعة بيانات من IdM بالشكل الذي يصدر به IdM ، وينقل كل هذا إلى النظام بالشكل الذي يفهم فيه النظام ما يحتاج إلى فعله. لكن! يجب أن يكون النظام ، من حيث المبدأ ، قادرًا على إنتاج البيانات اللازمة لإدارة الهوية وتنفيذ الأوامر اللازمة للعمل جنبًا إلى جنب مع إدارة الهوية. هذا هو الغرض الرئيسي من واجهة برمجة التطبيقات - لتوفير واجهة يمكن لـ IdM التعامل معها باستخدام موصل لأداء عمليات متنوعة على النظام.

عادة ، حتى قبل بيع IdM ، يركز تكامل الضميري على حاجة العميل إلى توفير API لجميع الأنظمة المتصلة بـ IdM ومتطلبات التقارير لتنفيذ واجهات برمجة التطبيقات هذه. هذا هو في الأساس تعداد وظائف مع معلمات المدخلات والمخرجات. على سبيل المثال:

• البحث عن جميع حسابات النظام. لا توجد معلمات الإدخال. الإخراج هو قائمة بجميع الحسابات مع كل سماتها.
• ابحث عن حساب بمعرف. معلمة الإدخال هي معرف الموجات فوق الصوتية. تسجيل الخروج - حساب يلبي معايير البحث ، مع جميع السمات.
• انشاء حساب معلمات الإدخال - تسجيل الدخول ، كلمة المرور ، الاسم الكامل ... خروج - معرف الموجات فوق الصوتية الجديدة.
• قفل الحساب. معلمات الإدخال - معرف الموجات فوق الصوتية. لا توجد معلمات الإخراج.
• وهلم جرا ...

أي أن API هي مجموعة من الوظائف اللازمة للتفاعل مع IdM. المشكلة هي أنه قد لا يتم تنفيذ جزء من هذه الوظائف في النظام بالشكل الصحيح على الإطلاق. فقط لأن هذا لم يكن ضروريا بعد. يمكن تنفيذ جزء منه ، ولكن كعملية معقدة متعددة المستويات خطوة بخطوة. على سبيل المثال ، في نظام آلي مصرفي محلي واحد ، يسبق إنشاء حساب مستخدم عن طريق ملء ثلاثة أدلة مختلفة مع مجموعة من السمات والعلامات المساعدة. أو ، يمكن تنفيذ بعض الوظائف بشكل بسيط ، ولكن لا يمكن نشرها ، أي أنه لا يمكن استخدام الدوال من الخارج. لذلك تم تصميم API لحل جميع هذه المشاكل. واجهات برمجة التطبيقات (APIs) هي وظائف تؤدي العمليات اللازمة لدمج نظام متكامل مع IdM ، في النموذج الصحيح والعمل الصحيح ، الذي تم نشره من أجل مكالماتهم الخارجية. حتى يتمكن أي مهندس برمجيات لا يعرف المطبخ الداخلي للنظام نفسه من استخدامها والقيام بسهولة بما هو مطلوب.

بعد ذلك ، كقاعدة عامة ، يطرح السؤال للعملاء ، والذي يتسبب في ألم في الأسنان مزعج لمهندس تنفيذ IdM: لماذا لا يمكن لمكامل واجهة برمجة التطبيقات أن يقوم بتنفيذ مُدمج IdM على النظام؟

تخيل نظامًا معقدًا لإدارة المؤسسة والذي يجب الآن تطبيق إدارة حقوق المستخدم باستخدام IdM. كتب البائع هذا النظام منذ التسعينيات. على مدى حياة طويلة ، تغيرت الهندسة المعمارية أربع مرات. لم يستطع النظام الفرعي لإدارة حقوق المستخدم مواكبة التطور السريع لوظيفة النظام نفسه وتم تنفيذه من قبل عدة أجيال من المبرمجين وفقًا لفهمهم المنطقي وغير المنطقي دائمًا وفقًا لمبدأ "كيف أحسبته بنفسي" ، أي بطريقة عكوسة. ليست هناك حاجة للحديث عن توثيق كل هذا الإجراء. في الوقت الحالي ، كل شيء يعمل بطريقة ما. يصعد موظفو البائع إلى الكود القديم لنظامهم بتردد وفزع فقط في حالة الحاجة الملحة لتصحيح بعض الأخطاء الفظيعة ، وتعميد ثلاث مرات ورش الشاشة بالماء المقدس ، ومغطاة بالدفوف ، لذلك لا سمح الله عدم كسر أي عكاز ، حتى لا يسقط كل شيء. .



والآن ، أصبحت الشركة العميلة التي تستخدم هذا المنتج السحري هي الوقت الذهبي لتنفيذ IdM. متطلبات API المقدمة ، لا API. لا يهتم العميل بمن سيكتب واجهة برمجة التطبيقات. خبط بقبضته على الطاولة بعبارة "أنا أبكي ملايين ضخمة ، أفعل ذلك" وغادر الاجتماع ، أغلق الباب عن عمد. بائع البرامج السحرية أيضا لا يهمني. لن يفعل أي شيء مجانًا ، لكنهم نسوا وضع أموال في الميزانية لتنفيذ API لأحلام قوس قزح حية حول كيف سيكون كل شيء رائعًا بعد تقديم IdM. في الوقت نفسه ، تم توقيع العقد ، "تم دفع المال" ، ويبدأ القفز السريع.

يحاول Poor Pasha-programmer ، الموظف في شركة IdM ، تكامل المفهوم الذي يجب فعله للحصول على ردود فعل طبيعية من النظام. إنه يدرس المصادر العامة ، وثائق شحيحة ، عفا عليها الزمن ، ويفهم الكود المصدري لنظام مجهول ويقطع هواتف البائع. بعد أسبوعين من المحن ، يدرك أن القرفصاء ليست كافية ، والارتداد مطلوب ، وحتى التخبط ، وليس حقيقة أن هذا سيساعد أيضًا ... وبعد شهر ، يظهر موصل ، نوع من العمل ، أكثر أو أقل من العمل. أعطال طفيفة ، حسنا ، كيف حدث ذلك. تحولت ضعيف باشا مبرمج على موظفي تكامل رمادي أثناء كتابته. تم دمج النظام السحري ، ولكن المشكلة هي أنه لم يتم إنشاء الحسابات بشكل صحيح ، ويجب على مسؤول النظام "إعادة" الحساب يدويًا إلى حالة العمل. تتغير كلمات المرور مرة أخرى ، وتحتفظ مارينا إيفانوفنا "المحظوظة" بالحساب الذي يمنع حسابها. يغمر موظفو شركة "الأعمال" الدعم الفني بشكاوى مفرغة: "إلى متى ؟؟؟" ، "من المستحيل العمل!" ، "افعل كما كان ..." في البداية ، يطلب العميل إصلاح كل شيء ويضرب الطاولة بشبشب حتى يصل إلى مبرمج باشا الأصلع. بعد ذلك ، وبسبب الإخفاقات المتكررة والاستياء المتزايد بين وحدات الأعمال ، يتم إيقاف تكامل IdM مع النظام السحري.

وماذا ستفعل هنا؟ على من يقع اللوم؟ إذا لم يكن بائع النظام ، فمن ذا الذي ينبغي عليه فرز كل الفوضى التي قام بها من الدلائل والوظائف واللوحات والمشغلات والأعلام والعكازات؟ إدارة الهوية المتكاملة؟ كيف يعرف كيفية تنفيذ وظيفة بشكل صحيح في نظام لا يستطيع البائع اكتشافه؟ وإذا كان ذلك ممكنا ، ثم لبعض المال الكبير؟ نعم ، أنا سميك جداً لوني الآن ؛ هناك استثناءات عندما يكون النظام غير معقد للغاية ، ويمكنك الاندماج معه دون واجهة برمجة تطبيقات خاصة. لكن كن معقولاً. إذا كان الهدف هو تجنب المشكلات غير الضرورية ، ساعد الأعمال على النمو وتحقيق ربح (والذي ، في رأيي ، هو الهدف الرئيسي لقسم تكنولوجيا المعلومات في أي شركة) والتمتع بالتشغيل السلس لجميع الأنظمة ، فكر في طرق للتكامل مع الأنظمة. ضع في الميزانية التكاليف اللازمة لدراسة فرص التكامل والتنفيذ الفعال للمكونات المفقودة. يدفع الجشع مرتين ، أو حتى ثلاث مرات. حفظ في النهاية باشا مبرمج: D. انه تقريبا أصلع. ولا تنسَ إصلاح طرق الاندماج في المعارف التقليدية!

نحن نبني نموذجا يحتذى به للشركة

أود أيضًا أن أوجه انتباهًا خاصًا إلى تشكيل نموذج الشركة . والحقيقة هي أن كل نظام لديه مجموعة حصرية خاصة به من الكيانات "موثوقة" - الكائنات التي توفر امتيازات المستخدم في النظام. يمكن تعيين جميع أنواع المجموعات والأدوار والملفات التعريفية والأغراض والدلائل والامتيازات وأنواع العمليات وما إلى ذلك إلى هذه الفئة من الكائنات ... يمكن أن يكون تحبيب الحقوق عميقًا جدًا ، ونتيجة لذلك نحصل على عدد ضخم للغاية من الكائنات المدارة. على سبيل المثال ، يمكن أن تكون بعض مجموعات الأمان في م عدة مئات أو حتى الآلاف. في بعض أنظمة الإدارة المالية ، يمكن منح كل مستخدم حقوقًا حصرية لكل حساب من أصل مليون موجود في مخطط الحسابات. وإذا كنا ندمج مع SAP؟ يمكن قياس عدد الحقوق الذرية بمئات الآلاف وحتى الملايين.

بالإضافة إلى ذلك ، يمكن للنظام دعم التداخل الهرمي والعلاقات المعقدة بين أنواع مختلفة من الكيانات المعتمدة. هذا في حد ذاته يعتمد على دراسة منفصلة لإمكانيات إدارة حقوق المستخدم في النظام.لذلك ، قبل تصميم تطبيق IdM في منزلك ، من الضروري ، استنادًا إلى أهداف المشروع ، تحديد الحقوق وعلى أي مستوى من الدقة ستديرها من خلال IdM. الشيء الرئيسي هو التوقف في الوقت المناسب. كل شيء يجب أن يكون ضروريا وكافيا. إذا كنت ترغب في إدارة حقوق مستخدم منفصلة لكل حساب في النظام ، فاستعد للمقدار المناسب من العمل لتنسيق وسحب حقوق المستخدم مع كل تغيير في مخطط الحسابات.

عند العمل على نموذج يحتذى به ، يجب عليك تحديد:

• من أين تأتي كائنات حقوق الوصول في IdM ، أي الأدوار نفسها. في معظم الأحيان ، يتم تحميلها من الأنظمة المدارة في المراحل الأولية للتكامل.
• . IdM , « ».
• . .

, , . , : , , . : – 50% . , , , . IdM, .

. .

, Solar inRights