آیا SSO ی VPN کاربران را به‌طور خودکار به برنامه‌های داخلی وارد می‌کند؟

دروازه‌ی VPN که از طریق ارائه‌دهنده‌ی هویت احراز هویت می‌کند تنها یک چیز را ثابت می‌کند: ارائه‌دهنده برای یک کاربر در برابر دروازه ضمانت کرده است. این دروازه به آن کاربر اعتباری برای ویکی شبکه‌ی داخلی، داشبورد پایش یا سرور ساخت نمی‌دهد. آن سرویس‌ها افراد را از طریق فدراسیون خودشان وارد می‌کنند و مجوز خودشان را اعمال می‌کنند، و تونل تنها تعیین می‌کند که کدام بسته‌ها می‌توانند به آن‌ها برسند.

سه نشست، سه تصمیم جداگانه

وضعیت‌ها را جدا نگه دارید، چون هر یک طبق برنامه‌ی خودش منقضی می‌شود. نشست VPN پذیرش هویت توسط دروازه به‌اضافه‌ی دسترسی شبکه‌ای است که اعطا کرده است. نشست مرورگر در ارائه‌دهنده‌ی هویت همان چیزی است که مرورگر هنوز برای آن ارائه‌دهنده نگه می‌دارد و می‌تواند طبق سیاستش دوباره استفاده کند. نشست برنامه به سرویسی تعلق دارد که پاسخی خطاب به خود را اعتبارسنجی کرده است.

اشتباه گرفتن این وضعیت‌ها پرسش نادرست را می‌سازد، که معمولاً این‌گونه بیان می‌شود که چرا تونل کاربر را همه‌جا وارد نمی‌کند. آن را بازنویسی کنید: کدام برنامه ورودی فدراسیون ندارد، کدام کاربر را رد می‌کند و کدام مسیر ندارد. یک اعلان ورود واحد که برنامه‌ی شبکه‌ی داخلی را باز می‌کند باز هم می‌تواند به ارائه‌دهنده برگردد، چون تغییر مسیر دوم درخواست مجوز جدیدی برای مخاطب دیگری است.

دروازه را به‌عنوان برنامه‌ی مستقل خودش متصل کنید

VPN را به‌عنوان برنامه‌ای تأییدشده در ارائه‌دهنده ثبت کنید، با شناسه، URI تغییر مسیر و تخصیص کاربر مخصوص خودش. سپس تعیین کنید آن ورود کدام مجوزهای شبکه را می‌دهد، چون این سیاست VPN است نه ویژگی ارائه‌دهنده. کاربرانی که باید فقط به زیرشبکه‌ی پایش برسند سیاست دروازه‌ی متفاوتی می‌گیرند، نه گذرواژه‌ی متفاوت.

پاسخ احراز هویت تونل اعتباری قابل استفاده‌ی مجدد نیست. نشانه‌های شناسه‌ی OIDC ادعای مخاطبی دارند که کلاینتی را نام می‌برد که برایش صادر شده‌اند، و اظهارات حامل SAML مخاطب را به ارائه‌دهنده‌ی سرویس گیرنده محدود می‌کند. سرویس دومی که پاسخ سرویس اول را می‌پذیرد اشتباه پیکربندی شده است، و کپی کردن نشانه در برنامه‌ای دیگر ادغام نیست.

هر برنامه‌ی داخلی را ثبت کنید، سپس بافت مرورگر را تنظیم کنید

هر سرویس به مقادیر پشتیبانی‌شده‌ی SAML یا OIDC نیاز دارد: صادرکننده، شناسه‌ی کلاینت، URL بازگشت فراخوان یا مصرف‌کننده‌ی اظهاره، ادعاهای لازم و تخصیص. دسترس‌پذیری روی آن می‌آید، چون بررسی‌های هویت هرگز مسیر یا پاسخ DNS نمی‌دهند.

1. ورودی برنامه را بسازید و تأیید کنید که شناسه‌ی موجودیت یا کلاینت با آنچه برنامه می‌فرستد مطابقت دارد.
2. URL دقیق بازگشت فراخوان را همراه با طرح و پورت ثبت کنید؛ یک خطای کوچک پس از احراز هویت کاربر شکست می‌خورد.
3. کاربران یا گروه‌ها را تخصیص دهید، سپس تأیید کنید که ادعاهای لازم صادر می‌شوند.
4. نقاط پایانی ارائه‌دهنده‌ی هویت را همراه با برنامه‌ی خصوصی مجاز کنید، وگرنه تغییر مسیر کامل نمی‌شود.

بافت مرورگر تعیین می‌کند که آیا نشست موجود ارائه‌دهنده دوباره استفاده می‌شود. کلاینت بومی که مرورگر سیستم را باز می‌کند می‌تواند آن وضعیت را به اشتراک بگذارد، در حالی که نمای تعبیه‌شده با ظرف کوکی خودش معمولاً نمی‌تواند. مرورگر جدید، پنجره‌های خصوصی و پروفایل دوم همه از صفر شروع می‌کنند، که انتظار می‌رود و پیکربندی خراب SSO نیست.

جریان را اجرا کنید و بخوانید کجا متوقف می‌شود

با پنل شبکه‌ی مرورگر بازتولید کنید و زنجیره‌ی تغییر مسیر را تماشا کنید. یک گذر مفید هر بار یک گام را دنبال می‌کند: از دروازه به ارائه‌دهنده، از ارائه‌دهنده بازگشت به برنامه با کد یا اظهاره، از برنامه به نقطه‌ی پایانی نشانه‌ی ارائه‌دهنده، صدور نشست برنامه. گامی که زنجیره در آن متوقف می‌شود مؤلفه‌ی قابل رفع را نام می‌برد.

دو بررسی خط فرمان تردیدهای معمول را حل می‌کند و اجرای هر دو از میزبان مدیریت بی‌خطر است:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

وقتی فراداده نقاط پایانی‌ای را فهرست می‌کند که هرگز ثبت نکرده‌اید، برنامه به مستأجر یا صادرکننده‌ی دیگری اشاره می‌کند. وقتی نخستین درخواست به برنامه با 302 به میزبانی غیرمنتظره پاسخ می‌دهد، پیکربندی فدراسیون برنامه جای بررسی است، نه پروفایل VPN.

اعلان‌ها را با یافتن اینکه چه کسی درخواست کرده اصلاح کنید

اعلان دوم گذرواژه به‌طور خودکار نقص نیست. برنامه ممکن است سطح اطمینان بالاتری بخواهد، یا ارائه‌دهنده ممکن است حداکثر عمر نشست و چالش تازه‌ای اعمال کند. حذف این الزامات برای آرام‌تر کردن جریان کنترلی عمدی را تضعیف می‌کند، پس پیش از تغییر سیاست مشخص کنید کدام مؤلفه آن را خواسته است.

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