SURFsecureID
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 27 Next »

Space Index

Total number of pages: 69

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

B

Page: Bestellen YubiKeys
SURFsecureID ondersteunt het gebruik van YubiKey-hardware tokens. De volgende type YubiKey-tokens zijn geschikt voor SURFsecureID. Merk op dat sommige versies niet meer verkrijgbaar zijn. YubiKey 5 (FIDO2 ondersteuning toegevoegd). Verkrijgbaar in versc

C

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 SURFsecureID, or that is using both simultaneously. Please note that SURFsecureID does not yet
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 
This part of the wiki gives all the (technical) information that can be of importance for Service Providers working with SURFsecureID. To start with it is explained how you can connect your service with the SURFsecureID gateway. Actually it is very simila

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

F

Page: FAQ SURFsecureID
SURFsecureID is de nieuwe naam van SURFconext Sterke Authenticatie Maakt het uit of ik een werk- of privételefoon registreer? Nee, het maakt niet uit of je een werk- of privételefoon registreert. Eenmalige codes ontvangen via SMS is gratis. Zorg ervoor da
Page: FAQ SURFsecureID (EN)
SURFconext Strong Authentication has been renamed to SURFsecureID. Does it matter if I register a work or private phone? No. It does not matter if you register your work or private phone. Receiving one time pass codes via text messages is free. Just make
Page: For a service
Introduction A service can use SURFsecureID to handle it's login, much like SURFconext is used to perform user login for services. There are only a few differences between a SURFconext and the SURFsecureID connection. With SURFsecureID, the login process
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 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 (RA-admin) 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 staat bij het ve
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
SURFsecureID is de nieuwe naam van SURFconext Sterke Authenticatie 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 j
Page: Help, something is wrong
SURFsecureID is the new name of SURFconext Strong Authentication 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

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: OpenID Connect koppeling aan SURFsecureID
De verwachting is dat SURFsecureID vanaf 1 november 2019 OpenID Connect gaat ondersteunen. De dienst sluit dan aan op SURFconext met OpenID Connect en daar wordt dan SURFsecureID aangeroepen. Introductie SURFsecureID zelf ondersteunt op dit moment geen Op

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 als Registration Authority (RA) geautoriseerd 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
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: More fine-grained authorization: allow RAs and RAAs users to work for more mul

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?
In juli 2016 kondigde NIST (National Institute of Standards and Technology in de V.S.) aan dat het alle vormen van authenticatie die gebruik maken van het telefoonnetwerk, zoals SMS-authenticatie, niet meer toe wil staan in toekomstige versies van haar ve
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! - 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
Home page: SURFsecureID
SURFconext Strong Authentication has been renamed to 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
Page: SURFsecureID gebruiken
SURFsecureID is de nieuwe naam van SURFconext Sterke Authenticatie 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
Page: SURFsecureID Metadata for Service Providers
The SURFsecureId Production, Pilot and Test environments use different AuthnContextClassRef identifiers. Production environment Click here https://sa-gw.surfconext.nl/authentication/metadata for the SAML 2.0 metadata for the Production environment. Clic
Page: SURFsecureID ondersteuning (NL)
SURFsecureID is de nieuwe naam van SURFconext Sterke Authenticatie 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
Page: SURFsecureID support
Page: SURFsecureID support (EN)
SURFconext Strong Authentication has been renamed to SURFsecureID. 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 w

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 Bèta release
Op dit moment is er geen tiqr bèta beschikbaar
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 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 Onegini 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 Onegini. Onegini is an IdP that allows anybody to create
Page: Using SURFsecureID
SURFconext Strong Authentication has been renamed to 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 provi

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

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

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

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

  • No labels