- Created by Unknown User (urn:collab:person:surfnet.nl:eefje), last modified on Mon 16 Jan 2017
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 49 Next »
Yes. In order to connect to SURFconext Strong Authentication, an application must meet the same requirement as when connecting to SURFconext. The main technical prerequisite is that a Service Provider must connect via SAML 2.0 using the Web Browser SSO profile. For more info: "Connecting a service to the SURFconext Strong Authentication gateway".
Yes. Every institution that is already connected to SURFconext as an Identity Provider, can connect its own services to the SURFconext Strong Authentication gateway. For more info: SURFconext documentation on how to connect institutional services or read our more specific documentation on how to connect services to SURFconext Strong Authentication
The application (or Service Provider in SAML terminology) requests the required Level of Assurance (LoA) via its authentication request to the Strong Authentication gateway.
To communicate the required Level of Assurance we use the "AuthnContextClassRef" from SAML 2.0. Our wiki "Requesting authentication at a specific LoA" describes how this works. This enables the application to define the required Level of Assurance for each authentication request. The required Level of Assurance can be determined by the application based on the user that authenticates, or the feature in the application that is selected. In most cases modifications to the application will be required to facilitate this.
The SURFconext Strong Authentication gateway also supports static configuration of a minimum LoA on the gateway based on the IdP and SP involved in the authentication. This enables an institution to enforce a minimum LoA for a certain Service Provider. The minimum LoA will be configured on the Strong Authentication gateway so the application does not have to be modified to specify the LoA during authentication. As a consequence authentication for all users from one institution to one application will then always require the same minimum LoA.
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.
For reasons of simplicity, transparency and security SURFconext Strong Authentication does not support SSO. This means that:
- Every authentication request from an SP will be redirected to SURFconext. SURFconext will redirect the request to the user's home IdP. This IdP will offer Single Sign On most of the times.
- Every authentication request from an SP with a LoA > 1 (which is every step-up request) will require a new authentication with the user's token.
SURFconext Strong Authentication does not support Single Sign On (SSO). As a result there is no active session on the Strong Authentication gateway for a user to logout. For first factor login SURFconext Strong Authentication relies on SURFconext. Therefore, the same issues for (single) logout apply. For more info read:
No. SURFconext Strong Authentication will not support the transfer of LoAs via the local IdP for a reason:
SURFconext Strong Authentication offers LoA 2 and LoA 3 authentication. This requires both strong authentication and strong identification, and a solid binding between the identity of the user and its authentication token. This solid binding and identification requires technical measures, but also organizational and procedural measures. SURFconext Strong Authentication is designed to offer this as-a-service to every institution. This set-up allows the institutional IdP to facilitate LoA1 authentication, while LoA2 and LoA3 authentication is facilitated by SURFconext Strong Authentication.
The required authentication tokens and the registration process are managed centrally by SURFconext Strong Authentication. This generic set-up, that is equal for all participating institutions, allows us to offer strong authentication based on Level of Assurance from different institutions:
- Without modifications to the technical infrastructure of the institution.
- Without extra audit requirements for existing identity management systems and procedures at the institution.
Local implementations of strong authentication at the IDP do not guarantee the same solid binding between the identity of the user and its authentication token. SURFconext Strong Authentication cannot guarantee to SPs that such an IdP-specific LoA2 and LoA3 implementation is equal to LoA2 and LoA3 facilitated by SURFconext Strong Authentication. Therefor this is not supported.
No. Not it if these are tokens from other authentication solutions like Vasco, Safenet etc.
The first release of SURFconext Strong Authentication will only support Yubikey hardware tokens and soft tokens Tiqr (app for iOS or Android) and SMS. Subject to certain conditions YubiKey tokens that are already used internally can be re-used. Since SURFconext Strong Authentication utilizes Yubico authentication servers these tokens need the appropriate configuration. Yubikey Edge, Neo and Standard tokens are by default suited to use with SURFconext Strong Authentication
The activation code should have enough entropy to prevent a guessing attack (an attacker should not be obtain the valid code via trial-and-error by generating codes), yet short enough to be written down by the user.
The activation code is valid for 14 days. So a user must visit a RA within 14 days after registering a token. To get a new activation code a user must delete the registered token and start a new registration.
The registration process is designed, to a greater or lesser degree depending on the assurance level, to ensure that the registration authority (RA) knows the true identity of the applicant. SURFconext Strong Authentication has implemented different controls in both its architecture as its infrastructure to mitigate possible threats:
| 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 employed to determine that a person with the claimed identity exists, and that the applicant is in fact the person who is entitled to that identity. These controls are federated login, e-mail verification, possession of activation code and face-to-face ID-proofing. |
Compromise or malfeasance of the infrastructure | Lack or poor implementation of security measures and policies undermine the reliability of the registration. | Infrastructure threats are addressed by normal computer security controls (e.g., separation of duties, record keeping, independent audits, etc.). Also a third party security audit on both software code and infrastructure was conducted. |
You can order YubiKey tokens online from any vendor. Yubikeyshop.nl offers a special discount for institutions in Dutch higher education and research. Click here for more info.
No. For security reasons only one token registration per user is allowed.Should a user wish to change his active token, he can remove the token registration and start a new registration process for a new token.
No. As explained in the previous question: for security reasons only one token registration per user is allowed. Should a user wish to install Tiqr on a second device, he must remove his Tiqr registration and start a new registration process for the new Tiqr app on his second device.
The length of the session is SP specific. We advise SPs to take into account the nature of the application and the data that is being processed within the application when deciding on the appropriate session length. For usability reasons the session length should not be too short (<15-30min?) but for security reasons it should also be not too long (>4-8 hours?).
It is NOT possible to activate the token of a user that is unable to appear in person at a Service Desk. Our policy - which is in line with ISO29115 - explicitly requires a user to appear in person during activation of his/her token, since a Registration Authority needs to verify both the identity of the user and the possession of the registered token.
There are multiple ways to achieve this:
- The easiest way is to remove the first factor of your user (username/password) through your regular exit proces/ IDM-lifecycle. By removing the first factor, the user can no longer use the second factor, since without a first factor authentication, the user will never reach the login screen that triggers the second factor authentication.
- You can also create a process within your institution to inform the RA's of your institution pro-actively that a certain user is no longer affiliated with the institution and its token registration should therefor be removed. The RA can then remove the second factor registration for the specific user through the RA Management portal.
- Addtionaly SURFconext Strong Authentication has a automatic deprovisioning process in place. Token registrations will be removed after 6 months of inactivity. Periodically users that have not used their token for 6 months receive reminders via e-mail, to keep their token activated by logging in once.
- No labels