| Table of Contents |
|---|
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 research connect their own services to SURFsecureID?
Yes. Every institution connected to SURFconext as an Identity Provider can connect its services to SURFsecureID.
How can an application enforce a specific level of assurance?
This is done via the authentication request to the SURFsecureID gateway. Enforcing a specific level of assurance can be done in two ways:
- Dynamically by communicating the required level of assurance with "AuthnContextClassRef". In this way the required level can be defined for each authentication request individually (based on the user authenticating or the selected feature in the application). In most cases modifications to the application are required to facilitate this.
- Statically: in SURFconext a minimum level of assurance can be configured (based on the IdP and SP involved). In this way the application does not have to be modified. Authentication for all users from one institution to one application will always require the same minimum level of assurance.
- Based on user context: with SURFconext step-up policies, a rule can be made based on the user's context (user attributes, IP address) that will require a specific SURFsecureID LoA.
Why is remote registration not supported?
Remote registration is vulnerable to threats and technically complex to achieve. In person registration is therefore the most efficient option. In Q4 of 2017, Innovalor reviewed the options for remote registration. This has resulted in a design an POC phase in the first half of 2019.
...
| width | 100% |
|---|
...
| borderColor | #4fb3cf |
|---|---|
| bgColor | white |
| titleBGColor | #4fb3cf |
| borderWidth | 2 |
| title | FAQ Service Providers |
| borderStyle | solid |
This is a list of our most frequently asked questions. For more information about SURFconext Strong Authentication, please visit the relevant pages on this wiki of contact our supportteam.
| Expand | ||
|---|---|---|
| ||
Different registration processes and mechanisms applied to identity vetting, proofing and credentialing result in different registration assurance levels. An applicant may appear in person to register, or the applicant may register remotely. Remote registration is limited to Levels 1 through 3 and is more vulnerable to threats and technically complex to achieve. Remote registration relies on the availability of trusted sources to cross-reference and validate the provided assertions such as name, home address, age, social security number (BSN), and photo. Examples of such sources are the institution’s HR system or the government/municipal administration (in The Netherlands: Basisregistratie Personen, BRP) Consultation of the latter source is restricted by legislation and not available for SURFconext Strong Authentication purposes; the HR system on the other hand could be used as an alternative source. Typically, after a successful validation, a registration activation code is sent to the applicant’s home address. This is cumbersome and expensive. Therefore, in person registration seems the most efficient option. In case the user is somehow not able to register in person, video conferencing tools such as Skype or Lync could be used. In this case the user identifies him/herself via the video conference and shows his/her passport or other valid photo-ID to the registrar. The use of video conferencing tools for identification, however, has several drawbacks: it introduces scheduling overhead and it makes it harder to detect a forged ID. Other – less attractive and/or appropriate – alternatives (such as use of physical address, email & mobile phone, use of bank account). |
...
Why is Google Authenticator not supported?
...
...
offers second factor authentication
...
in the form of an SMS service and a smart phone OTP app, but has no face-to-face registration processes
...
. For an individual Google user this will be fine. But for an educational institute, protecting its organisational assets
...
and its reputation
...
,
...
a self-asserted second factor is not enough. They want to determine that a service provider (e.g. a student information system) is dealing with a legitimate
...
user
...
. Face-to-face
...
| width | 100% |
|---|
...
| borderColor | #4fb3cf |
|---|---|
| bgColor | white |
| titleBGColor | #4fb3cf |
| borderWidth | 2 |
| title | FAQ for Identity Providers |
| borderStyle | solid |
Dit zijn de meest gestelde vragen. Voor meer informatie kun je terecht op de wiki of bij het supporteam.
registration is inevitable to achieve this.
Can a second factor authentication be re-used in one browser session?
Yes, SURFsecureID supports single-sign on (SSO) on the second factor. If enabled, the user will only need to login once a day (per device) with his second factor. The institution needs to enable this feature for all logins and can disable it for specific services. See also Configuratie opties#SingleSign-On(SSO)
Note that SURFsecureID does not always control SSO for the second factor. When using the Second Factor Only functionality, the central facility (like ADFS) controls SSO.
How does single logout work with SURFsecureID?
SURFsecureID does not support Single Sign On (SSO). As a result there is no active session on the SURFsecureID gateway for a user to logout. For first factor login SURFsecureID relies on SURFconext. Therefore, the same issues apply as with SURFconext.
Can an institution implement strong authentication on their own IdP and then forward the level of assurance to SURFsecureID?
No. SURFsecureID does not support the transfer of levels of assurance via the local IdP.
LoA 2 and LoA 3 authentication requires (1) strong authentication, (2) strong identification and (3) a solid binding between the user identity and his token. Local implementations of strong authentication (at the IdP) do not guarantee the same solid binding between the user identity and his token. This means that SURFconext cannot guarantee that such an IdP-specific LoA2 and LoA3 implementation is equal to LoA2 and LoA3 facilitated by SURFsecureID. Therefore this is not supported.
Can an institution re-use its own strong authentication tokens?
Yes, this is possible with AzureMFA tokens or FIDO2 tokens. It is also possible to re-use Yubikey tokens, however using a Yubikey many places increases the risk of fishing attacks.
Why is the activation code designed as it is?
The activation code should have enough entropy to prevent a guessing attack and yet short enough to be written down by the user.
How long is the activation code valid?
14 days after registering a token. To get a new activation code a user must delete the registered token and start a new registration.
How can SURFsecureID ensure that tokens are bound to the right identity?
Threat | Description | Controls |
|---|---|---|
| Impersonation | An applicant claims an incorrect identity, supporting the claim with a specific set of attributes created over time or by presenting false credentials. | During the registration process different methods are used to determine that the applicant is the right person:
|
Compromise or malfeasance of the infrastructure | Lack or poor implementation of security measures undermine the reliability of the registration. | Infrastructure threats are addressed by normal computer security controls:
Also a third party security audit on software code and infrastructure was conducted. |
How can I order YubiKey tokens?
There are several options where you can buy YubiKeys.
Can a user register multiple tokens?
Yes. If the user's institution allows the use of multiple tokens, the user can register multiple tokens as long as each one is of a different type. For example, a user can register a tiqr and a Yubikey, but not two tiqr apps or two Yubikeys.
Can I install the Tiqr app on multiple devices after registering once?
No. For security reasons only one token registration per user is allowed.
What is the length of the session of your second factor at an SP?
The length of the session is SP specific. For usability reasons it should not be too short (< 30 min), for security reasons it should not be too long (> 4-8 hours).
Can I activate the token of a user who cannot come personally to the service desk?
No. Our policy - in line with ISO29115 - explicitly requires a user to appear in person.
How can I revoke the token of a user?
There are two ways to achieve this:
- The easiest way is to remove the first factor of the user (= username/password) through your regular exit proces/ IDM-lifecycle. Once the first factor is removed, the user can no longer use his second factor.
- Ask the RA of your institution to remove the second factor registration through the RA Management portal.
Why is remote registration not supported
Different registration processes and mechanisms applied to identity vetting, proofing and credentialing result in different registration assurance levels. An applicant may appear in person to register, or the applicant may register remotely.
Remote registration is limited to Levels 1 through 3 and is more vulnerable to threats and technically complex to achieve. Remote registration relies on the availability of trusted sources to cross-reference and validate the provided assertions such as name, home address, age, social security number (BSN), and photo. Examples of such sources are the institution’s HR system or the government/municipal administration (in The Netherlands: Basisregistratie Personen, BRP) Consultation of the latter source is restricted by legislation and not available for SURFconext Strong Authentication purposes; the HR system on the other hand could be used as an alternative source. Typically, after a successful validation, a registration activation code is sent to the applicant’s home address. This is cumbersome and expensive.
Therefore, in person registration seems the most efficient option. In case the user is somehow not able to register in person, video conferencing tools such as Skype or Lync could be used. In this case the user identifies him/herself via the video conference and shows his/her passport or other valid photo-ID to the registrar. The use of video conferencing tools for identification, however, has several drawbacks: it introduces scheduling overhead and it makes it harder to detect a forged ID. Other – less attractive and/or appropriate – alternatives (such as use of physical address, email & mobile phone, use of bank account).
Why is Google Authenticator not supported
Different circumstances may translate to different requirements. There are use cases in which a second factor authentication token without a strict registration process makes sense: Google, for example, offers second factor authentication to its users in the form of an SMS service and a smart phone OTP app, but has no face-to-face registration processes in place.
The difference between this “Google use case” and the use cases of most institutions is that Google users are protecting their own account (from, say, snooping governments) as opposed to the educational institute’s student information system use case where the IdP is protecting its organisational assets (or its reputation). In the latter case, there is a strong need to be able to determine that a service provider (e.g. a student information system) is dealing with a legitimate user, thus necessitating a stringent identity proofing process during user registration (i.e. a face-to-face process) described below.
Kun je zelf als instelling kiezen welke methode wordt gebruikt? Of kiest de eindgebruiker dat zelf?
Dit wordt waarschijnlijk een getrapt model. De instelling kiest welke tokens beschikbaar zijn: SMS, Tiqr en/ of Yubikey. Vervolgens kan gebruiker uit de beschikbare tokens kiezen. Als instelling alleen Tiqr ondersteunt, dan valt er weinig te kiezen. We denken nog na over hoe je dat keuzeproces verder kan stroomlijnen, ook gezien de financiële consequenties van SMS (ca 6-8 cent/ transactie) en Yubikey (20-25 euro eenmalige aanschafwaarde). Mogelijkheden:
- We willen het mogelijk maken via een directe link (in bijvoorbeeld een mail van de instelling) een gebruiker direct voor een type token te laten kiezen.
- Nadat een gebruiker de self service registratie heeft afgerond volgt er nog een contactmoment met de instelling, namelijk de vetting door een RA. Dit geeft de instelling nog controle (achteraf) op de gekozen tokens
Moet je je 2e factor binnen één browsersessie meerdere keren gebruiken of blijft dat per browsersessie gelden?
Besloten is om geen SSO aan te bieden op de sterke authenticatie gateway. Dit betekent dat:
- Ieder authenticatie verzoek van een SP altijd wordt doorgeleid naar SURFconext, en vanaf daar naar de instellings IdP. De Instellings IdP zal typish SSO aanbieden.
- Voor ieder authenticatie verzoek van een SP voor een LoA > 1 (dus ieder step-up verzoek) de gebruiker gevraagd wordt voor authenticatie met zijn/ haar tweede factor.
Hoe verloopt de enrollment van gebruikers?
Voordat een gebruiker gebruik kan maken van sterke authenticatie via SURFconext Sterke Authenticatie moet hij voorzien worden van een sterk authenticatie middel. Dit proces wordt ook wel "enrollment" genoemd. Enrollment gaat via de self-service Registratieportal van SURFconext Sterke Authenticatie. Het eerste gedeelte van dit proces is self-service. De gebruiker logt met zijn instellingsaccount (1e factor) in op de Registratieportal, en vraagt vervolgens één van de ondersteunde authenticatiemiddelen (SMS, Tiqr, YubiKey) in voor zijn account.
Om zijn authenticatiemiddel te laten activeren moet de gebruiker langs bij een RA (=Registration Authority, doorgaans een Service Desk of IT Helpdesk). Een daartoe geauthoriseerde medewerker (RA) zal na een succesvolle controle ophet bezit van het aangevraagde authenticatiemiddel en de identiteit van de gebruiker, het authenticatiemiddel van de gebruiker activeren.
Dit enrollementproces doorloopt de gebruiker eenmalig. Het is dus niet specifiek voor een enkele SP. Na het doorlopen van het enrollment proces kan de gebruiker de sterke authenticatie gebruiken met alle SPs die aan SURFconext Sterke Authenticatie zijn gekoppeld.
In principe kan iedere gebruiker van een instelling die gebruik maakt van SURFconext Sterke Authenticatie zichzelf enrollen via de enrollment website. In de praktijk verwachten we dat dit zal gaan met bijvoorbeeld een uitnodiging die aan de gebruiker verstuurd wordt door de instelling, of met een verwijzing vanuit een SP.
Hoe werkt single logout in combinatie met SURFconext Sterke Authenticatie?
Omdat er geen SSO plaats vindt op de Sterke Authenticatie gateway, is er ook geen sessie op de Sterke Authenticatie gateway waarop uitgelogd moet worden. Voor de 1e factor login maakt SURFconext Sterke Authenticatie gebruik van de functionaliteit van SURFconext. Voor (single)logout gelden dezelfde (on)mogelijkheiden als voor SURFconext. Zie ook:
- De blog "Damn you, single log out": https://blog.surfnet.nl/?p=2570
- En de factsheet: http://www.surf.nl/kennis-en-innovatie/kennisbank/2014/factsheet-making-log-out-work-for-a-single-service-on-surfconext.html
How can an application enforce a required level of assurance
The application (or Service Provider in SAML terminology) requests the required Level of Assurance (LoA) via its authentication request to the Strong Authentication gateway.
Voor het doorgeven wordt het gegevensveld "AuthnContextClassRef" uit de SAML 2.0 standaard gebruikt. Hoe dat precies werkt staat beschreven in "Requesting authentication at a specific LoA". Hiemee is het voor de applicatie mogelijk per authenticatie verzoek de gewenste LoA te bepalen. Zo kan bijvoorbeeld afhankelijk van de gebruiker, of afhankelijk van de in de applicatie gekozen actie om een authenticatie met een hogere LoA worden gevraagd.
In veel gevallen zal de applicatie moeten worden aangepast om dit mogelijk te maken. Daarom willen we het ook mogelijk maken om voor iedere combinatie van applicatie (Service Provider) en instelling (Identity Povider) een minimale LoA af te dwingen op de Sterke Authenticatie gateway. De minimum LoA wordt geconfigureerd op de Sterke Authenticatie gateway. De applicatie hoeft dan geen LoA op te geven. Gevolg is wel dat alle autehnticatie van een instelling naar een applicatie op het minimale niveau plaatsvindt.
Hoe gaat authenticatie als een applicatie sterke authenticatie wilt implementeren?
Step-up authenticatie wil zeggen dat een gebruiker na ingelogd te zijn op een applicatie met een lagere LoA, de LoA van de authenticatie verhoogt. Een applicatie die gebruik maakt van SURFconext Sterke Authenticatie vraagt niet altijd direct om step-up (maar dat kan wel). In plaats daarvan vraagt de Applicatie op een gewenste plek (bijv. admin functionaliteit) om een authenticatie met de door de applicatie vereiste LoA. Een voorbeeld:
- Een gebruiker logt in op een Applicatie. De applicatie vraagt de Sterke Authenticatie gateway om een authenticatie met LoA level 1, het laagste niveau.
- De Sterke Authenticatie gateway vertaalt dit verzoek in een authenticatie, via SURFconext, naar de IdP van de instelling waar de gebruiker authenticeert.
- De Sterke Authenticatie gateway stuurt het resultaat van de authenticatie terug naar de Applicatie.
- De gebruiker wil een actie uitvoeren in de Applicatie waarvoor sterkere authenticatie vereist is.
- De applicatie vraagt de de Sterke Authenticatie gateway om een authenticatie met LoA level 2.
- De Sterke Authenticatie gateway vertaalt dit verzoek in een authenticatie, via SURFconext, naar de IdP van de instelling waar de gebruiker, waarschijnlijk via SSO, geauthenticeerd wordt.
- Omdat voor LoA 2 een tweede factor nodig is, zal de Sterke Authenticatie gateway de gebruiker vragen te authenticeren met zijn tweede factor.
- De Sterke Authenticatie gateway stuurt het resultaat van de authenticatie terug naar de Applicatie.
Moet mijn applicatie in de cloud staan om van SURFconext Sterke Authenticatie gebruik te kunnen maken?
Om gebruik te kunnen maken van SURFconext Sterke Authenticatie moet een applicatie voldoen aan dezelfde eisen als een applicatie die gebruik wil maken van SURFconext. De belangrijkste technische eis is dat de applicatie voor authenticatie gebruik maakt van de SAML 2.0 standaard volgens het Web-SSO profiel. Zie: "Connecting a service to the SURFconext Strong Authentication gateway".
Een instelling mag eigen applicaties aanbieden op SURFconext en Sterke Authenticatie. Zie ook de SURFconext documentatie over het aansluitproces voor diensten van instellingen.
Als een instelling in de eigen IdP sterke authenticatie implementeert, kan die LoA dan doorgegeven worden naar SURFconext Sterke Authenticatie?
Nee. De mogelijkheid om vanuit de instellings IdP een hoger LoA door te geven, en dus geen gebruik te maken van step-up op de SURFconext Sterke Authenticatie gateway willen we (voorlopig) niet aan gaan bieden. Wat SURFconext Sterke Authenticatie biedt is authenticatie op LoA niveau 2 en 3. Hiervoor is zowel sterke authenticatie als sterke identificatie nodig, waarbij de identiteit van de gebruiker sterk verbonden wordt met het authenticatiemiddel. Deze sterke binding en identificatie vereist, naast technische ondersteuning, vooral ook werk op het gebied van organisatie en procedure. Met SURFconext Sterke Authenticatie hebben we voor een opzet gekozen waarmee dit zoveel mogelijk as a service aan de instelling kan worden aangeboden. In deze opzet levert de instellings IdP alleen authenticatie op LoA 1 niveau, de hogere LoA's worden gefaciliteerd door SURFconext Sterke Authenticatie. De management van de benodigde sterke authenticatiemiddelen en het registratieproces vinden plaats via SURFconext Sterke Authenticatie. Door deze opzet kunnen we sterke authenticatie bieden op dezelfde LoA niveau's vanuit verschillende instellingen:
- Zonder aanpassingen aan de technische infrastructuur van de instelling
- Zonder extra audit's van en eisen aan bestaande identiy management systemen en procedures van de instelling
Can an institution re-use its own strong authentication tokens
No. Not it if these are tokens from other vendors of authentication solutions like Vasco, Safenet etc.
The first release of SURFconext Strong Authentication will only support Yubikey hardware tokens (URL wijzigen!) and soft tokens Tiqr (app for iOS or Android) and SMS. Re-use of YubiKey tokens that are already used for is mogelijk. Omdat voor authenticatie gebruik gemaakt wordt van de Yubico authenticatie servers moeten de tokens voorzien zijn van de daarvoor benodigde configuratie. Yubikey tokens worden standaard geleverd in een configuratie die geschikt is voor gebruik met SURFconext Sterke Authenticatie.
SURFconext Strong Authentication is designed as such that it is possible of other authentication tokens in the future.
| Note |
|---|
iets toevoegen over security risico: secret wordt op 2 plaatsen gedeeld |
In geen geval kan een bestaande registratie, bijvoorbeeld wie heeft welk token in bezit, worden hergebruikt.
Ook hergebruik van tokens van andere leveranciers zoals bijv. Vasco, Safenet is niet mogelijk.
Why is the activation code designed as it is
...