VPN SSO хэрэглэгчдийг дотоод апп-д автоматаар нэвтрүүлдэг үү?

Нэг нэвтрэлт нь туннель болон түүний цаанадах апп-уудыг хамарч болох боловч апп бүр өөрийн итгэлцэлтэй байх тохиолдолд л болно. Үүнийг холбох, шалгах дараалал энэ байна.

Таних тэмдгийн нийлүүлэгчээр баталгаажуулдаг VPN гарц нэг зүйлийг л нотолно: нийлүүлэгч хэрэглэгчийг гарцын өмнө батлав. Энэ нь тухайн хэрэглэгчид дотоод сүлжээний вики, хяналтын самбар эсвэл build серверт ямар ч итгэмжлэл өгөхгүй. Тэдгээр үйлчилгээ хүмүүсийг өөрийн холбоодоор нэвтрүүлж, өөрийн зөвшөөрлийг хэрэглэдэг бөгөөд туннель зөвхөн ямар пакет тэдэнд хүрч болохыг шийддэг.

Гурван сесс, гурван тусдаа шийдвэр

Төлөвүүдийг тусдаа байлгаарай, учир нь тус бүр өөрийн хуваарийн дагуу дуусна. VPN сесс гэдэг нь гарцын таних тэмдгийг хүлээн авах ба түүний олгосон сүлжээний хандалт юм. Таних тэмдгийн нийлүүлэгч дэх хөтчийн сесс гэдэг нь хөтөч тэр нийлүүлэгчид зориулж хадгалсан, түүний бодлогын дагуу дахин ашиглаж болох зүйл юм. Апп-ын сесс нь өөрт нь хаягласан хариуг баталгаажуулсан нэг үйлчилгээнд хамаарна.

Эдгээр төлөвийг хольсон нь буруу асуулт үүсгэдэг, ихэвчлэн туннель яагаад хэрэглэгчийг хаа сайгүй нэвтрүүлдэггүй гэж асуудаг. Үүнийг дахин томъёол: аль апп-д холбооны бүртгэл байхгүй, аль нь хэрэглэгчийг татгалзаж, аль нь замгүй байна. Дотоод сүлжээний апп-ыг нээх нэг нэвтрэлтийн сануулга нийлүүлэгч рүү буцаж болно, учир нь хоёр дахь дахин чиглүүлэлт нь өөр үзэгчдэд зориулсан шинэ зөвшөөрлийн хүсэлт юм.

Гарцыг өөрийн апп болгон холбох

VPN-ийг нийлүүлэгчид зөвшөөрөгдсөн апп болгон бүртгүүлээрэй, өөрийн танигч, дахин чиглүүлэх URI, хэрэглэгчийн хуваарилалттай. Дараа нь тэр нэвтрэлт ямар сүлжээний зөвшөөрөл олгодогыг шийдээрэй, учир нь энэ нь VPN бодлого, нийлүүлэгчийн боломж биш. Зөвхөн хяналтын дэд сүлжээнд хүрэх ёстой хэрэглэгчид өөр гарцын бодлого авдаг, өөр нууц үг биш.

Туннелийн баталгаажуулалтын хариу нь дахин ашиглах боломжтой итгэмжлэл биш. OIDC ID токенууд нь ямар хэрэглэгчид зориулж олгогдсоныг нэрлэсэн үзэгчдийн мэдэгдэл агуулдаг бөгөөд SAML тээгч мэдэгдлүүд үзэгчдийг хүлээн авагч үйлчилгээний нийлүүлэгчээр хязгаарладаг. Эхний үйлчилгээний хариуг хүлээн авдаг хоёр дахь үйлчилгээ буруу тохируулагдсан бөгөөд токеныг өөр апп руу хуулах нь интеграци биш.

Дотоод апп бүрийг бүртгэж, дараа нь хөтчийн контекстийг тохируул

Үйлчилгээ бүрт дэмжигдсэн SAML эсвэл OIDC утгууд хэрэгтэй: олгогч, хэрэглэгчийн танигч, буцаан дуудлага эсвэл мэдэгдэл хэрэглэгчийн URL, шаардлагатай мэдэгдэл, хуваарилалт. Хүртээмж нь үүний дээр ирдэг, учир нь таних тэмдгийн шалгалт хэзээ ч зам эсвэл DNS хариу өгдөггүй.

  1. Апп-ын бүртгэлийг үүсгэж, аж ахуйн нэгж эсвэл хэрэглэгчийн ID нь апп-ын илгээдэгтэй таарч байгаа эсэхийг батал.
  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 профайл биш.

Хэн хүссэнийг олж сануулгыг зас

Хоёр дахь нууц үгийн сануулга автоматаар алдаа биш. Апп илүү өндөр баталгааны түвшин шаардаж болно, эсвэл нийлүүлэгч сессийн дээд нас болон шинэ сорилт ногдуулж болно. Урсгалыг тайван болгохын тулд эдгээр шаардлагыг хасах нь зориудын хяналтыг сулруулдаг тул бодлогыг өөрчлөхийн өмнө аль бүрэлдэхүүн шаардсаныг тодорхойл.

Дараа нь юуг сайжруулахаа шийд. Сануулга апп-аас ирвэл түүний холбооны бүртгэлийг зас. Бодлогын дагуу нийлүүлэгчээс ирвэл шаардлагыг баримтжуул. Амжилттай нэвтрэлтийн дараа апп хүртээмжгүй бол сэжигтэй нь туннелийн чиглүүлэлт, учир нь таних тэмдэг ба пакет хүргэлт өөр өөр газарт бүтэлгүйтдэг бөгөөд хэрэглэгчийн суудлаас ижил харагддаг.

Холбоотой нийтлэлүүд