In WAYF, an SP has the ability to limit the set of IdPs from which the user can attempt to log in. This is called scoping and is supported in four different ways, technically, in WAYF. The set of IdPs that the SP wants to offer the user is referred to as the SP's scope. When an SP reports a scope to WAYF, WAYF will display on its discovery page only the names of the IdPs corresponding to the scope reported. In case the scope contains only a single IdP, WAYF will forward the user to that IdP's login page immediately upon receiving the authentication request from the SP, and won't show him a discovery list.
SAML Scoping
The SP can specify its scope in the very SAML2-AuthnRequest it sends to WAYF whenever a user wants to log in. The specification of the targeted login IdP takes the form of the element samlp:Scoping inserted as the last child of the samlp:AuthnRequest:
.
.
<samlp:Scoping>
<samlp:IDPList>
<samlp:IDPEntry ProviderID="https://entityID-of-preferred-IdP" />
</samlp:IDPList>
</samlp:Scoping>
</samlp:AuthnRequest>
Consequently, when WAYF receives from a service a login request ending like the one shown here, the user will not see the institution list but immediately be taken to the login page of the institution registered under the connection ID (entityID) https://entityID-of-preferred-IdP in WAYF's registry. The connection IDs for WAYF's institutions — i.e., the permissible values for ProviderID in the above example — can be deduced from WAYF's metadata registry.
If you implement your SAML2 SP yourself, it is, of course, easy for you to craft login requests with scoping if you need them. If you are dependent on third-party implementations, on the other hand, you may well encounter difficulty. For that reason WAYF has developped three rather more accessible ways for SPs to do scoping:
Parameter Scoping
The SP can add the parameter idplist to the URL where it calls WAYF with its AuthnRequest. WAYF then interprets that parameter's value as the SP's scope. For instance, calling WAYF with the (SAMLRequest parameter and) the parameter
idplist=http%3A%2F%2Fadfs.cphbusiness.dk%2Fadfs%2Fservices%2Ftrust%2Chttps%3A%2F%2Fwayf.itu.dk%2Fsaml2%2Fidp%2Fmetadata.php
inserted somewhere in the URL will effect WAYF's discovery page showing only the IT University of Copenhagen and Copenhagen Business Academy as selectable IdPs. As can be seen, the SP's scope is specified as a URL-encoded comma-separated list of the SAML2 entityIDs of the IdPs making up the scope.
Cookie Scoping
Immediately before sending the authentication request to WAYF, the SP can call the URL https://wayf.wayf.dk/vvpmss with the parameter idplist added. WAYF then interprets the value of the parameter as the SP's scope when the authentication request is sent within 10 seconds. The syntax is just like with Parameter Scoping, described above. Soon to be elaborated, with JavaScript and iframe examnple.
Metadata Scoping
The SP can specify its scope in WAYF's metadata for the SP, i.e. using mEdit: In each of the fields IdPList:n is specified the SAML2 entityID of an IdP contained in the scope. Please note that WAYF will use the scope specified in metadata with any authentication request from the SP unless one of the methods described above have been used before the authentication request has been sent. The scope specified in its metadata thus is a default scope for the SP.
Scoping using domain name
If a scope contains just a single element, the service provider may, rather than using the entityID of the identity provider, specify the latter by his domain name:
idplist=cphbusiness.dk
will have the same effect as
idplist=http%3A%2F%2Fadfs.cphbusiness.dk%2Fadfs%2Fservices%2Ftrust
. But if the scope is larger than just a single identity provider, domain name cannot be used to specify each identity provider, only entityID can.