...
Instellingen kunnen SURFsecureID aanvragen via het SURFdashboard. Alleen contactpersonen van de instelling die bij SURFnet SURF bekend zijn als Instellingscontactpersoon (ICP) of Instellingsbevoegde (BVI) kunnen deze aanvraag doen. NB: SURFsecureID is alleen beschikbaar voor instellingen die reeds als Identity Provider zijn aangesloten op SURFconext.
...
| SURFsecureID onderdeel | Gebruikte attributen |
|---|---|
| SURFsecureID Registratieportal | SURFnet SURF | urn:mace:dir:attribute-def:cn |
| SURFsecureID RA Management Portal | SURFnetSURF | urn:mace:dir:attribute-def:cn |
...
De RAA (Registration Authority Administrator) rol wordt vervuld door één of enkele medewerker(s) van de instelling. Dit gaat om bijvoorbeeld instellingscontactpersonen (ICP's), SURFconext contactpersonen of security officers. Tijdens de entryprocedure wordt de eerste RAA geautoriseerd door een een medewerker van SURFnetSURF. Daarna kan hij of zij andere personen binnen de instelling RA(A) maken.
...
Onderstaand overzicht laat zien wat er in welke situatie nodig is om een dienst met SURFsecureID in gebruik te kunnen nemen, met een indicatie van de doorlooptijd die daarmee gemoeid is. Let wel: een en ander is sterk afhankelijk van de medewerking door de betreffende leverancier en de gekozen implementatie. Instelling, SURFnet SURF en de dienstleverancier zullen wanneer zij dit proces ingaan het verwachtingsmanagement goed op elkaar moeten afstemmen.
| Startsituatie | Proces | Use-case | Doorlooptijd |
|---|---|---|---|
1. Dienst is reeds aangesloten op SURFsecureID gateway | Er is alleen een akkoord nodig van de SURFconextverantwoordelijke bij de instelling om deze dienst in gebruik te nemen. | 2 | Kort. ca. 1-2 werkdagen |
| 2. Dienst is aangesloten op SURFconext, maar nog niet op de SURFsecureID gateway | Er is actie van de dienstleverancier nodig om de dienst technisch aan te sluiten op de SURFsecureID gateway. Contractueel zijn er geen aanpassingen nodig. In onze documentatie voor dienstleveranciers (Service Providers) staat beschreven wat moet gebeuren om aan te sluiten op SURFsecureID Gateway. Hoeveel werk dit is, hangt helemaal af van de gekozen implementatie. Wanneer de dienstleverancier besluit om de dienst aan de 'buitenkant' in zijn geheel met sterke authenticatie af te schermen, dan is dit releatief weinig werk. In feite hoeft de dienst alleen een ander endpoint te configureren. Soms is het echter wenselijk om de sterke authenticatie meer als een step-up authenticatie te laten functioneren. D.w.z. dat sterke authenticatie pas getriggerd wordt wanneer de gebruiker een bepaalde functie in de dienst benadert, bijv. bij alleen het invoeren van tentamencijfers en niet bij het inzien van deze cijfers. Dit vergt meer logica dieper in de dienst en kost daarom ook meer ontwikkeltijd. | 2 | Gemiddeld. ca. 1-16 weken. |
| 3. Dienst is aangesloten op een centrale authenticatie voorziening van de instelling zoals ADFS, Citrix, BigIP F5. | In deze situatie sluit niet de dienst aan op SURFsecureID, maar is het de centrale authenticatie voorziening die dit doet. Deze voorziening moet zelf de 1e factor (gebruikersnaam/wachtwoord) controleren en roept indien nodig SURFsecureID aan voor de 2e factor. Zo kan de instelling tweefactorauthenticatie aan- of uitzetten voor verschillende diensten en groepen gebruikers met 1 koppeling tussen de centrale voorziening en SURFsecureID. Voor een aantal centrale authenticatie voorzieningen bestaan kant-en-klare oplossingen die snel te implementeren zijn:
Andere authenticatie voorzieningen die op deze manier SURFsecureID willen inzetten zullen zelf de SFO koppeling moeten realiseren. Dit kost meer ontwikkeltijd. Als de centrale authenticatie voorziening van een instelling is zijn er contractueel geen aanpassingen nodig. Mocht een dienstleverancier deze methode gebruiken, dan zal eerst het reguliere aansluitproces voor Service Providers doorlopen moeten worden. | 1 | Gemiddeld. ca. 1-16 weken. |
| 4. Dienst is niet aangesloten op SURFconext, SURFsecureID of via een centrale authenticatie voorziening | Samen met de instelling zal de dienstleverancier eerst moeten bepalen hoe zijn dienst gekoppeld kan worden aan SURFsecureID. Dit kan via een van de twee ondersteunde use-cases; direct aan SURFsecureID (zie scenario 2 hierboven) of via een centrale authenticatie voorziening (zie scenario 3 hierboven). Indien de dienst direct op SURFsecureID aansluit zal eerst het reguliere aansluitproces voor Service Providers doorlopen moeten worden om aan te sluiten op SURFconext. Dit aansluitproces bestaat uit een technische en organisatorische component. Aanvullend dient ook nog een koppeling met de SURFsecureID gateway gemaakt te worden. Hierbij geldt ook weer: de hoeveelheid werk die hiermee gemoeid is, hangt helemaal af van de gekozen implementatie. | 1 of 2 | Langer. ca. 4-24 weken |
...
Zodra de relevante dienst beschikbaar is via de SURFsecureID gateway kan de instelling in samenwerking met SURFconext en de dienstleverancier een functionele test uitvoeren om vast te stellen dat Sterke Authenticatie via SURFconext werkt. Tijdens een finale check tussen instelling, SURFnet SURF en dienstleverancier wordt een go/ no go beslissing genomen voor het in gebruik nemen van de koppeling met SURFsecureID. De koppeling wordt dan overgeheveld naar onze productieomgeving en is daarna klaar voor gebruik.
...
Wanneer de instelling op een later tijdstip ook andere diensten via SURFsecureID wil gaan gebruiken, dan kan de instelling dat kenbaar maken via support@surfconext.nl. In overleg worden stap 4 en 5 uit dit stappenplan dan nogmaals doorlopen.
SURFnet SURF zal tevens de facturatie voor het gebruik van SURFsecureID starten vanaf de maand na in productiename.
...