Angiv adgangsresultatet, ikke kun et SSO-afkrydsningsfelt
Et krav om, at en godkendelsesplatform understøtter SAML single sign-on, er ufuldstændig, medmindre det forklarer, hvem der skal indtaste hvilken lejer, med hvilke tilladelser, og hvad der sker, når deres rolle eller ansættelse ændres. Vellykket godkendelse etablerer en identitetspåstand under et aftalt forbundsforhold. Det autoriserer ikke automatisk alle domæner, kunder, rapporter eller administrative handlinger i applikationen. Indkøbs- og implementeringsgennemgange bør derfor teste adgangsresultatet i stedet for at acceptere et vellykket login som hele kravet.
Denne artikel er en foreslået kravramme. Det hævder ikke, at EmailAuth implementerer SAML, just-in-time provisionering, bestemte roller eller nogen sessionskontrolfunktion. Ingen identitetsudbyder blev konfigureret, påstand indsendt eller givet adgang. Microsofts SAML-protokoldokumentation giver en konkret officiel beskrivelse af en Entra-støttet udveksling, mens de foreslåede acceptkriterier stadig kræver bekræftelse mod den faktiske platform og identitetsudbyder.
Bind foreningen til den påtænkte ansøgning og lejer
Dokumenter identitetsudbyderen, tjenesteudbyderen, påtænkt lejer, godkendt forbundsadministrator og konfigurationsejer. Registrer applikations-id'et og påstandsforbrugerslutpunktet fra godkendte konfigurationsbeviser uden at kopiere legitimationsoplysninger eller komplette følsomme påstande til et generelt regneark. Entra-dokumentationen beskriver udsteder, publikum, svarkorrelation og emnebekræftelse. Disse er ikke udskiftelige etiketter: en påstand, der er beregnet til én applikation, bør ikke blive autoritet for en anden applikation, blot fordi den har en gyldig signatur.
Kræv den faktiske implementering for at validere de protokolelementer, der passer til dets understøttede flow, herunder tillid til udstederen og underskriftsmateriale, tilsigtet publikum og modtager, gyldighedsbetingelser og anmodningskorrelation, hvor det er relevant. Opfind ikke en enkelt valideringsopskrift, der dækker hvert påbegyndt flow eller bibliotek. Bed leverandøren om at dokumentere sine understøttede flows og sikkerhedstjek, og verificer dem derefter i et godkendt isoleret miljø. Et eksempel på et XML-svar i dokumentationen er ikke bevis for, at målplatformen håndhæver disse kontroller.
Hold godkendelse og godkendelse adskilt
Azures identitetsvejledning til flere lejere skelner rollebaseret og ressourcebaseret godkendelse og advarer mod føderationsfejlkonfigurationer, der giver adgang til utilsigtede lejere. Brug den skelnen, når du skriver krav. En bruger, der er godkendt af en kundes identitetsudbyder, har stadig brug for et autoriseret forhold til den korrekte applikationslejer og ressourcer. Et suffiks for e-mailadresse alene bør ikke behandles som en komplet lejemåls- eller rollebeslutning uden en dokumenteret godkendt kortlægning.
Angiv de tilladte roller og ressourceomfang uafhængigt af loginmetoden. En rapportfremviser kan læse udvalgte domæner, men ikke eksportere alle kunder; en lejeradministrator kan administrere medlemmer uden at ændre en anden lejers indstillinger. Definer, hvem der kan etablere eller ændre disse tilknytninger, og hvordan ændringer gennemgås. Hvis der bruges gruppe- eller rolleattributter, skal du dokumentere deres kilde, accepterede værdier og adfærd, når attributter er fraværende eller uventede. Disse er foreslåede kontroller, ikke påstande om et bestemt produkts rollemodel.
Definer deltage og rolleskifteadfærd
For en ny bruger skal du angive, om kontoen skal klargøres på forhånd, eller om understøttet just-in-time adfærd er tilladt. Dokumenter, hvordan den påtænkte lejer er valgt, og om der kræves godkendelse, før den første session kan få adgang til data. Udled ikke automatisk klargøring ud fra tilgængeligheden af SAML-godkendelse. Leverandøren skal identificere sin faktiske understøttede livscyklusadfærd og eventuelle forskelle mellem administrativ, interaktiv og API-adgang.
For rolleændringer skal du angive, hvornår nye tilladelser skal træde i kraft, og hvordan eksisterende sessioner håndteres. Et krav bør skelne mellem fjernelse af en rolle og deaktivering af en konto. Det bør også angive, om cachelagrede godkendelsesbeslutninger opdateres, og hvordan det observerede resultat vil blive kontrolleret. Undgå at antage, at en ny påstand ved næste login opdaterer hver allerede aktive session. Behold faktiske beviser for både tilladte og nægtede handlinger efter en ændring, når den autoriserede test til sidst udføres.
Gør deaktivering og sessionshåndtering eksplicit
En medarbejders identitetsudbyderkonto kan blive deaktiveret, mens en tjenesteudbydersession forbliver aktiv i henhold til applikationens egen adfærd. Kravene skal spørge, hvordan eksisterende sessioner, huskede enheder, lokale reservekonti og ikke-interaktive legitimationsoplysninger behandles. SSO-tilgængelighed etablerer ikke i sig selv en universel logout- eller tilbagekaldelsesgaranti. Kræv, at leverandøren beskriver understøttede tilbagekaldelsesmekanismer, forventede begrænsninger og det nødvendige bevis for at verificere dem.
Adskil rutinemæssig offboarding fra nødinddæmning. Rutinemæssige ændringer kan følge planlagt livscyklussynkronisering; en hændelse kan kræve, at en autoriseret administrator tilbagekalder adgang omgående via en anden understøttet sti. Denne artikel udfører eller godkender ikke disse sikkerhedsændringer. Det foreslår, at deres ejerskabs- og verifikationskriterier dokumenteres før vedtagelsen, i stedet for at blive opdaget under en hændelse, hvor teamet antager, at deaktivering af identitetsudbyderkontoen var tilstrækkelig.
Et arbejdsark til SSO-accept
Opret et regneark med identitetsudbyderens konfigurationsreference, tjenesteudbyderlejer, brugertestidentitet, påtænkt rolle, ressourceomfang, understøttet flow og forventet resultat. Tilføj rækker til deltagelse, rolleforøgelse, rollereduktion, deaktivering, aktiv sessionsadfærd og enhver godkendt lokal gendannelsessti. Registrer, hvem der autoriserer hver test, og hvilket miljø, der indeholder armaturerne. Medtag ikke rigtige adgangskoder, sessionscookies, private signeringsnøgler eller komplette produktionspåstande i arbejdsarket.
Inkluder negative sager, der viser grænser: en identitet, der er beregnet til en anden lejer, må ikke få adgang, en seer må ikke modtage administrative rettigheder, og en fjernet rolle må ikke stille forblive effektiv ud over den dokumenterede adfærd. Udtryk disse som acceptkriterier, indtil de faktiske resultater foreligger. En mislykket test bør registrere handlingen og observerede svar uden at antage, at fejlen blev håndhævet sikkert, blot fordi grænsefladen skjulte en knap. Server-side-autorisation kræver sit eget bevis.
Fiktiv diagnose: login lykkes, men omfanget er forkert
En fiktiv organisation evaluerer en platform for to kundeteams. Begge bruger den samme virksomhedsidentitetsudbyder, men deres applikationslejere skal forblive adskilte. En indledende demonstration viser vellykket SSO og et rapportdashboard. Anmelderen bemærker, at demonstrationen aldrig fastslog, hvilken lejer testbrugeren var bundet til, eller om en eksisterende session ville beholde en rolle efter fjernelse.
Den foreslåede opfølgning er en autoriseret inventarbaseret test, der kontrollerer lejerbinding, rollereduktion og invaliditet separat. Et vellykket login tæller kun for godkendelsesdelen af kravet. Ingen sådan test blev udført her, og den fiktive platform er ikke en påstand om EmailAuth eller en anden navngiven tjeneste. Eksemplet forklarer, hvorfor en tilsyneladende komplet SSO-demonstration kan efterlade spørgsmål om materialeadgang ubesvarede.
Kræv bevis før du accepterer kapaciteten
Et nyttigt leverandørsvar identificerer understøttede protokolstrømme, livscyklusintegrationer, rollekortlægning, sessionsadfærd, reserveadgang og revisionsbevis. Det angiver også begrænsninger klart. Konverter ikke en køreplanserklæring eller et skærmbillede til bevis for implementering. Bevar produktversionen og konfigurationskonteksten, så acceptresultatet forbliver fortolkbart efter et udbyderskifte.
Kataloget kræver test af joinforbindelse, rolleændring, deaktivering og håndtering af aktiv session med nuværende platformunderstøttelse. Det originale bevis forbliver åbent. Dette udkast indeholder foreslåede krav og en fiktiv øvelse, ikke testresultater. Gennemgang af menneskelig specialist, kildeanvendelighed, produktionsruter, tilgængelighed og ejerfrigivelse er også åbne. Offentliggørelse og enhver kapacitetspåstand kræver autoriserede observationer af den faktiske platform i stedet for konklusioner fra SAML-dokumentation alene.