Följade steg behöver du följa för att ansluta en SP till SWAMID:

Installera programvara

Först och främst behöver du installera programvara. Om du kör Apache som webserver så rekommenderar vi att du använder Shibboleth. De flesta större Linux-distributioner (debian, ubuntu, centos, redhat) har Shibboleth färdigpaketerat och det går att installera som ett vanligt paket. På ubuntu/debian installerar man tex Shibboleth enklast såhär:

# apt-get install libapache2-mod-shib2

Applikationen

Vanliga applikationsmiljöer

  • Om din applikation är skriven helt i php eller python kan det vara intressant att titta på simpleSAMLphp eller pySAML2. Dessa låter dig integrera en SP direkt i din applikation. Detta kräver dock lite mer erfarenhet och Shibboleth i en Apache fungerar väl även för dessa typer av applikationer.
  • Om din applikation är skriven i java rekommenderar vi att du använder en Apache-server som frontend (via mod_proxy_ajp) och låter Shibboleth i SPn sköta inloggning till din applikation. Läs mer om hur du använder Shibboleth och Apache med Java här.
  • Om din applikation är skriven i .NET och kör i IIS så bör du kunna använda WIF (Windows Identity Foundation). Ett annat alternativ som är väl beprövat och fungerar mycket väl ihop med SWAMID är att använda Shibboleth för IIS. Det finns MSI-paket för 32 och 64-bitars Windows på http://shibboleth.internet2.edu/.

Anpassa applikationen

Många web-applikationer stödjer idag någon form av extern inloggning, ofta via LDAP eller Active Directory. Det är mer sällan (ännu) som applikationer stödjer inloggning via en extern identitetsfederation (tex SWAMID). Lyckligtvis är det ofta enkelt att göra anpassningen själv. Många applikationer sköter inloggning via ungefär samma typ av flöde:

  1. Om användaren inte har en aktiv session så skickas användaren till en "välkommst-sida" med publik information. Ibland kan applikationen (tex en wiki) innehålla en mängd information som inte kräver inloggning. I varje vy renderas en Login-knapp (ofta i hövre högra hörnet av sidan).
  2. Användaren klickar på Login-knappen och kommer till en login-vy med ett användarnamn och lösenordsfält.
  3. Användaren skriver in sitt användarnamn och lösenord och klickar på "Login-knappen".
  4. Om inloggningen lyckas skapas en session (som hanteras via en cookie eller en state-parameter i URLen) och användaren skickas tillbaka till applikationen.

Att anpassa en sådan applikation till federerad inloggning är relativt enkelt. Det som krävs är att det går att rendrera en alternativ login-länk som leder till en alternativ login-vy. Detta alternativa flöde fungerar såhär:

  1. Användaren klickar på login-länken som pekar på /Shibboleth.sso/DS/ds.swamid.se?target=https://example.com/alternative-login-view. Denna länk är associerad med en sk SessionInitiator - en länk som startar inloggningen i Shibboleth-modulen i Apache/IIS. Se Discovery Service och WAYF för rekommendation på SessionInitiators för SWAMID. När användaren lyckas logga in via sin IdP i SWAMID skickas han/hon tillbaka till URLen som anges i target-parametern. Denna URL (https://example.com/alternative-login-view) ska vara konfigurerad för Shibboleth i Apache/IIS.
  2. Vyn alternative-login-view i applikationen får nu tillgång till de attribut som är tillgängliga från inloggningen. Dessa attribut (tex namn, epost) kan nu användas för att skapa en ny användare i applikationens interna användardatabas (tänk på att disabla evt interna lösenord) alterntivt uppdatera en existerande användare. I SWAMID kan man nästan alltid utgå att det finns ett permanent "användarnamn" i REMOTE_USER-parametern som kan användas som nyckel i databasen. Dock kan detta värde vara långt och bör inte visas för användaren - använd hellre displayName för personalisering av användarens egna sidor i applikationen. Exakt vilka attribut som finns och hur man kommer överens med IdPer om vilka som ska skickas är en fråga du gärna får ta upp med SWAMID Operations (operations@swamid.se).
  3. Slutligen skapas en session på samma sätt som det normala flödet och användaren skickas vidare till applikationen som vanligt.

Resten av denna artikel beskriver hur du konfigurerar Shibboleth. Om du valt att använda WIF, pySAML2 eller simpleSAMLphp eller någon annan SAML-implementation så får du kolla i dokumentationen för respektive programvara men stegen nedan bör vara ungefär desamma.

Metadata och signaturvalidering

Börja med att ladda ner signerigs-certifikatet för SWAMID från https://md.swamid.se/md/md-signer.crt. Spara det som swamid-signer.crt i /etc/shibboleth (om din SP följer normal katalogstruktur).

Lägg sedan till följande i shibboleth2.xml bland alla andra MetadataProvider-element:

<MetadataProvider 
   type="XML" 
   uri="http://md.swamid.se/md/swamid-1.0.xml"
   backingFilePath="swamid-1.0.xml" reloadInterval="300">
      <SignatureMetadataFilter certificate="swamid-signer.crt"/>
</MetadataProvider>

Notera att metadata med fördel kan laddas ner från http (inte https). Säkerheten i metadata kommer från validering av signaturen på metadatafilen och inte från TLS - https gör ingen nytta i detta fall.

Attribut

Du kommer antagligen att vilja aktivera lite fler attribut än de som är aktiverade per default

Discovery Service och/eller WAYF

För att användarna ska hitta till sina IdPer använder man normalt en speciell tjänst som låter användare välja bland en lista av IdPer. Läs mer om hur du konfigurerar Discovery Service och WAYF i din SP. När du gjort detta är du klar för en omstart av shibd för att ändringarna ska ta effekt.

Omstart och test

# /etc/init.d/shibd restart

Om allt fungerar så ska det straxt skapas en fil /var/run/shibboleth/swamid-1.0.xml med SAML2 metadata i. Om filen inte dyker upp beror det oftast på att shibd inte startar eller på att det smugit sig in något syntaxfel i någon av konfigurationsfilerna. Kolla loggarna!

Registrera tjänsten i SWAMID

För att din tjänst ska kunna logga in via IdP:er i SWAMID måste SPs metadata läggas in i http://md.swamid.se/md/swamid-1.0.xml. Detta åstadkommer du genom att skicka ett mail till operations@swamid.se och tala om vad SPn används till, vem som ansvarar för den samt uppge hostnamnet till SPn. Om du ändrar i konfigurationen i din shibboleth2.xml så kan det betyda att metadata i SWAMID måste uppdateras - skicka isåfall ett nytt mail till operations@swamid.se och tala om vilken SP som ska uppdateras. Detta är speciellt viktigt om du byter nycklar eller certifikat.

  • No labels