Vid inloggning till en tjänst som kräver en viss tillitsnivå eller kräver multifaktorsinloggning behöver ett antal kontroller göras. Om någon kontroll misslyckas ska användaren informeras om hur den bäst löser problemet.

...

1. Om multifaktorinloggning krävs: Inom SWAMID används signalering enligt REFEDS Multi-Factor Authentication Profile (REFEDS MFA). Begär att multifaktorinloggning används genom att i attributet RequestedAuthnContext ange värdet https://refeds.org/profile/mfa i Authentication Request.
2. Om Single Sign-On inte får användas: Begär att ny inloggning används genom att i attributet ForceAuthn ange värdet true i Authentication Request.
   • För att åsidosättande av Single Sign-On ska fungera korrekt måste alla godkända inloggningsmetoder vara definierade i attributet RequestedAuthnContext, t.ex. https://refeds.org/profile/mfa, https://refeds.org/profile/sfa och urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport för både multifaktor- och singelfaktorinloggning. Vissa identitetsutgivarprogramvaror kan luta sig tillbaka på operativsysteminloggningen om det inte explicit pekas ut vilka inloggningsmetoder som är godkända.

...

• 3.2 Configure Shibboleth SP - attribute-map.xml
• 3.3 Configure Shibboleth SP - Check for Identity Assurance or REFEDS SIRTFI
• Kravställning vid inloggning
• Service Provider error handling during federated login

1. Kontroll om att IdP:n uppfyller SWAMID AL2

Se 3.3 Configure Shibboleth SP - Check for Identity Assurance or REFEDS SIRTFI#3.3ConfigureShibbolethSPCheckforIdentityAssuranceorREFEDSSIRTFI-GetassuranceprofilesfrommetadataintheShibbolethServiceProvider för att säkerställa att Meta-Assurance-Certification följer med som ett attribut till applikationen.

...

ErrorURL:en ovan ska då peka på https://idp.example.se/ErrorUrl/?errorurl_code=AUTHORIZATION_FAILURE&errorurl_ts=...&errorurl_rp=...&errorurl_tid=...&errorurl_ctx=http://www.swamid.se/policy/assurance/al2. Se Service Provider error handling during federated login för mer information om errorURL.

2. Kontroll om att identifierande attribut följer med

Kontrollera att de attribut som krävs av tjänsten har ett värde. Detta kan typiskt röra sig om eduPersonPrincipalName som ofta används som användarnamn i tjänster, eller kanske norEduPersonNIN eller personalIdentityNumber. Om attribut saknas så är det lämpligt att meddela användaren att IdP:n inte skickar attributen som krävs för att identifiera dig, hänvisa användaren till sin support via IdP:ns errorURL, med kod IDENTIFICATION_FAILURE och entitetskategori (samt eventuellt specifikt attribut) som kontext:

...

ErrorURL:en ovan ska då peka på https://idp.example.se/ErrorUrl/?errorurl_code=IDENTIFICATION_FAILURE&errorurl_ts=...&errorurl_rp=...&errorurl_tid=...&errorurl_ctx=http://refeds.org/category/research-and-scholarship,%20eduPersonPrincipalName.

3. Kontroll om att assurance-attributet följer med från IdP:n

Förutom de direkt identifierande attributen så behöver även kontroll göras att assurance-attributet följer med. IdP:er kan vara konfigurerade att släppa användarnamn och personnummer men specifikt inte assurance. Alla användare i SWAMID måste uppfylla minst SWAMID AL1 så frånvaro av attributet beror sannolikt på att IdP:n inte alls släpper attributet. Om attribut saknas så är det lämpligt att meddela användaren att IdP:n inte skickar tillitsnivå, hänvisa användaren till sin support via IdP:ns errorURL, med kod IDENTIFICATION_FAILURE och entitetskategori (samt eventuellt eduPersonAssurance) som kontext:

...

ErrorURL:en ovan ska då peka på https://idp.example.se/ErrorUrl/?errorurl_code=IDENTIFICATION_FAILURE&errorurl_ts=...&errorurl_rp=...&errorurl_tid=...&errorurl_ctx=http://refeds.org/category/research-and-scholarship,%20eduPersonAssurance.

4. Kontroll om att användaren uppfyller SWAMID AL2

Kontrollera slutligen att SWAMID AL2 uppfylls för användaren. Attributet assurance är en lista med tillitsnivåer som användaren uppfyller. Listan är typiskt en semikolonseparerad sträng, exempel:

...

Om användarna i tjänsten förväntas ha en hög teknisk kompetens kan det ofta också vara lämpligt att hänvisa till https://release-check.swamid.se/ där användaren kan se sina egna attribut och annan information kopplat till sin inloggningstjänst.

Teknisk implementation baserat på krav om multifaktorinloggning och åsidosättande av single sign-on

Instruktionerna nedan är skrivna för Shibboleth Service Provider och webbservern Apache. Motsvarande behöver göras för annan SP- och webbserverprogramvara.

1. Begär multifaktorinloggning och åsidosättande av single sign-on

I konfigurationen för Apache finns det flera sätt att aktivera inloggning med Shibboleth och det beskrivs inte här, se 1.2 Configuring Apache Web Server to use Shibboleth för ett exempel. Autentisieringsinställningar i via location-objektet beskrivs nedan.

För att aktivera krav på multifaktorinloggning via signaleringen för REFEDS MFA:

• ShibRequestSetting authnContextClassRef https://refeds.org/profile/mfa

För att aktiver åtsidosättande av single sign-on:

• ShibRequestSetting forceAuthn true

<Location /mfa-protected-directory>
    AuthType shibboleth
    ShibRequireSession On
    ShibRequestSetting authnContextClassRef https://refeds.org/profile/mfa
    ShibRequestSetting forceAuthn true
    require valid-user
</Location>

2. Kontroll om att multifaktorinloggning är genomförd

Shibboleth släpper normalt sätt inte in användaren användaren in till webbtjänsten om inte multifaktorinloggning har skett men man bör ändå kontrollera att multifaktorinloggning har genomförts.

Använd inloggningsmetod finns i servervariablen Shib-AuthnContext-Class.

Det är möjligt att anpassa den generella felsidan för Shibboleth SP så att den visar ett bra felmeddelande istället för det generella som är inbyggt i Shibboleth SP, se Errors - Shibboleth Service Provider 3. Det är även möjligt att använda ett passiv, eller lazy, modell för inloggning men då krävs att applikationen både hanterar autentisieringsbegäran och autentisieringskontrollen i applikationen istället för att låta standardmekanismerna göra det men det beskrivs inte på denna wikisida.

Om authentication context class är felaktigt så är det lämpligt att meddela användaren att IdP:n inte skickar tillitsnivå, hänvisa användaren till sin support via IdP:ns errorURL, med kod AUTHENTICATION_FAILURE och https://refeds.org/profile/mfa som kontext:

ErrorURL:en ovan ska då peka på https://idp.example.se/ErrorUrl/?errorurl_code=AUTHENTICATION_FAILURE&errorurl_ts=...&errorurl_rp=...&errorurl_tid=...&errorurl_ctx=https://refeds.org/profile/mfa.

3. Kontroll om att  är genomförd "nyss"

Om inte single sign-on tillåts vid inloggningen ska man i applikationen kontrollera att inloggningen har skett i närtid, t.ex. inom fem minuter från aktuell tid. När inloggningen skedde finns i servervariabeln Shib-Authentication-Instant.

Om inloggningstiden är felaktig så är det lämpligt att meddela användaren att IdP:n inte skickar tillitsnivå, hänvisa användaren till sin support via IdP:ns errorURL, med kod AUTHENTICATION_FAILURE och forceAuthn som kontext:

ErrorURL:en ovan ska då peka på https://idp.example.se/ErrorUrl/?errorurl_code=AUTHENTICATION_FAILURE&errorurl_ts=...&errorurl_rp=...&errorurl_tid=...&errorurl_ctx=forceAuthn.