Space Index

Total number of pages: 119

0-9 ... 0	A ... 5	B ... 0	C ... 6	D ... 5	E ... 1
F ... 4	G ... 0	H ... 3	I ... 2	J ... 0	K ... 0
L ... 1	M ... 2	N ... 0	O ... 0	P ... 0	Q ... 0
R ... 4	S ... 8	T ... 1	U ... 3	V ... 1	W ... 0
X ... 0	Y ... 1	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 test omgeving

Voor het doen van tests met SURFsecureID heeft SURFnet een test omgeving beschikbaar. Deze omgeving kan door instellingen, en ook door service providers, gebruikt worden om sterke authenticatie te testen. De test omgeving staat geheel los van de productie

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: Activatie hulpteksten

Als je instelling het toestaat dat gebruikers zelf hun token activeren kan het nuttig zijn om activatie hulpteksten te configureren. Deze teksten worden op het activatie keuzescherm aan de gebruiker getoond om te helpen bij het maken van een keuze tussen

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: Configuratie opties

Er zijn verschillende SURFsecureID configuratie opties voor een instelling. Een wijziging in deze opties kun je aanvragen via support@surfconext.nl. mailto:support@surfconext.nl. Token types De instelling kan kiezen welke token types er ondersteund moeten

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

This documentation describes how to connect a SP to the SURFsecureID gateway directly. New SP's must connect to the SURFconext gateway. Request authentication at a specific LoA An example Apache configuration snippet where a request for a specific URL tri

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, configuration changes, issues or incidents regarding SURFsecureID. The SURFconext team offers support to all Identity Providers and Service Providers,

D

Page: Diensten met SURFsecureID

Een dienst kan op verschillende manieren gebruik maken van SURFsecureID. Welke manier het beste geschikt is is afhankelijk van hoe de login integratie van de dienst is ingericht: Via SURFconext. Er zijn 1500+ diensten gekoppeld aan SURFconext, waarbij het

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 connecting to SU

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 two environments that can be used. The table below shows the differences between these environments. header-logo-test.png header-logo.png Environment for testing purposes only Uses IDP's from SURFconext Test environment https://wiki.surfn

F

Page: FIDO2 tokens

Sommige desktop applicaties, zoals de Microsoft Office desktop of mobile applicatie en de Mac OSX Calender en Mail werken met een ingebouwde browser die de FIDO/webauthn standaard (nog) niet ondersteunt. De login met een FIDO token werkt dan ook niet voor

Page: For a service

Introduction A service can connect to SURFconext to handle it's strong authentication login. Previously, it was also possible to connect a service to SURFsecureID directly, but this has been deprecated. All necessary (and more) functionality to enable SUR

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: 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 met de rol Registration Authority (RA) 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 identit

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: 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: Installatie ADFS MFA Extensie

SURF 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 registratie

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: Microsoft integratie opties

Er zijn verschillende mogelijkheden om Multi Factor Authentication (MFA) te gebruiken in een omgeving met ADFS, Azure AD en SURFconext. De verschillen worden hier uitgelegd. Let er wel op dat beide opties niet gecombineerd kunnen worden in één omgeving, d

Page: Migrating a SP from SURFsecureID to SURFconext

Introduction Since the start of 2020 SURFconext can use SURFsecureID for two factor authentication natively, without requiring SPs to connect to SURFsecureID gateway directly. For SPs that currently authenticate to the SURFsecureID gateway directly (endpo

N

O

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: Registratie- en activatieproces

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 kan worden a

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: Enable Single Sign-On (SSO) on second factor Planned for 2023H2 User deprovisi

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

Home page: SURFsecureID

With SURFsecureID users have to do a second authentication step, 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 SURF

Page: SURFsecureID ADFS plugin

See Installatie ADFS MFA Extensie for instructions for a first time installation of the plugin You can download the plugin from https://github.com/SURFnet/ADFS-MFA-SAML2.0-Extension/releases/download/2.0.3/SetupPackage-2.0.3.exe https://github.com/SURFnet

Page: SURFsecureID Metadata for Service Providers

The SURFsecureId Production and Test environments use different AuthnContextClassRef identifiers. Production environment Click here https://metadata.surfconext.nl/surfsecureid-metadata.xml for the SAML 2.0 metadata for the Production environment. Click

Page: SURFsecureID voor toegang tot SURF diensten

Voor toegang tot een aantal SURF diensten zoals SURFdomeinen en SURFdashboard is SURFsecureID https://surf.nl/surfsecureid, de 2e factor dienstverlening van SURF nodig. De 1e factor login (gebruikersnaam/wachtwoord van de eigen instelling via SURFconext)

T

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

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

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 connected to the SURFconext test environment, you can use eduID. EduID is an IdP that allows anybody to create an a

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

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: 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. Dit zijn bijvoor

Z

!@#$

Introduction

Second Factor Only authentication allows a SP to authenticate only the second factor of a user. With SFO you can add two factor authentication to your institutions application gateway (e.g. Citrix Netscaler or F5 BIG-IP) or to the authentication or authorization gateway (e.g. Microsoft ADFS or Novell/NetIQ). SFO has its own authentication endpoint at SURFsecureID.

Once a user is registered with a second factor both SFO authentication and SURFsecureID can be used.

Differences between 'standard' SURFsecureID and SFO authentication

Feature	Standard authentication	SFO authenticaton
Authentication of first factor	Always	Never
Authentication of second factor	Based on policy between IdP and SP	Always
User registration	Using SURFsecureID selfservice registration and vetting by an RA
Standard SURFconext features	Attributes, Authorization, persistent identifiers	None

With SFO the authentication via SURFconext is bypassed (see image below). This means that SURFconext functionality (e.g. attributes from the user's home IdP, the definition of authorization rules and persistent user identifiers) is not available.

Note that also with SFO the registration of users will be done by the institutions (IdP's): there is no work to be done for the SP.

SAML AuthRequest

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

use the urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect binding
be signed using the http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 algorithm (XML signatures cannot be used).
include a RequestedAuthnContext with an AuthnContextClassRef with one of the defined levels.
include the SURFconext identifier of the user in the Subject element as a NameID (with Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified", see description of AuthnRequest in https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, line 2001).

SFO uses different SingleSignOn Location and AuthnConext identifiers as compared with standard authentication.

Example AuthRequest

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_zQIibz9FKixdlgX8E7bHqE29wfatcgbsPdVn0NN"
    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>

The signature is not visible in the XML: it will be encoded in HTTP GET parameters according to the specification of the HTTP-Redirect binding.

Determining the SURFconext identifier of a user

The SURFconext identifier is built from identifiers that the IdP of the user sends to SURFconext during authentication: urn:collab:person:{{urn:mace:terena.org:attribute-def:schacHomeOrganization}}:{{urn:mace:dir:attribute-def:uid}}
where:

urn:collab:person:
= fixed prefix.
{{urn:mace:terena.org:attribute-def:schacHomeOrganization}}= value of schacHomeOrganisation attribute of the user; same for all users and will be something like "institution.nl".
{{urn:mace:dir:attribute-def:uid}}= value of uid attribute of the user. Replace any "@" with an "_".

For the value of last two items: ask the administrator of the IdP .

Example: urn:collab:person:some-organisation.example.org:m1234567890

SAML Response

The result of a successful authentication is a SAML Response. It does not contain an AttributeStatement.

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="_zQIibz9FKixdlgX8E7bHqE29wfatcgbsPdVn0NN"
                >
    <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="_zQIibz9FKixdlgX8E7bHqE29wfatcgbsPdVn0NN"
                    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="_zQIibz9FKixdlgX8E7bHqE29wfatcgbsPdVn0NN"
                                              />
            </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>

Error handling

When a user cannot be authenticated, the SURFsecureID gateway sends a SAML Response to the SP with a non success status:

urn:oasis:names:tc:SAML:2.0:status:Responder with subcode urn:oasis:names:tc:SAML:2.0:status:AuthnFailed =
Authentication not successful
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

Level: authentication strength

See explanation at "Levels of Assurance".

Implementation

SFO must be implemented at the SP. The authentication protocol is similar to the one used by the SURFsecureID gateway. The main difference is that the SP must send the identifier of the user in the Subject element of the SAML AuthnRequest (see description of AuthnRequest, line 2017).

The SP will be registered at the SURFsecureID gateway as either SFO SP or a 'standard' SURFsecureID SP: this determines which endpoint he can access. If a SP implementation needs both, he can register an additional EnityID and use it to access the other endpoint.
There is a white-list of SURFconext identities allowing SFO authentication. The SP must indicate in advance the institutions from which he wants to authenticate users with SFO.

You can find the metadata of the SFO endpoints on SURFsecureID Metadata for Service Providers.

Always do a first factor authentication before starting a SFO authentication

Starting an SFO authentication will immediately start an authentication at the SURFsecureID gateway: a push notification (tqr) or an SMS will be sent to the user being authenticated. If authentication is started for the wrong user, 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 behavior of the SFO authentication it is possible to determine whether a username exists.

For this reasons we advise to perform a first factor authentication before starting a SFO authentication.

Example

An example code for using SFO with SimpleSAMLphp can be found at: https://github.com/SURFnet/Stepup-SFO-demo

Page tree

Second Factor Only (SFO) Authentication