Op deze pagina vind je alle veelgestelde vragen (FAQ). Staat jouw vraag er niet tussen en kun je het antwoord ook niet vinden in de rest van de wiki? Stuur je vraag naar het SURFconext-team (support@surfconext.nl).
|
|
|
|
|
|
|
Toelichting
Deze definitie staat in de nieuwe SURFconext bijlage bij de SURFnet gebruiksovereenkomst. Alle aangesloten Identity Providers krijgen die binnenkort (Q3-4, 2013) ter ondertekening toegestuurd. De gehanteerde definitie is ruimer dan vroeger en komt nu overeen met de definitie die SURFmarket gebruikt.
Om de authenticiteit van SAML assertions en authentication responses te verifiëren, gebruik je digitale handtekeningen. Dat betekent dat je ‘signing keys’ moet aanmaken en configureren in je Identity Provider-systeem. Je moet de public signing key publiceren in de vorm van een self-signed certificate in de metadata. De gateway van SURFconext leest deze metadata in, samen met de public key, zodat berichten die van jouw organisatie komen, gevalideerd kunnen worden.
Hoewel SURFconext alleen de public key uit het certificaat gebruikt, vertoont sommige software problemen als er iets mis is met het certificaat, bijvoorbeeld als de geldigheidsduur van het certificaat verloopt. Hieronder lees je aandachtspunten bij het verlopen van token signingcertificaten.
Bij de installatie van de ADFS server is een self-signed tokencertificaat geïnstalleerd met een standaard geldigheidsduur van 1 jaar. Dit certificaat wordt automatisch vernieuwd voordat de geldigheidsduur is verstreken. Volgens de standaardinstellingen wordt 20 dagen voor het verstrijken van het oude certificaat een nieuw certificaat aangemaakt.
Wij raden je aan om de geldigheidsduur van dit certificaat te verlengen tot bijvoorbeeld 5 jaar, omdat Service Providers elke keer dat een cerificate rollover plaatsvindt het nieuwe certificaat moeten importeren. En tot die tijd zal de dienst onbereikbaar zijn voor jouw gebruikers.
Als je het automatisch gegenereerde token signingcertificaat wilt verlengen en vervangen, moet je de volgende stappen doorlopen:
Deze stappen zijn bedoeld voor een nieuwe installatie. Voor een bestaande productie-installatie voer je alleen de stappen 1 t/m 3 uit. De langere geldigheidsduur wordt dan pas van kracht na de eerstvolgende (automatische) rollover.
Add-PSSnapin Microsoft.Adfs.PowerShell
Set-ADFSProperties -CertificateDuration 1825
Update-ADFSCertificate -CertificateType Token-Signing -Urgent
Get-ADFSCertificate -CertificateType Token-Signing
Voor sommige Identity Provider-systemen (bij voorbeeld SimpleSAMLphp) levert het verlopen van het token signingcertificaat geen problemen op. Bij andere software kan dit wel een probleem geven. Ook als die software de geldigheidsduur van certificaten zelf niet kan aanpassen, kun je waarschijnlijk wel een bestaand certificaat importeren. Het certificaat dat je wilt importeren, maak je dan met een andere tool, zoals OpenSSL.
Met OpenSSL kun je een self-signed tokencertificaat aanmaken. Je doet dat met de volgende commando’s:
openssl genrsa -out key.pem 2048 openssl req -new-key key.pem -out req.csr -subj '/CN=idp.example.org Signing Certificate' openssl x509 -req -in req.csr -signkey key.pem -days 1825-out cert.pem |
Als een bestaand certificaat moet worden verlengd (in plaats van een nieuw gegenereerd certificaat), gebruik je het commando:
openssl x509 -in oldcert.pem -signkey key.pem -days 3650-out newcert.pem |
Single Log Out (SLO) betekent dat je in één keer uitlogt bij alle Service Providers tegelijk, nadat je bij 1 Service Provider bent uitgelogd. Het is dus precies het tegenovergestelde van Single Sign On.
SURFconext ondersteunt in de praktijk geen Single Log Out. Hiervoor zouden namelijk alle Service Providers bepaalde technische aanpassingen moeten doen op hun systemen. In de praktijk is het onmogelijk om dit af te dwingen en er zeker van te zijn dat een gebruiker ook daadwerkelijk is uitgelogd wanneer deze op uitloggen heeft geklikt bij een willekeurige andere Service Provider. Vanwege de mogelijke veiligheidsissues die dit met zich meebrengt, ondersteunt SURFconext geen SLO.
De enige echt veilige vorm van SLO is (en blijft) het volledig afsluiten van je browser. Met volledig bedoelen we dat de gebruiker alle vensters en tabbladen moet sluiten en dat de browserapplicatie dus helemaal is afgesloten. Alleen het sluiten van de tabbladen van diensten waar je bent ingelogd via SURFconext is niet voldoende om overal uit te loggen.
Bij sommige browsers, zoals Safari, biedt zelfs het volledig afsluiten van de browser niet genoeg garantie dat de gebruiker volledig is uitgelogd bij alle Service Providers. Gebruikers die inloggen op een publieke of terminal-pc, of de computer van een ander, moeten altijd de privémodus gebruiken om er zeker van te zijn dat de sessie volledig is beëindigd.
Het is essentieel om de gebruikers van jouw organisatie goed te informeren over hoe zij veilig moeten uitloggen, zeker tijdens het gebruik op een publieke of terminalpc of de computer van een ander.
We adviseren je daarom om al bij het inloggen op de webpagina’s te vermelden dat de enige veilige vorm van uitloggen het volledig afsluiten van je browser is.
Op deze pagina staan richtlijnen beschreven voor hoe je de login pagina het beste kan vormgeven.
Zie ook: https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues
Of lees de innovatieblog van SURFnet
De gegevens van de gebruikers blijven in beheer van de organisatie waar ze studeren of werken. Door SURFconext te gebruiken, hoeven inlognamen en wachtwoorden niet worden doorgegeven aan Service Providers. Soms worden er wel attributen (gebruikerskenmerken), zoals naam, doelgroep en opleiding van gebruikers uitgewisseld. Service Providers kunnen hun aanbod daarmee afstemmen op de behoeften van de gebruikers.
SURFconext zorgt ervoor dat alleen de informatie die nodig is, wordt doorgestuurd naar Service Providers. Bij het inloggen ontvangt SURFconext persoonsgegevens van de instelling. SURFconext stuurt deze door naar de Service Provider. Hierbij is SURFconext dus het doorgeefluik.
Organisaties, Service Providers en SURFconext slaan de gegevens op in logfiles. Het doel van deze logfiles is beperkt tot het beheer van de dienst, interne controle van de processen en beveiliging. Dit betekent dat de gegevens in de logfiles alleen voor een bepaalde termijn worden bewaard. Meer informatie over privacy lees je bij Contracten en Privacy.
Persoonsgegevens mogen niet langer bewaard worden dan nodig is voor het doel waarvoor ze zijn verzameld.
Identity Providers
Voor de personeelsregistratie geldt dan dat persoonsgegevens uiterlijk 2 jaar nadat het dienstverband of de werkzaamheden zijn beëindigd, worden verwijderd.
Voor de studentenadministratie geldt dat persoonsgegevens uiterlijk 2 jaar na het beëindigen van de studie worden verwijderd.
Service Providers
In het contract tussen SURFnet en de Service Provider staat dat de persoonsgegevens in het federatiebestand uiterlijk 2 jaar na de laatste transactie van de gebruiker worden verwijderd.
SURFconext
De persoonsgegevens die in de logfiles van SURFconext worden opgeslagen, worden maximaal 6 maanden bewaard. Deze termijn geldt ook voor de logfiles van de Identity Providers en Service Providers.
Meer informatie
Meer informatie over dit onderwerp lees je bij Contracten en Privacy.
Op technisch vlak waarborgen wij de privacy door de gegevens te versleutelen voordat ze worden verzonden.
Maar om de privacy daadwerkelijk te waarborgen, maken wij met alle deelnemers aan SURFconext duidelijke afspraken, zodat de gegevens alleen gebruikt worden voor het doel dat we hebben afgesproken.
De afspraken op het gebied van privacy staan in de ‘Privacy Best Practice’. Dit document is gebaseerd op de Wet bescherming persoonsgegevens (Wbp). In de Privacy Best Practice staat het doel waarvoor persoonsgegevens worden verzameld. Het gebruiken van persoonsgegevens is alleen toegestaan als het noodzakelijk is om dat specifieke doel te bereiken, bijvoorbeeld autorisatie of personalisatie. Daarbij krijgen alleen personen die het echt nodig hebben, toegang tot de persoonsgegevens.
De transparantie voor de gebruiker over het gebruik van zijn persoonsgegevens, wordt gewaarborgd door hem hierover te informeren zodra hij een dienst benadert via SURFconext. Ook zijn er maximale bewaartermijnen voor persoonsgegevens vastgesteld en worden SURFconext-deelnemers verplicht om beveiligingsmaatregelen te nemen om misbruik van de gegevens te voorkomen. Meer informatie over privacy lees je bij Contracten en Privacy. Daar vind je ook het 'Privacy Best Practice' document.
Wij raden je aan om wijzigingen in het Identity Provider-systeem zoveel mogelijk te vermijden. Dit omdat er vrijwel altijd sprake is van een verstoring van de diensten. Die verstoring varieert van 1 werkdag tot 2 weken.
Helaas is het soms onvermijdelijk om iets te veranderen aan je Identity Provider-systeem of aan de configuratie daarvan. Bijvoorbeeld als je overstapt naar een ander softwarepakket, of verhuist naar een andere server.
Maar ook het wijzigen van de inhoud van een attribuut, het vervangen van het certificaat of het aanpassen van de URL van de metadata valt onder een wijziging van je Identity Provider-systeem. Al deze veranderingen hebben impact op de diensten die de gebruikers van je organisatie gebruiken via SURFconext. Vaak zijn 1, meerdere, of alle diensten tijdelijk niet te gebruiken, bijvoorbeeld omdat de gebruikers van je organisatie niet kunnen inloggen. De duur van deze onderbrekingen varieert sterk.
Neem daarom altijd eerst contact op met het SURFconext-team (support@surfconext.nl) om de wijziging(en) met ons te spreken, en om samen de impact te bepalen.
Meer informatie over de procedure voor het vervangen (migreren) van een Identity Provider-systeem lees je bij Veranderingen aanbrengen bestaande Identity Provider.
Het attribuut eduPersonTargetedID is een kopie van de Subject -> NameID welke door SURFconext zelf wordt gezet. Als een Identity Provider de eduPersonTargetedID zelf zet, wordt deze altijd overschreven door SURFconext.
Dit attribuut is in het leven geroepen omdat de Subject -> NameID zelf geen onderdeel is van de SAML v2.0-respons en dus niet gebruikt kan worden. Als SURFconext het attribuut eduPersonTargetedID plaatst, kan de Subject -> NameID wel worden gebruikt.
Je hoeft dit attribuut niet zelf toe te voegen aan je Identity Provider-systeem, omdat SURFconext dit attribuut automatisch vult.
SURFconext bouwt een nieuw NameID op uit schacHomeOrganization + UID. Je ziet deze terug als 'subject' in de debug-pagina van het Engineblok op https://engine.surfconext.nl/authentication/sp/debug. Voorts bepaalt ook het NameIDformat hoe de NameID naar de Service Provider wordt gestuurd. Deze kan zijn:
urn:oasis:names:tc:SAML:2.0:nameid-format:transient urn:oasis:names:tc:SAML:2.0:nameid-format:persistent urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified |
Per Service Provider kan worden bepaald wat het NameIDformat is. Voor de SURFconext Wiki (https://wiki.surfnetlabs.nl/) is de NameIDformat (vooralsnog) unspecified en ziet er als volgt uit:
eduPersonTargetedID=urn:collab:person:surfnet.nl:henny
Je kunt dit onder andere bekijken met de SAML tracer, een plugin voor FireFox. Op deze pagina staat beschreven hoe je SAML tracer kunt gebruiken.
Op de debug-pagina van SURFconext (https://engine.surfconext.nl/authentication/sp/debug) zal je na het inloggen geen eduPersonTargetedID attribuut zien. Dit komt doordat deze pagina alleen informatie laat zien voordat deze gemanipuleerd is (dus voordat SURFconext het eduPersonTargetedID-attribuut heeft gezet). |