AWS Client VPN SAML و Google Workspace: شکاف فراخوانی بازگشتی

صفحه app_not_configured_for_user از Google Workspace می‌آید و پیش از آن‌که حتی یک بستهٔ تونل مذاکره شود ظاهر می‌شود. همین ترتیب، تمام تشخیص است. نصب دوبارهٔ کلاینت، ویرایش پروفایل یا بررسی مسیرها نمی‌تواند صفحه‌ای را پاک کند که نقطهٔ پایانی VPN هنوز آن را ندیده است. مرحله‌ای که شکست می‌خورد، تحویل در مرورگر میان ارائه‌دهندهٔ هویت و یک شنونده روی رایانهٔ خود کاربر است، و در آن تحویل دقیقاً سه چیز ارزش بررسی دارد.

صفحه را بیانیهٔ ارائه‌دهندهٔ هویت بخوانید

Google این را زمانی برمی‌گرداند که برنامهٔ SAML برای حسابی که وارد شده فعال نباشد. ممکن است برنامه خاموش باشد، کاربر بیرون از واحد سازمانی یا گروه تخصیص‌یافته باشد، یا تنظیمات ارائه‌دهندهٔ سرویس با آنچه درخواست خواسته بود هم‌خوان نباشد.

هیچ‌کدام از این‌ها مشکل گواهی، مسیر یا تونل نیست، هرچند کاربر آن را در کلاینت VPN دیده است.

دو مقداری که کلاینت می‌پذیرد

AWS Client VPN تبادل SAML را به ابتکار ارائه‌دهندهٔ سرویس انجام می‌دهد، پس کلاینت مرورگری باز می‌کند، کاربر احراز هویت می‌کند و ارائه‌دهنده یک اظهارنامهٔ امضاشده را به نشانی Assertion Consumer Service بازمی‌گرداند. برای کلاینت رومیزی که AWS فراهم می‌کند آن نشانی یک شنونده روی loopback است، معمولاً درگاه 35001، و مخاطب مورد انتظار شناسهٔ موجودیت برنامهٔ SAML مربوط به Client VPN است، نه موجودیت ورود به کنسول AWS.

هر دو مقدار باید با آنچه کلاینت انتظار دارد هم‌خوان باشد: جایی که اظهارنامه فرستاده می‌شود و کسی که به او خطاب شده است. پیکربندی کپی‌شده از یک برنامهٔ SSO در کنسول می‌تواند کاملاً باورپذیر به نظر برسد و در همان حال جفت نادرست را هدف بگیرد.

هر دو مقدار را از الزامات Client VPN SAML بگیرید، نه از یک راهنمای عمومی ورود یکپارچهٔ AWS. موجودیت SSO کنسول آن‌قدر شبیه است که وسوسه‌کننده باشد. این برنامهٔ دیگری با مخاطب دیگر است و کلاینت اظهارنامه را بدون توضیح رد می‌کند. جفت را یک بار کپی کنید و کنار پروفایل نگه دارید.

Google فراخوانی بازگشتی ساده HTTP را نمی‌پذیرد

کنسول مدیریت نشانی ACS با HTTPS می‌خواهد، در حالی که فراخوانی بازگشتی کلاینت HTTP ساده روی loopback است. آن مقدار را اصلاً نمی‌توان در پیکربندی برنامهٔ Workspace وارد کرد، به همین دلیل برخی تیم‌ها پراکسی معکوسی را امتحان می‌کنند که TLS را پایان می‌دهد و به شنوندهٔ محلی هدایت می‌کند. این کار ناهم‌خوانی را درست نمی‌کند: مرورگر یک مبدأ می‌بیند، کلاینت مبدأ دیگری اعلام می‌کند و پاسخ بازگشتی ممکن است به مقصد نادرست برسد.

ترتیبی که کار می‌کند یک ارائه‌دهندهٔ هویت واسط است. برنامهٔ SAML نزد واسط، فراخوانی بازگشتی loopback و مخاطب AWS را می‌گیرد و واسط حساب Workspace را به بالا فدره می‌کند. قاعدهٔ HTTPS گوگل برآورده می‌ماند و اظهارنامه‌ای که به کلاینت می‌رسد همچنان نشانی و مخاطب مورد انتظار را نام می‌برد.

آن واسط یک وابستگی اداری است که کسی باید مالک آن باشد، پایش کند و در خروج کارمند لحاظش کند. همچنین دومین جایی است که یک قطعی به شکست ورود تبدیل می‌شود. پیش از وعده‌دادن طراحی، هزینه‌اش را حساب کنید. اگر هیچ‌کس مالک آن نشود، پاسخ صادقانه این است که کلاینت AWS نمی‌تواند از Workspace به‌عنوان تنها ارائه‌دهندهٔ هویت خود استفاده کند.

تخصیص و تأیید دو مرحله‌ای

پیش از هر بازطراحی، تأیید کنید که برنامه برای واحد سازمانی یا گروه درست فعال است و برنامه‌های SAML شخص ثالث کنترل‌های تخصیص خودشان را جدا از فهرست برنامه‌ها در سمت Google دارند.

همچنین بررسی کنید که تأیید دو مرحله‌ای در حساب فعال است یا نه. Google می‌تواند آن را پیش از قابل استفاده شدن یک برنامهٔ SAML برای کاربر الزامی کند و یک پاسخ در رشتهٔ اصلی دقیقاً به همین شکل حل شد. این ارزان‌ترین چیزی است که می‌توان کنار گذاشت و آزاردهنده‌ترین چیزی که آخر از همه کشف می‌شود.

با یک نشست پاک تأیید کنید

پس از هر تغییر، با پروفایل مرورگر تازه و پیکربندی پاک کلاینت آزمایش کنید. اظهارنامه‌های ذخیره‌شده و نشست‌های دوباره‌استفاده‌شده پنهان می‌کنند که آیا اصلاح رسیده است.

سپس دو رکورد را کنار هم مقایسه کنید: رویداد حسابرسی ارائه‌دهندهٔ هویت و گزارش کلاینت. ورود موفق بدون تونل به فراخوانی بازگشتی یا مخاطب اشاره می‌کند. تونل متصل با منبعی که در دسترس نیست مشکلی در مسیریابی یا مجوز است و کاملاً جای دیگری می‌گنجد.

چه چیزی را تغییر ندهید

برای گذشتن از صفحه، auth-federate را از پروفایل حذف نکنید و بررسی‌های گواهی را غیرفعال نکنید. هر دو طراحی احراز هویت را تغییر می‌دهند نه فراخوانی بازگشتی معیوب را، و هر دو معمولاً در به‌روزرسانی بعدی کلاینت می‌شکنند.

به‌جای آن تحویل را درست کنید و یادداشتی بگذارید که واسط، مخاطب و درگاه loopback را نام ببرد. نفر بعدی که صفحه را می‌بیند به هر سه نیاز خواهد داشت.