I WAYF har udbyderen af en tilsluttet tjeneste mulighed for at begrænse hvilke af WAYFs institutioner brugeren kan vælge at logge ind fra. Dét kaldes scoping og har i alt fire forskellige tekniske understøttelser i WAYF. Den mængde identitetsudbydere som tjenesteudbyderen ønsker at lade brugeren kunne vælge imellem, kaldes tjenestens scope. Når en tjenesteudbyder meddeler WAYF et scope, viser WAYF kun de tilsvarende institutionsnavne på listen hvor brugeren skal vælge institution. Hvis scope'et kun har et enkelt element, viderestiller WAYF straks brugeren til den enlige identitetsudbyders login-side og viser ham ingen liste.
SAML-scoping
Udbyderen kan specificere sin tjenestes scope i det SAML2-AuthnRequest han sender til WAYF når brugeren ønsker at logge ind. Specifikationen har form af elementet samlp:IDPList i elementet samlp:Scoping indføjet som sidste element i samlp:AuthnRequest'et:
.
.
<samlp:Scoping>
<samlp:IDPList>
<samlp:IDPEntry ProviderID="IdPentityID1" />
<samlp:IDPEntry ProviderID="IdPentityID2" />
.
.
.
<samlp:IDPEntry ProviderID="IdPentityIDn" />
</samlp:IDPList>
</samlp:Scoping>
</samlp:AuthnRequest>
Forbindelses-ID'erne for WAYFs institutioner — altså de mulige værdier for ProviderID i eksemplet herover — kan udledes af WAYFs metadata for tilsluttede institutioner.
Hvis man selv implementerer sin SAML2-SP, kan man naturligvis nemt snedkerere login-requests med scoping hvis man har behov for det. Men hvis man er afhængig af tredjepartsimplementeringer, kan det være vanskeligt at få sin SP til at afsende scope'ede requests. Derfor har WAYF udviklet tre mere tilgængelige måder for tjenesteudbydere at lave scoping på:
Parameter-scoping
Tjenesten kan sende login-forespørgslen til WAYF med parameteren idplist tilføjet URL'en hvorpå WAYF kaldes med tjenestens AuthnRequest. WAYF fortolker så parameterens værdi som scope for tjenesten. Eksempelvis vil et kald af WAYFs SSO-tjeneste med (SAMLRequest-parameter og) parameteren
idplist=http%3A%2F%2Fadfs.cphbusiness.dk%2Fadfs%2Fservices%2Ftrust%2Chttps%3A%2F%2Fwayf.itu.dk%2Fsaml2%2Fidp%2Fmetadata.php
indsat et sted i URL'en føre til visning af WAYFs discoveryside med kun DTU og Cphbusiness som mulige login-steder. Tjenestens scope angives altså som en URL-indkodet kommasepareret liste af SAML2-entityID'erne for de omfattede login-steder.
Cookie-scoping
Tjenesten kan umiddelbart før loginforespørgslen afsendes, kalde URL'en https://wayf.wayf.dk/vvpmss med parameteren idplist tilføjet. WAYF fortolker så parameterens værdi som scope for tjenesten når loginforespørgslen derefter afsendes inden for 10 sekunder. Syntaksen er fuldstændig som ved parameter-scoping beskrevet herover. Uddybes snarest, med eksempel med JavaScript og iframe.
Metadata-scoping
Tjenesteudbyderen kan angive scope'et i WAYFs metadata for tjenesten, dvs. inde i mEdit: I hvert af felterne IdPList:n angives SAML2-entityID’et på en identitetsudbyder som indgår i scope’et. Bemærk at WAYF bruger det angivne scope ved enhver login-forespørgsel fra tjenesten medmindre en af de herover beskrevne metoder samtidig er benyttet forud for afsendelsen af login-forespørgslen. På den måde er et scope angivet i tjenestens metadata et default-scope for tjenesten.
Scoping til domænenavn
Hvis et scope kun indholder et enkelt element, kan tjenesteudbyderen i stedet for identitetsudbyderens entityID angive identitetsudbyderens domæne:
idplist=cphbusiness.dk
vil have samme virkning som
idplist=http%3A%2F%2Fadfs.cphbusiness.dk%2Fadfs%2Fservices%2Ftrust
. Men hvis scope'et er større end en enkelt identitetsudbyder, kan man ikke betegne hver identitetsudbyder med domænenavn – så skal der bruges entityID.