چه زمانی این همکاری مفید است
وقتی بنیان ابری گسترش می‌یابد یا احراز هویت مشتری‌رو تغییر می‌کند، هویت وابستگی حیاتی می‌شود. یکپارچه‌سازی شکننده، امتیاز گسترده و سفرهای مستندنشده تغییر ساده پلتفرم را پرریسک می‌کنند.
تصمیم‌ها پیش از اجرا
دسترسی نیروی کار را از هویت مشتری/شریک جدا می‌کنیم، فدراسیون و claimها را بازبینی و مرز محیط و دسترسی امتیازدار را تعریف می‌کنیم. نوسازی هویت خارجی به تحلیل سازگاری نیاز دارد، نه فرض برابری ویژگی بین پلتفرم‌ها.
معماری در بستر تصمیم
معماری مفهومی برای مرزهای تصمیم؛ محیط مشتری را نشان نمی‌دهد.
آنچه دریافت می‌کنید
- فهرست یکپارچه‌سازی هویت/کاربرد
- طراحی دسترسی، فدراسیون و claim هدف
- ملاحظات مهاجرت/هم‌زیستی و بازگشت
- مدل اتوماسیون محیط و مسئولیت عملیاتی
نحوه کنترل تحویل
- 01کاربردها، ارائه‌دهنده هویت و سفر کاربر را ترسیم کنید.
- 02الزامات احراز هویت و دسترسی هدف را تعریف کنید.
- 03یکپارچه‌سازی‌های نماینده و موارد حاشیه را بیازمایید.
- 04مهاجرت را با مالکان کاربرد و پشتیبانی توالی دهید.
- 05پایش، بازیابی و مدیریت دسترسی را اعتبارسنجی کنید.
مرزها و مبادلات
قابلیت محصول و گزینه مهاجرت تغییر می‌کند. راهنمای فعلی Microsoft و ارائه‌دهنده را برای سناریوی واقعی بررسی می‌کنیم؛ تغییر نام tenant یا کپی رابط، سفر کاربر، سیاست سفارشی و وابستگی کاربرد را مهاجرت نمی‌دهد.
پرسش‌ها و پاسخ‌ها
نوسازی هویت را چگونه طراحی و مرحله‌بندی کنیم؟
یکپارچه‌سازی هویت نیروی کار و کاربر خارجی، مرز دسترسی و توالی مهاجرت را حول کاربردهایی که محافظت می‌کنند طراحی کنید.
#تیم ما در زمان تحویل چه انتظاری داشته باشد؟
تحویل شامل فهرست یکپارچه‌سازی هویت، طراحی دسترسی و فدراسیون و claim، و ملاحظات مهاجرت و بازگشت است. شواهد پذیرش و مالک را پیش از اجرا توافق می‌کنیم.
#برای گفتگوی اول چه چیزی بیاوریم؟
هدف کسب‌وکار، معماری فعلی، مالکان بارکاری، محدودیت‌های عملیاتی و مهلت‌های ثابت را بیاورید تا تصمیم‌ها و دسترسی‌های لازم این همکاری مشخص شود.
#حوزه، هزینه و زمان تحویل چگونه تعیین می‌شود؟
ابتدا بارکاری و وابستگی‌ها را محدود می‌کنیم. خروجی‌ها، آمادگی دسترسی، پوشش آزمون و پنجره تأیید برنامه را مشخص می‌کند؛ پیش از کشف قیمت یا زمان ثابت فرض نمی‌کنیم.
#