...
- 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:
- 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).
- Användaren klickar på Login-knappen och kommer till en login-vy med ett användarnamn och lösenordsfält.
- Användaren skriver in sitt användarnamn och lösenord och klickar på "Login-knappen".
- 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:
- Användaren klickar på login-länken som pekar på
/Shibboleth.sso/Login?target=http://your.app/alternative-login-view. Denna länk är associerad med en sk SessionInitiator - en länk som startar inloggningen i Shibboleth-modulen i Apache/IIS. 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 ska vara konfigurerad för Shibboleth i Apache/IIS. - Applikationen (alternative-login-view) kan får nu tillgång till de attribut som är tillgängliga från inloggningen. Dessa attribut 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.
- 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.
...