Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »

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 (surfconext-beheer@surfnet.nl).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 Welke gebruikers van een organisatie mogen gebruikmaken van SURFconext?
Als gebruiker wordt aangemerkt:
  1. een persoon met een aanstelling dan wel een arbeidsovereenkomst bij de Instelling (organisatie);
  2. een bij de Instelling (organisatie) ingeschreven student, extraneus of cursist;
  3. een persoon die anderszins in het kader van de taakuitvoering van de Instelling (organisatie) geautoriseerd is.

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.

 Hoe verleng ik het token signingcertificaat van mijn Identity Provider-systeem?

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.

Certificaat verlengen in ADFS 2.0

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:

Icon

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.

  1. Start Windows PowerShell.
  2. Laad de ADFS plugin met het commando
    Add-PSSnapin Microsoft.Adfs.PowerShell
  3. Zet de geldigheidsduur van certificaten op 5 jaar (1825 dagen) met:
    Set-ADFSProperties -CertificateDuration 1825
  4. Activeer het nieuwe certificaat met:
    Update-ADFSCertificate -CertificateType Token-Signing -Urgent
    Voer deze stap alleen uit als de server nog niet in productie is genomen. Voor productieservers wacht je tot het eerstvolgende moment waarop een certificate rollover plaatsvindt.
  5. Controleer of het certificaat is verlengd met:
    Get-ADFSCertificate -CertificateType Token-Signing
  6. De verloopdatum van het certificaat staat vermeld onder 'Not After'.

Certificaat verlengen voor andere Identity Provider-systemen

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
 Hoe werkt log out?

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.

Icon

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.

Advies

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.

Meer informatie

Zie ook: https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues

Of lees de innovatieblog van SURFnet

 Wat gebeurt er met de gegevens van gebruikers van SURFconext?

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.

 Hoelang worden de gegevens bewaard die ik via SURFconext doorstuur?

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.

 Hoe waarborgt SURFconext mijn 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.

 Wat is de procedure voor het wijzigen of vervangen (migreren) van een Identity Provider-systeem?

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 (surfconext-beheer@surfnet.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.

 Wat is het attribuut eduPersonTargetedID?

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.

Wat doet SURFconext?

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:

Het transient format is het meest veilig (eenmalige unieke code die per sessie en per Service Provider anders is), daarna het persistent format (unieke code die over meerdere sessies, over meerdere Service Providers en voor langere tijd geldig is) en de unspecified variant is het minst veilig (waarin de UID en de schacHomeOrganization zichtbaar zijn). Deze laatste wordt in verband met inbreuk op de privacy niet meer toegestaan.

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:

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.

Icon

 

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).

 Aan welke eisen moeten de entitlement-attributen voldoen voor de TERENA Personal Certificate Service?

Om een persoonscertificaat te kunnen aanvragen via de TERENA Personal Certificate Services (https://mijncertificaat.surfnet.nl/) moeten de vrijgegeven attributen aan extra eisen voldoen.

Dit attribuut moet gevuld zijn met een waarde die per persoon uniek is en eindigt met de domeinnaam van de betreffende instelling.

Voor een medewerker van de Universiteit van Tilburg is dat bijvoorbeeld @uvt.nl.

De waarde van het surname (sn) attribuut moet overeenkomen met de achternaam in het identiteitsbewijs (zie het voorbeeld onderaan op de pagina).

De eduPersonEntitlement is een multivalued attribuut. Dat wil zeggen dat dit attribuut meerdere waarden mag hebben. Gebruikers die een certificaat mogen aanvragen hebben de waarde 'urn:mace:terena.org:tcs:personal-user' in dit attribuut staan. Alleen accounts van echte personen mogen deze attribuutwaarde krijgen. Het mogen dus geen testaccounts of functionele accounts zijn. Bovendien moeten deze personen een geldig identiteitsbewijs hebben laten zien (face-to-face). Voor personeel in loondienst is dat automatisch al het geval.

Voor administrators wordt daarbij nog een tweede waarde gebruikt: 'urn:mace:terena.org:tcs:personal-admin'. Deze waarde wordt alleen gebruikt bij gemachtigden (administrators). Zij krijgen extra rechten in de webapplicatie, zoals het intrekken van certificaten (revocation) en het wijzigen van bepaalde informatie, zoals telefoonnummers. Log in op de debug-pagina van SURFconext (https://engine.surfconext.nl/authentication/sp/debug) om te controleren of jouw account de juiste attributen levert. Meer informatie over het toevoegen van dit attribuut lees je bij Hoe geef ik het eduPersonEntitlement attribuut mee?

Voorbeeld

 Hoe wordt het UID-attribuut door SURFconext en aangesloten diensten gebruikt?

Een van de attributen in het schema van SURFconext is het UID attribuut (urn:mace:dir:attribute-def:uid) Op welke wijze wordt dat gebruikt binnen SURFconext door de aangesloten diensten?

  • SURFconext gebruikt de waarde van het UID-attribuut als onderdeel van de primaire identifier voor gebruikers in SURFconext. Om precies te zijn in een combinatie met de waarde van het schacHomeOrganization-attribuut (urn:mace:terena.org:attribute-def:schacHomeOrganization).
    De reden dat wij UID gebruiken is omdat UID per definitie uniek is binnen een organisatie. UID is een van de twee vereiste attributen die een identity provider moet leveren om aan te kunnen sluiten op SURFconext (zie ook: Vereiste attributen).
  • Als  een Service Provider er om vraagt (en de Identity Provider toestemming geeft) kan deze ook het UID-attribuut krijgen. SURFconext geeft op dat moment de waarde door die door de Identity Provider is aangeleverd. Sommige Service Providers zullen dit atribuut gebruiken als (basis voor) een identifier. Het komt zelden voor dat dit attribuut aan een gebruiker getoond word.
  • Naast bovenstaand 'interne' gebruik binnen SURFconext, geven wij standaard ook een identifier (de zogenaamde SAML name-ID) aan Service Providers. Deze Identifier is persistent, en niet rechtstreeks tot de gebruiker te herleiden voor de dienst. De identifier is gebaseerd op de door door de instellingen geleverde UID. Diverse diensten gebruiken deze name-ID (of het afgeleide attribuut 'eduPersonTargetedID') als identifier, en wij moedigen Service Providers aan specifiek dat te gebruiken, in plaats van het UID-attribuut.

Kijk voor meer informatie over attributen op de pagina Attributen in SURFconext (NL).

 Hoe voeg ik het eduPersonAffiliation-attribuut toe?

Het 'urn:mace:dir:attribute-def:eduPersonAffiliation'-attribuut geeft aan welke relatie je als gebruiker hebt met jouw organisatie. SURFspot gebruikt dit attribuut bijvoorbeeld om je naar de juiste 'winkel' te sturen.

Voor studenten heeft dit attribuut de waarde 'student'. Voor medewerkers heeft dit attribuut de waarde 'employee'. De naam en de waarde van dit attribuut zijn hoofdlettergevoelig.

Wil je controleren of dit attribuut voor jou als gebruiker goed wordt doorgegeven? Log dan in op de debug-pagina van SURFconext: https://engine.surfconext.nl/authentication/sp/debug.

Attribuut vrijgeven in ADFS 2.0

Identity Providers die ADFS 2.0 gebruiken, kunnen het vrijgeven van attributen regelen via de GUI. Zorg er eerst voor dat alle studenten in een Windows Security Group zitten, en alle medewerkers in een andere Windows Security Group. Op basis van de Windows Security-groepen voeg je conditioneel een attribuut met een bepaalde waarde toe. Dat gebeurt met een 'Send Group Membership as a Claim'-rule.

Om dit attribuut vrij te geven, moet de volgende stappen doorlopen:

  1. Open de ADFS 2.0 Management utility.
  2. Selecteer 'ADFS 2.0 -> Service -> Claim Descriptions'.
  3. Kies 'Add Claim Description...'.
  4. Vul de Display name met 'eduPersonAffiliation' en de 'Claim identifier' met 'urn:mace:dir:attribute-def:eduPersonAffiliation'.
  5. Kies 'OK'.
  6. Selecteer 'ADFS 2.0 -> Trust Relationships -> Relying Party Trusts'.
  7. Selecteer 'wayf.surfnet.nl' en kies voor 'Edit Claim Rules...'.
  8. Kies 'Add Rule...'.
  9. Kies 'Send Group Membership as a Claim' en kies 'Next'.
  10. Vul de 'Claim rule name' met 'eduPersonAffiliation student', de 'User's group' met de Security Group waarin de studenten zitten en de 'Outgoing claim value' met 'student' en kies 'OK'.
  11. Kies nogmaals 'Add Rule...'.
  12. Kies 'Send Group Membership as a Claim' en kies 'Next'.
  13. Vul de 'Claim rule name' met 'eduPersonAffiliation employee', de 'User's group' met de Security Group waarin de medewerkers zitten en de 'Outgoing claim value' met 'employee' en kies 'OK'.
 Hoe geef ik het eduPersonEntitlement-attribuut mee?

Diensten die het 'urn:mace:dir:attribute-def:eduPersonEntitlement'-attribuut gebruiken, kunnen hiermee zien wat de toegangsrechten van een bepaalde gebruiker zijn. Het wordt bijvoorbeeld gebruikt door de TERENA Certificate Services:

Zie ook het antwoord op de vraag Aan welke eisen moeten de entitlement-attributen voldoen voor de TERENA Personal Certificate Service?.

Attribuut vrijgeven in ADFS 2.0

Het eduPersonEntitlement-attribuut is een een multi-value string. Het kan dus meer dan 1 waarde doorgeven. In het geval van 'AD' als 'attribute store' moet je dus een AD-veld gebruiken dat multi-value strings ondersteunt. Daar zijn er niet zo veel van. Een goede keuze is bijvoorbeeld altSecurityIdentities.

Om het eduPersonEntitlement/attribuut vrij te geven, moet je de volgende stappen doorlopen:

Op de federatie (ADFS)-server:

  1. Open 'ADFS 2.0 management console'.
  2. Ga naar 'AD FS 2.0 -> Service -> Claim Descriptions'.
  3. Kies 'Add Claim Description ...'
    1. Display name: urn:mace:dir:attribute-def:eduPersonEntitlement
    2. Claim type: urn:mace:dir:attribute-def:eduPersonEntitlement
    3. Belangrijk! Selecteer beide checkmarks bij 'Publish this claim description ...' Doe dit bij alle 'Claim Descriptions' die je zelf hebt toegevoegd.
  4. Kies 'Finish'.
  5. Ga naar AD FS 2.0: 'Trust Relationships -> Relying Party Trusts'. Klik de productiesettings aan (die met 'Identifier wayf.surfnet.nl') of de testsettings (die met 'Identifier wayf-test.surfnet.nl').
  6. Kies 'Edit Claim Rules ...'
  7. Kies 'Add Rule : Next'
    1. Voer de naam in voor de rule, bijvoorbeeld 'Persoon eduPersonEntitlement'
    2. Attribute store: Active Directory
    3. LDAP Attribute: altSecurityIdentities
    4. Outgoing Claim Type: urn:mace:dir:attribute-def:eduPersonEntitlement
  8. Kies 'Finish'.

Op de domein controller:

  1. Vul in AD meerdere waardes in voor de gebruiker in het veld 'altSecurityIdentities'. Bijvoorbeeld:
    1. urn:mace:terena.org:tcs:personal-admin
    2. urn:mace:terena.org:tcs:escience-user
    3. urn:mace:terena.org:tcs:escience-admin
    4. urn:mace:terena.org:tcs:personal-user
  2. Controleer de werking via https://wayf.surfnet.nl/attributes. De waardes moeten als volgt op aparte regels staan:
    1. urn:mace:dir:attribute-def:eduPersonEntitlement urn:mace:terena.org:tcs:personal-admin
    2. urn:mace:dir:attribute-def:eduPersonEntitlement urn:mace:terena.org:tcs:escience-user
    3. urn:mace:dir:attribute-def:eduPersonEntitlement urn:mace:terena.org:tcs:escience-admin
    4. urn:mace:dir:attribute-def:eduPersonEntitlement urn:mace:terena.org:tcs:personal-user
 Hoe geef ik het schacHomeOrganisation-attribuut mee?

Het 'urn:mace:terena.org:attribute-def:schacHomeOrganization'-attribuut identificeert de organisatie van een gebruiker. De waarde van dit attribuut is een RFC1035-domeinaam, bijvoorbeeld 'surfnet.nl'. Voor alle gebruikers van een Identity Provider heeft dit attribuut dezelfde waarde. De waarde die je toekent, is het hoofddomein van de organisatie.

Attribuut vrijgeven in ADFS 2.0

Voor Identity Providers die ADFS 2.0 gebruiken, kunnen het vrijgeven van attributen regelen via de GUI. De truc is om een 'Send Group Membership as a Claim' te gebruiken met als groep 'Domain Users'. Het attribuut wordt dan aan alle gebruikers toegevoegd.

Om dit attribuut vrij te geven moet je de volgende stappen doorlopen:

  1. Open de ADFS 2.0 Management utility.
  2. Selecteer 'ADFS 2.0' -> 'Service' -> 'Claim Descriptions'.
  3. Kies 'Add Claim Description...'.
  4. Vul de 'Display name' met 'schacHomeOrganization' en de 'Claim identifier' met 'urn:mace:terena.org:attribute-def:schacHomeOrganization'.
  5. Kies 'OK'.
  6. Selecteer 'ADFS 2.0' -> 'Trust Relationships' -> 'Relying Party Trusts'.
  7. Selecteer 'wayf.surfnet.nl' en kies voor 'Edit Claim Rules...'.
  8. Kies 'Add Rule...'.
  9. Kies 'Send Group Membership as a Claim' en kies 'Next'.
  10. Vul de 'Claim rule name' met 'schacHomeOrganization', de 'User's group' met 'Domain Users' en de 'Outgoing claim value' met de gewenste waarde en kies 'OK'.

Attribuut vrijgeven in SimpleSAMLphp

Je voegt een attribuut met een constante waarde toe door het bestand 'config/config.php' te wijzigen. Voeg in deze file het volgende toe, onder de entry voor 'authproc.idp':

 

10=> array(
    'class'=> 'core:AttributeAdd',
),

 

Vul voor 'example.org' de gewenste waarde van het schacHomeOrganization attribuut in.

De index in de 'authproc.idp' moet uniek zijn. In het voorbeeld is deze 10. Is die waarde al in gebruik? Kies dan een andere.

Zie de simpleSAMLphp-documentatie voor meer informatie: http://simplesamlphp.org/docs/stable/core:authproc_attributeadd.

 Kan ik TMG gebruiken als proxy voor ADFS 2.0?

 

Je kunt TMG gebruiken als proxy voor ADFS 2.0. In de installatiehandleiding voor het aansluiten van een Active Directory Federation Services (ADFS) 2.0 Identity Provider op SURFconext staat hoe je een proxyserver inricht op basis van ADFS. Er zijn diverse instellingen die al een MS Thread Management Gateway (TMG) hebben, en deze als proxy gebruiken in plaats van de ADFS-proxy.

Er is (nog) geen handleiding die speciaal voor SURFconext beschrijft hoe je TMG configureert. Op Microsoft Technet staat wel een artikel dat de installatie beschrijft: http://social.technet.microsoft.com/wiki/contents/articles/7877.configuring-tmg-as-an-ad-fs-2-0-proxy.aspx

 

Let er bij het configureren van de proxy op dat je de SAML 2.0-metadata zonder authenticatie beschikbaar maakt. Het gaat hier om de url: https:///FederationMetadata/2007-06/FederationMetadata.xml.

 Wat gaat er veranderen bij SURFguest? (IdP)


Tot op heden faciliteerde SURFnet de toegang van externen tot online diensten via een eigen gast-IdP: SURFguest

Vanaf maandag 2 september zullen wij voor gast-toegang tot op SURFconext aangesloten diensten geleidelijk aan overschakelen op Onegini. Onegini is een nieuwe manier van inloggen waarbij een gebruiker zijn social account (Facebook, Twitter, LinkedIn, Google) gebruikt. Gebruikers hoeven zo geen aparte gebruikersnaam en wachtwoord meer te onthouden. SURFguest gebruikers krijgen vanaf 2 september per mail het verzoek om uiterlijk 31 december 2013 hun huidige SURFguest account om te zetten naar Onegini. Na de omzetting kan de gebruiker met zijn social account inloggen via Onegini en heeft hij toegang tot dezelfde applicaties en content als voorheen via SURFguest.

Deze FAQ-pagina geeft meer achtergrond bij de overgang van SURFguest naar Onegini.

Wat is Onegini?

Onegini is een nieuwe manier van inloggen waarbij een gebruiker zijn social account (Facebook, Twitter, LinkedIn, Google) gebruikt. De gebruiker hoeft dan geen aparte gebruikersnaam en wachtwoord meer te onthouden.

Waarom wordt SURFguest vervangen door SURFguest?

Op verzoek van gebruikers willen we het inloggen via een social account (Facebook/LinkedIn/Google/Twitter) mogelijk maken. Hiermee wordt SURFguest overbodig.

Wat is het verschil tussen een gast-account en een instellingsaccount?

Onegini accounts zijn gebaseerd op social accounts (Facebook/LinkedIn/Google/Twitter). Dat noemen we ook wel ‘self asserted accounts’. Dat betekent dat de identiteit door de gebruikers zelf is opgegeven en niet geverifieerd is. Dit betekent dat je geen zekerheid hebt over de juistheid van de identiteit die de gebruiker heeft opgegeven. Dit resulteer in een laag ‘Level of Assurance’ (LoA). Dit is anders dan bij de uitgifte van een instellingsaccount, waar een uitgebreid identificatieproces aan vooraf gaat.

Sommige Service Providers besluiten daarom om gast-gebruikers minder rechten in hun applicatie te geven dan gebruikers met een instellingsaccount. Dit verschilt echter per SP.

Welke Service Providers staan gast-gebruik toe?

Een beperkt aantal Service Providers staat gast-gebruik via Onegini (en voorheen via SURFguest) toe. Wanneer een Service Provider Onegini heeft opgenomen in het selectiescherm met Identity Providers (ook wel WAYF ‘Where are you From’ genoemd), ondersteunt hij gastgebruik.

Tot wanneer hebben gebruikers de tijd om hun SURFguest account te migreren naar Onegini?

Gebruikers hebben tot 31 december 2013 de tijd om hun SURFguest account te migreren naar Onegini. In de tussentijd kunnen zij zowel via Onegini als SURFguest inloggen bij Service Providers, maar vanaf 1 januari 2014 alleen nog maar via SURFguest.

Waar kan ik documentatie over Onegini voor eindgebruikers en Service Providers vinden?

Op de SURFnet wiki staat meer informatie over Onegini die toegespitst is op:

Eindgebruikers

Service Providers

Hoe is de rolverdeling tussen Onegini & SURFconext?

SURFconext heeft een contract met Onegini voor het leveren van een applicatie voor gasttoegang tot applicaties van derden op basis van een social account. In dat contract zijn goede afspraken gemaakt over de continuiteit van Onegini, de service levels en hoe Onegini  omgaat met privacy en beveiliging van data.

Meer informatie over Onegini:

Meer informatie over Onegini kan je vinden op de website van Onegini

 

 

 

 

 

 

 

 

 

 

  • No labels