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 5 Next »

Space Index

Total number of pages: 96

0-9 ... 0 A ... 6 B ... 0 C ... 5 D ... 5 E ... 2
F ... 9 G ... 0 H ... 6 I ... 3 J ... 0 K ... 0
L ... 1 M ... 1 N ... 0 O ... 1 P ... 0 Q ... 0
R ... 5 S ... 20 T ... 13 U ... 4 V ... 1 W ... 0
X ... 0 Y ... 3 Z ... 0 !@#$ ... 0    

0-9

A

Page: Aandachtspunten voor RA
Er zijn een aantal aandachtspunten waar een instelling bij het inrichten van het registratieproces rekening mee moet houden: Geldige legitimatiebewijzen De volgende documenten gelden als geldig legitimatiebewijs: Paspoort Rijbewijs Identiteitskaart NB: ee
Page: Aansluiten op de SURFsecureID Pilot Omgeving
Voor het doen van pilots met SURFsecureID heeft SURFnet een Pilot omgeving beschikbaar. Deze omgeving kan door instellingen, en ook door service providers, gebruikt worden om sterke authenticatie uit te proberen in de eigen omgeving. De pilot omgeving sta
Page: Aanvragen SURFsecureID
Het aanvraagproces voor instellingen die gebruik willen maken van SURFsecureID kent een aantal stappen. In overleg met de betrokken instelling kunnen een aantal van deze stappen parallel of in een andere volgorde uitgevoerd worden. Weet u nog niet zeker o
Page: Azure MFA
Je hebt al een Azure MFA token geregistreerd voor je instelling. Je kunt dit controleren door naar deze pagina van Microsoft https://account.activedirectory.windowsazure.com/proofup.aspx te gaan en in te loggen met je instellingsaccount Voor SURFsecureID
Page: Azure MFA (EN)
You have already registered an Azure MFA token for your institution. You can check this by going to this page from Microsoft https://account.activedirectory.windowsazure.com/proofup.aspx and logging in with your institution account For SURFsecureID, it do
Page: Azure MFA als authenticatiemiddel
Achtergrond Azure MFA en SURFsecureID ondersteunen elk verschillende typen 2FA-middelen. Voor gebruikers is het onhandig en verwarrend als zij verschillende 2FA-middelen naast elkaar moeten gebruiken. Bijvoorbeeld voor de ene applicatie de Microsoft Authe

B

C

Page: Configureer Azure AD voor SURFsecureID koppeling
image2020-6-8_16-58-46.png Voer onderstaande stappen uit op je instellings Azure AD om de koppeling met SURFsecureID te maken. Geef de gevraagde informatie door aan support@surfconext.nl. mailto:support@surfconext.nl. Geef ook aan dat je via Azure AD wilt
Page: Configuring a Shibboleth SP for SURFsecureID
Request authentication at a specific LoA An example Apache configuration snippet where a request for a specific URL triggers a SAML request with LoA 2. The LoA identifier (http://surfconext.nl/assurance/loa2) in the example below is specific for the Produ
Page: Configuring a simpleSAMLphp SP for SURFsecureID
The sp.php script below shows how you can use SimpleSAMLphp to: Request a specific minimum level op assurance (LoA) from the SURFsecureID gateway Verify the LoA at which the user is authenticated To use this scripts: Configure a SimpleSAMLphp SAML 2.0 hos
Page: Connecting your service to SURFsecureID
Depending on the integration option you choose for your service, you need to follow a different connection procedure and technical implementation. 1) SFO authentication Procedural An institution must give permission for a SFO integration in the SURFsecure
Page: Contact and support
Support for connected IdPs and SPs The SURFconext team is the first point of contact for all questions, issues or incidents regarding SURFsecureID. The SURFconext team offers support to all Identity Providers and Service Providers, as well as users that a

D

Page: Diensten met SURFsecureID
Om gebruik te maken van SURFsecureID moet de dienst of voorziening worden gekoppeld. Op deze pagina wordt een overzicht gegeven welke diensten een koppeling hebben met SURFsecureID (in de pilot- of de productieomgeving): MS ADFS Office 365 Citrix Netscal
Page: Differences between options
The table below shows the differences for a service between the two authentication options. Note that both options can be used by an institution protecting it's services. For each service the most appropriate integration option can be chosen. Feature Stan
Page: Differences between SURFconext and SURFsecureID
This page describes the differences between SURFconext and SURFsecureID that are relevant for a SAML service provider (SP) that is migrating from SURFconext to the SURFsecureID gateway, or that is using both simultaneously. Note that this is only relevant
Page: Documentatie voor instellingen
Op de volgende pagina's vindt u alle relevante informatie voor instellingen die in hun rol van Identity Provider SURFsecureID willen gaan gebruiken. Technisch zijn er geen aanpassingen nodig aan uw Identity Provider software, op organisatorisch vlak dient
Page: Documentation for Service Providers 
For Service Providers there are normally no changes needed to make use of SURFsecureID. To require SURFsecureID for all logins to a specific Service Provider, or for all logins by one or more IdP's to a specific Service Provider, the SURFconext team can s

E

Page: Environments overview
SURFsecureID has three environments that can be used. The table below shows the differences between these environments. header-logo-test.png header-logo-pilot.png header-logo.png Environment for testing purposes only Uses IDP's from SURFconext Test enviro
Page: Error code 32881
Description During token registration, you get an error page with error code 32881 Solution This error occurs when your institution does not sent your email address https://wiki.surfnet.nl/display/surfconextdev/Attributes+in+SURFconext#AttributesinSURFcon

F

Page: FAQ SURFsecureID
Waarom moet ik mij identificeren? Jouw instelling wil zeker weten dat diensten en gegevens veilig en alleen toegankelijk zijn voor geautoriseerde personen. Voor toegang tot extra gevoelige diensten of gegevens wordt SURFsecureID ingezet. De instelling wil
Page: FAQ SURFsecureID (EN)
Why do I need to identify myself? Your institution wants to make sure that services and data are safe and only accessible to authorized persons. SURFsecureID is used for access to extra sensitive services or data. The institution then wants to be more sur
Page: FIDO2
Je hebt een FIDO2 token nodig en een recente browser. Niet alle FIDO2 tokens worden door SURFsecureID ondersteund. Kijk hier voor een overzicht van ondersteunde FIDO2 tokens. Neem contact op met jouw instelling om een FIDO2 token te verkrijgen, of bestel
Page: FIDO2 (EN)
You need a FIDO2 token and a recent browser. Not all FIDO2 tokens are supported by SURFsecureID. Look here for an overview of supported FIDO2 tokens. Contact your institution to obtain a FIDO2 token, or order one online. Access to your institution's mail
Page: FIDO2 tokens
De Microsoft Office desktop of mobile applicatie werken met een ingebouwde browser die de FIDO/webauthn standaard (nog) niet ondersteunt. De login met een FIDO token werkt dan ook niet voor deze applicaties. Achtergrond FIDO is een technologie waarmee vei
Page: For a service
Introduction A service can connect to SURFconext or SURFsecureID to handle it's strong authentication login. There are only a few differences between both options. But whenever possible, connect your service to SURFconext as this is the preferred method.
Page: For an institution
Introduction An institution can use SURFsecureID to add a second authentication factor to any service or facility. This is most valuable when added to an existing, central (authentication) facility. For instance, if an institution uses Microsoft ADFS to s
Page: Foutcode 32881
Beschrijving Tijdens de registratie van je token krijg je de foutcode 32881 Oplossing Deze fout treed op als je instelling jouw email adres https://wiki.surfnet.nl/display/surfconextdev/Attributes+in+SURFconext#AttributesinSURFconext-mail of volledige naa
Page: Frequently Asked Questions
Should my application be web based to connect to SURFsecureID? Yes. The main technical prerequisite is that a Service Provider must connect via SAML 2.0 using the Web Browser SSO profile. Can institutions from secondary vocational-, higher education and r

G

H

Page: Handleiding RA Management portal
Medewerkers die de rol Registration Authority (RA) hebben, vormen een belangrijke schakel in het proces om sterke authenticatie voor een gebruiker mogelijk te maken. De kracht van een sterkere vorm van authenticatie valt of staat bij het verifiëren van de
Page: Handleiding RA-admin
Medewerkers die de rol Registration Authority Admin - afgekort RA-admin of RAA - hebben, vormen een belangrijke schakel in het proces om sterke authenticatie binnen de instelling mogelijk te maken. De kracht van een sterkere vorm van authenticatie valt of
Page: Handleiding Registratieportal
Deze handleiding is voor alle gebruikers die een token willen registreren voor SURFsecureID. Gebruikers kunnen een authenticatie token kiezen via een Registratieportal https://sa.surfsecureid.nl/. De volgende tokens zijn beschikbaar: SMS tiqr YubiKey Inho
Page: Help er gaat iets mis
Krijg je een foutmelding tijdens het gebruik van SURFsecureID? De kans is groot dat het een van onderstaande foutmeldingen betreft. Lees hier meer over wat de foutmelding betekent en wat je kunt doen om het probleem te verhelpen. Staat jouw foutmelding er
Page: Help, something is wrong
Do you receive an error whilst using SURFsecureID? Chances are you're receiving one of the errors on this page. You can read what your error means and what you can do to fix this problem. If your error is not on this page, or the problem persists after tr
Page: Het Instellingsconfiguratie scherm
In het instellingsconfiguratie scherm kan de RAA voor iedere instelling waarvoor hij / zij de RAA rol heeft de actuele instellingsconfiguratie inzien. De RAA kan deze configuratie niet wijzigen, alleen medewerkers van SURFnet kunnen dit. Neem contact op m

I

Page: Inrichten registratieproces
Het proces waarin een fysieke persoon gelinkt wordt aan zijn digitale identiteit en zijn authenticatiemiddel is cruciaal om misbruik en identiteitsfraude tegen te gaan. SURFsecureID is daarom zo ontworpen dat een token met zekerheid gekoppeld wordt aan de
Page: Installatie ADFS MFA Extensie
SURFnet heeft een multifactor authenticatie (MFA) extensie ontwikkeld voor Microsoft AD FS voor gebruik met SURFsecureID. Met deze extensie kan de tweede factor van een gebruiker in SURFsecureID worden gebruikt voor MFA authenticatie in AD FS. De registra
Page: Introduction to SURFsecureID
SURFsecureID gives institutions secure access to services. Better security is particularly critical for services handling sensitive data. Such services require stronger forms of authentication than a username and password in order to limit the risk of sec

J

K

L

Page: Levels of Assurance
When users access online services, they want to be confident that their data and services are secure and their privacy is protected. Institutions and Service Providers that offer online services also need to verify a user's identity to make sure only the

M

Page: Manual RA Management portal
Employees with the role Registration Authority (RA), have an important role in facilitating strong authentication to users. The process by which a physical person is linked to his/her digital identity information and to his/her authentication credential i

N

O

Page: Ondersteunde FIDO2 tokens
SURFsecureID ondersteunt het gebruik van FIDO tokens (ook authenticators of security keys genoemd). Zowel FIDO U2F als FIDO2 tokens kunnen hierbij als 2e factor worden gebruikt. De FIDO protocollen zijn gestandaardiseerd, waardoor tokens van verschillende

P

Q

R

Page: RA locaties beheren
Voor instellingen zijn er twee mogelijkheden om aan te geven waar gebruikers hun tokens moeten activeren: RA-locaties: de RA(A) kan verschillende locaties configureren met naam, locatie en contactgegevens die worden getoond aan de gebruikers. RA-contactpe
Page: RA-rollen toewijzen
Introductie Medewerkers die de Registration Authority (RA) rol hebben zijn mogen tokens (SMS, tiqr, YubiKey) van gebruikers activeren nadat zij succesvol vastgesteld hebben dat de gebruiker: is wie hij zegt te zijn bezit van het aangevraagde token kan aan
Page: Registratieportal - Pagina niet gevonden
Voorbeeld Screen Shot 2018-06-14 at 13.29.27.png Beschrijving Tijdens de registratie van je token volg je de email verificatie link en krijgt deze foutcode Oplossing Deze fout treed op als de email verificatie link niet correct is. Dit kan veroorzaakt wor
Page: Registration portal - Page not found
Example Screen Shot 2018-07-17 at 11.35.32.png Description During the token registration process, you follow the email verification link and get this error. Solution This error occurs when the email verification link is not correct. This can occur when: T
Page: Roadmap
It is our ambition to let SURFsecureID grow into the default strong authentication solution for Dutch education and research institutions. The following activities are planned: Remote registration facility Preliminary research is done https://www.surf.nl/

S

Page: SAML message examples
Requesting authentication at a specific LoA A SP can request authentication at a specific LoA by specifying that LoA in the AuthnRequest. Note that an SP can send an AuthnRequest to the gateway at any time, also when a user is already logged in at the SP.
Page: Second Factor Only (SFO) Authentication
Introduction Second Factor Only authentication allows a SP to authenticate only the second factor of a user. SFO is suitable for situations where the application must perform the fist factor authentication of the user like that application gateway (e.g. C
Page: Service Provider Techical Requirements
On this page we provide a list of the technical requirement that a service provider's SAML implementation must meet in order to connect to the SURFsecureID gateway. Sending the Authentication Request To initiate a authentication the SP must send a SAML 2.
Page: SMS
Een mobiele telefoon (werk of privé) die SMS kan ontvangen is vereist. Toegang tot het mailaccount van jouw instelling. Basics Gebruik je telefoon zorgvuldig Jouw telefoon is privé, deel deze niet met anderen. Verlies je telefoon niet uit het oog. Vergren
Page: SMS (EN)
You will need a mobile phone (work or private) that can receive SMS text messages. You will need access to your institutional e-mail account. Basics Handle your phone with care Your phone is private, do not share your phone with others. Never leave your p
Page: SMS als tweede factor?
Het gebruik van SMS voor twee-factor authenticatie is altijd nog beter dan geen tweede factor, maar er zijn andere, modernere en veiligere twee-factor authenticatiemiddelen beschikbaar voor SURFsecureID, zoals tiqr, Yubikey en binnenkort FIDO2. We laten h
Page: Stepup Gateway - Error Oops! - Error code 18354
Example Screen Shot 2018-05-01 at 16.14.40.png Description You see this error after repeatedly sending an SMS code Solution When you try to login with SMS, you can request a SMS code 3 times. If you try for the 4th time, this error appears. The solution i
Page: Stepup Gateway - Error Oops! - Error code 21072
Example Screen Shot 2018-10-22 at 11.09.22.png Description You see this error when you try to login to a service Solution A possible solution is to return to the service where you were trying to login and start the login proces again. You can also try a d
Page: Stepup Gateway - Error Oops! - Errorcode 22109
Voorbeeld fout_22109.jpg Beschrijving This error appears when the user has successfully authenticated, but the SURFsecureID gateway can't find a session, and therefore can't redirect you to the originating service. This happens when a link is opened in a
Page: Stepup Gateway - Error Oops! - Foutcode 18354
Voorbeeld Screen Shot 2018-05-01 at 16.14.40.png Beschrijving Je krijgt deze error bij het herhaaldelijk laten versturen van een SMS code Oplossing Als je inlogt met SMS kun je 3x een SMS code laten versturen. Als je het nog vaker probeert verschijnt deze
Page: Stepup Gateway - Error Oops! - Foutcode 21072
Voorbeeld Screen Shot 2018-10-22 at 11.09.22.png Beschrijving Je krijgt deze error als je probeert in te loggen bij een dienst Oplossing Een mogelijke oplossing is om terug te gaan naar de dienst waarop je wilde inloggen en het nogmaals te proberen. Je ku
Page: Stepup Gateway - Error Oops! - Foutcode 22109
Voorbeeld fout_22109.jpg Beschrijving Deze foutmelding verschijnt als de gebruiker succesvol is ingelogd, maar de SURFsecureID gateway de sessie niet meer kan vinden, en je dus niet terug kan sturen naar de dienst. Dit gebeurt als een link wordt geopend i
Page: Stepup Gateway - Error Oops! - Foutcode 72588
Voorbeeld ssid-error.png Beschrijving The SURFsecureID Gateway did not receive the eduPersonTargetedID (EPTI) attribute. This attribute is required when authenticating to a Service Provider (SP) that uses SURFsecureID. Oplossing Ask SURFconext support mai
Page: Supported FIDO2 tokens
SURFsecureID supports the use of FIDO tokens (also called authenticators or security keys). Both FIDO U2F and FIDO2 tokens can be used as a 2nd factor. The FIDO protocols are standardized, so that tokens from different manufacturers can be used. See below
Home page: SURFsecureID
With SURFsecureID users have to do a second authentication, above their 'normal' username and password login. The result is a higher security for the Service Provider (SP) and the Identity Provider (IdP). This wiki explains the principles behind SURFsecur
Page: SURFsecureID gebruiken
Wanneer je gebruik maakt van online diensten wil je zeker weten dat jouw privacy wordt bewaakt en jouw data veilig is. Daarnaast willen instellingen en online diensten zeker weten dat jij degene bent die je zegt dat je bent (en niet iemand die zich als jo
Page: SURFsecureID Metadata for Service Providers
The SURFsecureId Production, Pilot and Test environments use different AuthnContextClassRef identifiers. Production environment On juli 2nd 2020 the signing certificate of SURFsecureID production was be replaced. For more information see SURFsecureID Ke
Page: SURFsecureID ondersteuning (NL)
Op deze pagina's vindt je ondersteuning voor het gebruik van SURFsecureID of hulp als er iets mis gaat. Handleiding voor het gebruik van SURFsecureID Bekijk de veelgestelde vragen of jouw vraag hier bij staat Help, er gaat iets mis! Een overzicht van veel
Page: SURFsecureID support
Page: SURFsecureID support (EN)
On these pages you can find support for using SURFsecureID or help when something goes wrong. Manual for using SURFsecureID Frequently asked questions for SURFsecureID Help, something is wrong. An overview of common error messages. If your question is not

T

Page: Tiqr
Een smartphone is vereist (Apple iOS of Android) Download de tiqr app Je hebt toegang nodig tot je instellings e-mailaccount. Basics Ga zorgvuldig om met je telefoon en de tiqr app Jouw telefoon en tiqr app zijn privé, deel deze niet met anderen. Verlies
Page: Tiqr (EN)
You will need a smartphone (Apple iOS or Android) Download the tiqr app You will need access to your institutional e-mail account. Basics Handle your phone and tiqr app with care Your phone and tiqr app are private, do not share it with others. Never leav
Page: Tiqr - Black screen while trying to scan the QR code
Example This screen is shown during the registration process of you tiqr app: Screenshot_20180618-131321_TiQR.jpg Description While registering you tiqr app you need to scan the QR code, but this is not possible because the tiqr app only shows a black scr
Page: Tiqr - Error - Je account is geblokkeerd
Voorbeeld image (1).png Beschrijving Je gebruikt normaal tiqr om in te loggen op de dienst. Nu verschijnt bovenstaande fout als je probeert in te loggen bij een dienst. Oplossing Je hebt waarschijnlijk 5x een verkeerde PIN-code ingevoerd in de tiqr app. H
Page: Tiqr - Error - Your account is blocked
Example image (1).png Description You normally use tiqr to login to the service. Now, the above error appears when you try to login. Solution You've probably entered a wrong PIN-code 5 times in the tiqr app. This permanently blockes your current tiqr regi
Page: Tiqr - Invalid Response during registration
Example This error is displayed in the tiqr app during the registration process: Screenshot_20180618-115040_TiQR.jpg Description During registration of your tiqr app an error saying "invalid response" is displayed in the tiqr app. This problem can occur o
Page: Tiqr - Invalid Response tijdens registratie
Voorbeeld De volgende fout verschijnt in de tiqr app tijdens het registratieproces: Screenshot_20180618-115040_TiQR.jpg Beschrijving Tijdens het registreren van tiqr verschijnt de foutmelding "Invalid response" in de tiqr app. De fout ziet er uit zoals he
Page: Tiqr - Kan niet inloggen. Ongeldige sleutel.
Voorbeeld Het volgende scherm verschijnt in de tiqr app tijdens op een Android telefoon: image2019-3-11_15-49-41.png Beschrijving Tijdens de login met tiqr zie je bovenstaande foutmelding. Dit probleem doet zich voor op Android telefoons. Oplossing De ops
Page: Tiqr - Zwart scherm tijdens scannen QR code
Voorbeeld Het volgende scherm verschijnt in de tiqr app tijdens het registratieproces: Screenshot_20180618-131321_TiQR.jpg Beschrijving Tijdens het registreren van tiqr wil je de QR code scannen, maar dat lukt niet omdat de tiqr app een zwart scherm laat
Page: Tiqr Android Bèta release
De tiqr Bèta release is bedoeld voor testen of voor gebruikers die problemen ondervinden met de huidige tiqr release of die willen testen wanneer een nieuwe release aanstaande is. Huidige tiqr bèta release: 3.0.5 Installatie Installatie van de tiqr Bèta g
Page: Tiqr iOS Bèta release
De huidige tiqr beta release is versie 3.0.8. Om een beta release van tiqr te testen moet je eerst Apple's TestFlight https://apps.apple.com/nl/app/testflight/id899247664 App installeren. Om de tiqr beta vervolgens te installeren, open je de volgende link
Page: Token overzicht exporteren
Als RAA heb je in de 'Tokens' tab te mogelijkheid om een token overzicht te exporteren als CSV bestand. Een RA heeft deze mogelijkheid niet. Selecteer de tokens die je wilt exporteren, gebruik hiervoor de 'Zoek'-functie Klik op 'Exporteren' om een CSV-bes
Page: Token registration manual
This manual is for all users that want to register a token for SURFsecureID. Users can select an authentication token via a Registration Portal https://sa.surfsecureid.nl/. The following tokens are available: SMS Tiqr YubiKey Table of contents of this man

U

Page: Using Citrix NetScaler with Second Factor Only (SFO) Authentication
Since Citrix ADC release 13 https://docs.citrix.com/en-us/citrix-adc/13/, Citrix NetScaler contains the SAML features that are required to use second factor only (SFO) authentication with SURFsecureID. This allows adding 2nd factor authentication with SUR
Page: Using eduID as IdP for testing SPs
eduID is the replacement for OneGini. See "Migrating your old Onegini account to a new eduID" for more information. For testing with the SURFsecureID test environment you need a user account. If you do not have access to an identity provider (IdP) that is
Page: Using Levels of Assurance to express strength of authentication
SURFsecureID uses Levels of Assurance (LoA) to express the strength of authentication. This page describes how a service or institution can request a LoA for a specific service or part of a service. Furthermore, the LoA identifiers differ between the envi
Page: Using SURFsecureID
When you’re using digital services, you need to be sure that your privacy is being protected and your data is secure. Also institutions from higher education and research and service providers that offer services online need to know it is really you (and

V

Page: Voorwaarden en tarieven
Onderstaande voorwaarden zijn van toepassing op het gebruik van SURFsecureID. Instellingen gaan bij aanmelding voor SURFsecureID akkoord met deze voorwaarden. Voorwaarden SURFsecureID Naast onderstaande voorwaarden zijn de voorwaarden van de “Gebruiksover

W

X

Y

Page: YubiKey
Je hebt een YubiKey hardware token nodig (Standard, Edge, Neo, 4 of 5). Neem contact op met jouw instelling om een YubiKey te verkrijgen, of bestel er een online. Toegang tot het mailaccount van je instelling is vereist. Een apparaat met USB poort is vere
Page: YubiKey (EN)
You will need a YubiKey hardware token (Standard, Edge, Neo, 4 or 5). Please contact your institution to request a YubiKey hardware token, or order a YubiKey yourself online. You will need access to your institutional e-mail account. You will need a devic
Page: YubiKeys
SURFsecureID ondersteunt het gebruik van YubiKey-hardware tokens. Yubikeys die "Yubico OTP" ondersteunen zijn geschikt voor gebruik binnen SURFsecureID. Merk op dat er ook Yubikeys te koop zijn die enkel FIDO2 als protocol ondersteunen. Deze (meestal) b

Z

!@#$

Second Factor Only (SFO) Authentication is an alternate SAML authentication endpoint that is offered by the SURFconext strong authentication (SA) gateway. The SFO endpoint allows a Service Provider (SP) to authenticate only the second factor of a user. This in contrast to a "standard" authentication at the SA gateway where authentication of the first factor, being the normal authentication of the user to the IdP of their home institution through SURFconext, is always performed.

SFO Authentication was designed to facilitate the integration of SURFconext SA with the internal services of an institution (i.e. the institution offering services to their own users). Typical applications include:

  • Adding two factor authentication to an institution's application gateway (e.g. Citrix Netscaler or F5 BIG-IP)
  • Adding two factor authentication to an institution's authentication or authorization gateway (e.g. Microsoft ADFS, Novell/NetIQ)

Both SFO authentication and standard authentication use the 2nd factor of the user that is registered with SURFconext SA. This means that once a user is registered with SURFconext SA both services using standard and SFO authentication can be used.

The table below shows the differences between a SURFconext SA standard authentication and a SURFconext SA SFO Authentication.

FeatureStandard authenticationSFO authenticaton
Authentication of the user's first factorAlwaysNever
Authentication of the user's second factorBased on policy between the IdP and SPAlways
User registrationUsing SURFconext SA selfservice registration and vetting by an RA
Standard SURFconext featuresAttributes, Authorization, persistent identifiersNone

During SFO Authentication the authentication via SURFconext is bypassed (see image below). This means that SURFconext functionality like attributes (from the user's home IdP), persistent user identifiers or the definition of authorization rules is not available when using SFO authentication. For the self-service registration of users and the vetting by RA the SURFconext SA self-service and RA web interfaces are used, with the first factor authentication provided by SURFconext.

Implementation at the SP

Second factor authentication (SFO) requires implementation / configuration at the service provider. The SFO authentication protocol is very similar to the SAML 2.0 protocol used by normal authentication to the SA gateway. The main difference is that the SP must send the identifier of the user to SA gateway in the SAML AuthnRequest. For this the Subject element in the SAML AuthnRequest must be used (see the description of the AuthnRequest element in the https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, section 3.4.1, line 2017)

SAML AuthRequest

To start a SFO the SP must send a SAML 2.0 AuthnRequest to the SFO endpoint of the SA Gateway. This request:

  • must use the urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect binding
  • must be signed using the http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 algorithm. (Note that the HTTP-Redirect binding does not use XML Signatures)
  • must include the SURFconext identifier (see below) of the user in the Subject element of the AuthnRequest. (see the description of the AuthnRequest element in the https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, section 3.4.1, line 2017) as a SAML NameID with Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified".

The SFO uses a different SingleSignOn Location and different AuthnConext identifiers than the standard authentication.

See below for an example AuthnRequest. The signature is not visible in the XML as it will be encoded in HTTP GET parameters according to the specification of the HTTP-Redirect binding.

Example AuthnRequest
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                    ID="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN"
                    Version="2.0"
                    IssueInstant="2016-03-10T15:09:21Z"
                    Destination="https://gw.stepup.example.org/gssp/2nd-factor-only/single-sign-on"
                    AssertionConsumerServiceURL="https://application-gateway.some-organisation.example.org/consume-assertion"
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

    <saml:Issuer>https://application-gateway.some-organisation.example.org/metadata</saml:Issuer>
    <saml:Subject>
        <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">urn:collab:person:some-organisation.example.org:m1234567890</saml:NameID>
    </saml:Subject>
    <samlp:RequestedAuthnContext>
        <saml:AuthnContextClassRef>http://stepup.example.org/verified-second-factor/level2</saml:AuthnContextClassRef>
    </samlp:RequestedAuthnContext>    
</samlp:AuthnRequest>

Determining the SURFconext identifier of a user

The SURFconext identifier is build from identifiers that the IdP of the users sends to SURFconext during authentication. It has the following form:
urn:collab:person:{{urn:mace:terena.org:attribute-def:schacHomeOrganization}}:{{urn:mace:dir:attribute-def:uid}}

where:

  • "urn:collab:person:" is a fixed prefix.
  • "{{urn:mace:terena.org:attribute-def:schacHomeOrganization}}" is the value of the schacHomeOrganisation attribute of the user. This value is the same for all users of an institution and will typically be something like "institution.nl". The administrator of the identity provider (IdP) of the institution can tell you how this value is formed for users of the institution.
  • "{{urn:mace:dir:attribute-def:uid}}" is the value of the uid attribute of the user. The administrator of the identity provider (IdP) of the institution can tell you how this value is formed for users of the institution.

Example SURFconext identifier (59 characters): urn:collab:person:some-organisation.example.org:m1234567890

SAML Response

The result of a successful authentication is a SAML Response. The Response does not contain an AttributeStatement as would a Response from a standard authentication.

Example Response:

Example Response
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                ID="_ECAokbn0lm7lfVT7THQUl+dSbMrpeyAgiTv0+q16"
                Version="2.0"
                IssueInstant="2016-03-10T15:09:25Z"
                Destination="https://application-gateway.some-organisation.example.org/consume-assertion"
                InResponseTo="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN"
                >
    <saml:Issuer>https://gw.stepup.example.org/second-factory-only/metadata</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    xmlns:xs="http://www.w3.org/2001/XMLSchema"
                    ID="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN"
                    Version="2.0"
                    IssueInstant="2016-03-10T15:09:25Z"
                    >
        <saml:Issuer>https://gw.stepup.example.org/second-factory-only/metadata</saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
                <ds:Reference URI="#_1ROuxGVzJi5bbre6W4woNza82aK41HKjp6aKtw9r">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                    <ds:DigestValue>YR5JFfJc1JZIKm7Ao3kXtDupEfeMrhKpD9T1lF1z0Lg=</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>...</ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:Subject>
            <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">urn:collab:person:some-organisation.example.org:m1234567890</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData NotOnOrAfter="2016-03-10T15:14:25Z"
                                              Recipient="https://application-gateway.some-organisation.example.org/consume-assertion"
                                              InResponseTo="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN"
                                              />
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions NotBefore="2016-03-10T15:09:25Z"
                         NotOnOrAfter="2016-03-10T15:14:25Z"
                         >
            <saml:AudienceRestriction>
                <saml:Audience>https://application-gateway.some-organisation.example.org/metadata</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2016-03-10T15:09:25Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>http://stepup.example.org/verified-second-factor/level2</saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
    </saml:Assertion>
</samlp:Response> 

Errors

When the SA gateway is unable or unwilling to authenticate the user a SAML Response with a non success status is sent. In some failure scenarios a non 20x HTTP status code may be returned.

SAML status codes are used to refer specific failure modes back to the SP:

  • Status urn:oasis:names:tc:SAML:2.0:status:Responder with subcode urn:oasis:names:tc:SAML:2.0:status:AuthnFailed: The authentication was not successful
  • Status urn:oasis:names:tc:SAML:2.0:status:Responder with subcode urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext: The user could not be authenticated at the requested level

Example error response:

Example error response
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                ID="_ECAokbn0lm7lfVT7THQUl+dSbMrpeyAgiTv0+q16"
                Version="2.0"
                IssueInstant="2016-03-10T15:09:25Z"
                Destination="https://application-gateway.some-organisation.example.org/consume-assertion"
                InResponseTo="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN">
                <saml:Issuer>https://gw.stepup.example.org/metadata</saml:Issuer
                >
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
            <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" />
        </samlp:StatusCode>
    </samlp:Status>
</samlp:Response>

Implementation Considerations

Always do a first factor authentication before starting a SFO authentication

Starting an SFO authentication will immediately start an authentication at the SA gateway. For tiqr this means that a push notification is sent to the phone of the user being authenticated. For SMS authentication this means that an SMS message is sent to the mobile phone of the using being authenticated. When an authentication is started for the wrong user (deliberately or not) this will derange the targeted user and in case of SMS, incur a cost to the institution and possibly for the user.

By observing the behaviour of the SFO authentication it is possible to determine whether a username exists or not.

For the above two reasons we strongly advise implementers to always perform a first factor authentication before starting a SFO authentication. The second factor authentication process was not designed to be used as a single factor authentication mechanism.

  • No labels