Pag-access sa Portal APM: kanino ang session ng application?
Limang pagsusuri para sa desisyon sa pag-publish gamit ang BIG-IP Portal Access: saklaw ng resource, session ng backend, dalawang timer, kahulugan ng logout at mga limitasyon ng pag-rewrite.
Ang pag-publish ng intranet application sa pamamagitan ng BIG-IP APM Portal Access ay desisyon tungkol sa mga session, hindi tungkol sa pagkopya ng virtual server. Pinapasok ng portal ang user, pinapanatili ng rewrite profile ang mga piling request sa landas ng gateway, at may sariling session pa rin ang application. Hinihiwalay ng limang pagsusuri ang disenyong kumikilos nang mahulaan mula sa disenyo kung saan natututuhan ng help desk ang mga timeout isa-isa bawat user. Gawin sila sa pagkakasunod-sunod at huminto sa unang hindi totoo.
Pagsusuri 1: na-publish ang resource, hindi lamang naka-link
Ang bookmark sa webtop ay nagpapatunay na may nakikitang entry ang user. Hindi nito pinapatunayan na na-publish ang application. Hanapin ang access profile, rewrite profile at ang virtual server na nagsasama sa kanila, pagkatapos tiyakin na ang assignment ng resource ay tumuturo sa application na iniisip mo. Kung may kulang o hindi pare-pareho sa tatlo, walang saysay ang natitirang listahan.
Ang kalahating na-publish na kaso ay mukhang maayos sa entry point. Dinadala ng virtual server ang access profile habang ang rewrite profile ay limitado sa ibang resource URI, kaya lumilitaw ang entry sa webtop at naglo-load ang unang pahina, pagkatapos umaalis ang mga request ng sub-path sa landas ng gateway at direktang narating ang backend. Ang kabaligtaran ay resource na nakatalaga sa maling application: bumubukas ang bookmark, at may binubuksang hindi inaprubahan ng kahit sino.
Pagsusuri 2: ang session ng backend ay hiwalay na estado
Maaaring humingi ang backend ng sarili nitong authentication kahit itinuturing ng APM na naka-sign in ang user. Ang sinusuportahang SSO integration ay nagtatatag ng ugnayang iyon para sa iyo, ngunit ang pagtanggap sa portal login ay hindi ginagawang tumatanggap ang bawat application ng parehong credentials o parehong session cookie. Kung hindi naka-configure ang SSO para sa resource, hihingi ang application ng sarili nitong login sa loob ng portal na authenticated na.
Ang pag-disable ng SSO para baguhin ang nakikitang prompt ay karaniwan at mahinang shortcut: binabago nito ang disenyo ng authentication nang hindi hinahawakan ang lifecycle na gumawa ng prompt. Sa halip, magpasya kung dapat bang lumitaw ang backend login, at kung dapat, gawin itong tahasang bahagi ng naka-publish na daloy.
Pagsusuri 3: may dalawang orasan, at hindi sila ang parehong orasan
Ang access profile ng APM ay may inactivity timeout at maximum na haba ng buhay ng session. Ang application ay may sariling idle timer at pag-expire ng cookie. Ang pagpapahaba ng timer ng portal ay hindi nagpapahaba ng session ng application, at ang pagpapaikli ng session ng application ay hindi nagla-logout sa user mula sa portal.
| Timer | Owner | What it ends |
|---|---|---|
| Inactivity timeout | APM access profile | the portal session after idle time |
| Maximum lifetime | APM access profile | the portal session regardless of activity |
| Application cookie | Backend application | the application session inside a live portal |
Ang klasikong tawag sa support ay nagmumula sa pares na hindi tugma: valid pa ang portal, wala na ang session ng application, at nakikita ng user ang login form na tila sumasalungat sa portal. Tamang pag-uugali iyon, hindi sira, at ang solusyon ay piliin kung aling orasan ang dapat mag-expire muna para sa application na ito.
Pagsusuri 4: may tinukoy na saklaw ang logout
Isulat kung ano ang dapat tapusin ng sign-out button ng application: ang application na iyon lang, ang buong APM session, o mas malawak na session ng identity provider. Sinusuportahan ng access profile ang listahan ng logout URI na may opsyonal na pagkaantala, at ganoon mo ginagawang tinatapos ng logout ng application ang session ng portal kapag iyon ang pangangailangan. Kung wala ito, iniiwan ng logout ng application na buhay ang portal, at ang susunod na request ay maaaring tahimik na mag-sign in muli sa user.
Isaalang-alang ang epekto sa iba pang resource sa parehong portal. Kung ang logout mula sa isang application ay nagtatapos ng session ng anim pa, tatawagin itong bug ng mga user maliban kung napagkasunduan muna ang pag-uugali sa may-ari ng application. Ang pagsasara ng tab at pagbabalik sa webtop ay hindi patunay na may natapos.
Pagsusuri 5: nakakaligtas ang application sa pag-rewrite
Nire-rewrite ng Portal Access ang mga piling web content, at may mga gilid ang pag-rewrite. Maaaring mahulog sa labas ng kayang hawakan ng isang release ang mga modernong client-side feature, background worker, upload flow at federated login. Ang matrix ng compatibility ayon sa bersyon ng F5 ang dokumentong dapat basahin bago mag-commit, dahil nakadepende sa release ang mga limitasyon.
Subukan ang mahahalagang daloy, hindi ang landing page: mag-sign in, dumaan sa bawat kinakailangang function, mag-upload kung nag-a-upload ang application, hayaang mag-expire ang inilaan na session at sundan ang bawat logout path. Ang pahinang nag-render nang isang beses ay hindi patunay na gumagana ang application.
Kapag hindi ma-rewrite ang kinakailangang daloy, lumipat sa dokumentadong disenyo ng federation, reverse proxy o network access. Ang browser portal na inutusang kumilos tulad ng pangkalahatang tunnel ay papasa sa demo at babagsak sa audit.