FAQ

How can I test my (test)service on a permanent basis?

It is possible to test your service permanently on the SURFconext 'connect' environment (the test environment of SURFconext). Initial registration of your service is done via the Service Provider registration form  which can be obtained via support@surfconext.nl. Within this environment the DIY/test IdP is available for testing. Changes can be made via the same Service Provider registration form  and are available instantaneously. Note that the connect environment metadata is different from the production environment.

For the production enviroment, the use of Onegini IdP for testing is available for logging in into your application. Refer to Using Onegini as IdP for testing SPs.

What are the costs of connecting my service to SURFconext?

Connecting your service to SURFconext is free. However, you do need to take into account the costs involved with implementation and configuration of local systems. We also ask every service to deliver a security audit on a periodic basis. The security audit assures that privacy agreements stated in the SURFconext contract are met.

How does SURFconext guarantee my privacy?

On a technical level, we ensure privacy by encrypting before sending the data. But in order to ensure privacy, we make clear agreements with all participants of SURFconext, so that data will only be used for the purpose for which we agreed.

The agreements in the area of privacy are in the 'Privacy Best Practice'. This document is based on the Personal Data Protection Act (Wbp). The Privacy Best Practice explains the purpose why personal data is collected; the use of personal data is permitted only if it is necessary to achieve a specific goal, for example, authorization and personalization. Only the people who really need it, get access to this data.

Transparency for the user on the use of their personal data is guaranteed by informing the user when he is approached by a service through SURFconext. Also, there are rules about the maximum storage period of personal data. Participants of SURFconext are required to take security measures in order to prevent abuse of personal data. 
More information on privacy you will find at Contracten en Privacy (dutch). There you also will find the 'Privacy Best Practice' document.

How can I facilitate guest access for my service?

Until recently, SURFnet used SURFguest to facilitate guest access for SURFconext Service Providers. This is about to change with the introduction of Onegini. This FAQ gives more information about Onegini and the transition from SURFguest to Onegini.

What is Onegini?

Onegini is a new way of signing in that allows users to access online services in a safe and easy way using their social account (Facebook, Twitter, LinkedIn, Google).
 

What is the Level of Assurance of a Onegini account?

Onegini accounts are based on Social accounts (Facebook/LinkedIn/Google/Twitter) and are so-called 'self asserted accounts'. The identity of the users is not verified, except maybe an e-mail address verification. This means that you do not have certainty over the correctness of the user's identity, and these account have a low Level of Assurance (LoA). Please take this into consideration once you facilitate guest access. You can choose to restrict access rights for guest users based on their e-mailaddress or a group membership in SURFconext groups

What if users do not have a Facebook/ LinkedIn/ Google/ Twitter account?

Users can decide to create a local Onegini account without using a social account (Facebook/ LinkedIn/ Google/ Twitter account). For the user this results in the same functionality, although the user does need  to remember a new username/ password combination for Onegini.

How are Onegini & SURFconext related?

SURFconext signed a contract with Onegini about their offering of an application that facilitates guest-access to external applications using a social account. This contract contains arrangements on the continuity of Onegini, service levels, and the policies on privacy and security of data.

More information about Onegini:

More information about Onegini can be found on the Onegini website

Contact

If you need more information about Onegini & SURFconext, please contact us via support@surfconext.nl

Does SURFconext support provisioning?

No, SURFconext does not support provisioning. If your service needs provisioning, you need to engage your customers yourself and tell them your requirements. For more information go to article Provisioning.

Does SURFconext support Single Logout?

SURFconext does not support Single Log Out. For this feature to work all Service Providers have to make adjustments to their systems. It's impossible to enforce this for all Service Providers and one can never be sure a user is logged out at a service. Because of possible security issues, SURFconext does not support SLO

How does SURFconext support rich clients and mobile applications?

Wether a rich client supports federated login with SAML completely depends on the vendor or developer of that rich client. This support needs to be build into the rich client and often also on the server side of the service. Unfortunately, there is nothing an external federation party like SURFconext can do that would make the rich client compatible with a federation. It is really something the developers should have build into these rich clients.

The result of this is that SURFnet can educate the institutions on what to look for when evaluating services that have rich clients associated with them. SURFnet and it's associated institutions can also pressure vendors to support federations in their designs. Of course, when you have control of the service (you have implemented it yourself for example) and are participating in the development of the rich clients, you can make the necessary modifications to support an identity federation and thus SURFconext.

For more information, go to the SURFconext and rich clients article: SURFconext and rich clients

My metadata has changed. What should I do?

Before bringing your metadata to production, please inform us and provide us with the new metadata in order for us to prepare our systems. In this case there will be no downtime for the users.

Can I use SURFconext to login using a Social ID Facebook Google etc?

Yes. You can use Onegini to login at various services with your social ID.

Which attributes can SURFconext supply to my service?

SURFconext operates with a minimal disclosure principle. This means that only the absolute necessary (personal) information is transferred to a service. When requesting a SURFconext production environment connection, you need to specify the attributes you need from the list. SURFconext Support will review your attribute request and configure an Attribute Release Policy accordingly.

Which attribute should I use to uniquely identify SURFconext users in my application?

SAML has a specific element for identifying the authenticated user in the SAML response send to the Service Provider. This element is called 'NameID' and is always present in the SAML assertion (it is not an attribute and thus not subject to your service's Attribute Release Policy). Service Providers should use the NameID (rather than email address, or other attributes that might change over time) to identify users.

Does SURFconext support Shibboleth 1.3?

No, SURFconext does not support Shibboleth 1.3. The End Of Life date for Shibboleth 1.3 IdP and SP software was 30th June 2010.The minimal requirements for your federative authentication product is Shibboleth 2.0. Go to this article for more information how to upgrade your current product.

What do 'single-tenant' and 'multi-tenant' mean?

See Use of single-tenant and multi-tenant services in SURFconext.

How can I implement my own discovery screen?

If you want to have more control over how the Identity Provider Discovery is done or how the WAYF selection page looks, you can integrate a WAYF page in your service. To be able to do this, you need to know all available Identity Providers that have been coupled with your service. For this, SURFconext offers a special subset of metadata for any Service Provider that wants to do this. For more information go to following article: Use your own WAYF

Does SURFconext support ASelect/OpenASelect?

Because ASelect does not support SAML2.0, wich is mandatory for SURFconext, ASelect is not compatible with SURFconext. However, an open source version of ASelect, OpenAselect, does support SAML 2.0. For documentation on how to upgrade your system go to article: Upgrade paths for your IdP or SP to be SAML2.0 compliant (SP)

Is there a way for my users to authenticate and not use Single Logon?

Yes. It is possible for a Service Provider to force users to authenticate when logging in. If you set the ForceAuthn parameter to true, single sign-on is disabled (default value is false). If the user had a previously established session with SURFconext, this will be ignored and the user will be requested to authenticate again.

Is it possible to add my own branding to the SURFconext discovery screen?

When you connect your service to SURFconext, the default is that SURFconext will provide a WAYF selection page if necessary (when more than one Identity Provider is possible). It will show the Identity Providers that have allowed access to your service and/or that have bought a service license. If you want to have more control over how the Identity Provider Discovery is done or how the WAYF selection page looks, you can integrate a WAYF page in your service. To be able to do this, you need to know all available Identity Providers that have been coupled with your service. For this, SURFconext offers a special subset of metadata for any Service Provider that wants to do this. For more information how to do this go to article: Use your own WAYF.

Why doesn't my services gets attribute X?

The most common problem is that the IdP did not release the required attribute for your service. SURFconext operates with a minimal disclosure principle. This means that only the absolute necessary (personal) information is transferred to a service.

Can I get statistics about the number of users who log in to my service via SURFconext?

Currently it is not possible to get statistics about the number of logins to a service.

What is a virtual IdP vIdP or Virtual Organisation IdP?

A vIdP is an Identity Provider (IdP) provided by the OpenConext platform.  It consists of:

• a group of users (as defined in either OpenConext Teams+Grouper, or at an External Group Provider);
• a group of IdPs;
• a combination of the above.

A concrete example is in grid computing (see the Wikipedia article on VOs) where a VO may be a group of researchers from different institutions whose access to a supercomputer or data from the CERN supercollider is their only commonality.  Their institutions may not be part of a common federation.

What is a Virtual Organization or a Collaborative Organization?

A Collaborative Organization (or Virtual Organization) is an organization which does run its own IdP, but rather depends on other institutions to deliver identity information for its users.  Typical examples are research collaboration such as CLARIN or ELIXER, in which users from different universities collaborate on a common topic.  In such a case, the Collaborative Organization offers (computing) facilities, which need to be accessible to ll its researchers, even though they log in using the identity and IdP of their home university.

SURFconext offers some support for such collaborative organizations, typically by using a virtual IdP (see above) to combine individual users from multiple IdPs in a single "virtual" IdP that is visible to the SP.

Can I offer my service to foreign universities via SURFconext?

Yes. SURFconext is connected to the EduGAIN service. EduGAIN makes it possible for services connected to SURFconext to be made available for foreign universities. The technical implementation differs from a connection to the SURFconext hub with Dutch institution. Services who want to connect to foreign universities should make separate connections to non-Dutch IdP's (mesh). Please contact the SURFconext Team for more information (support@surfconext.nl)

What is the difference between SURFfederatie and SURFconext?

SURFfederatie is a platform which educational and research institutions can use for access to various (cloud based) services. SURFconext expands the functionalities of SURFfederatie and makes various features like online collaboration, single sign on and group management more easy. As of the 1st of January 2014, SURFfederatie will no longer be available.

How can I use groups provided by SURFconext?

SURFconext Teams provides students, researchers and staff at institutions with an easy way to manage collaborative groups. The management of groups is organised centrally and the groups can be used with various cloud services. For instance, a group can be set up for members of a research team so that only team members are given access to restricted data within a particular cloud service. More information on how to use groups can be found on this article: VOOT definition.

Does SURFconext support authorization?

SURFconext is mainly a platform for authenticatin, but offers limited support for authorization, mainly in the context of VOs (i.e., limiting access to a specific SP based on group membership).  However, we strongly recommend you to implement an autorization component in your own application.  

SURFconext can apply a number of attributes which can be used to base authorization decisions upon, such as the user's home institution, his affiliation (student, faculty, etc), and group memberships. In addition, SURFconext can pass on custom entitlements from an IdP to an SP.

Does SURFconext support other authentication protocols like OpenID Connect or Facebook Connect?

Currently, SURFconext formally only supports SAML2.  However, there is also the possibility to use OAuth 2 to authenticate, and we are interested in extending this to a full OpenID Connect service.  If you are interested in working with us on that topic, please contact surfconext-beheer@surfnet.nl.

How do I relay a student or employee number from my IdP to an SP?

Since februari 2015, SURFconext supports the schacPersonalUniqueCode attribute to relay institution-specific student and employee numbers to SPs.  Please note that at this time, only a very limited number of IdPs are providing this attribute.  If you are running an SP and would like to use this attribute, or is you are running an IdP and would like to provide it, please contact support@surfconext.nl. 

How do I transmit non-standard attributes from an IdP to an SP?

SURFconext is limited in the attributes it will pass on between IdPs and SP.  The full supported set (consisting of standard attributes only) can be found at this page.  

Sometimes, it is required that an IdP sets a custom attribute to the SP.  In SURFconext, we use the eduPersonEntitlement attribute (urn:mace:dir:attribute-def:eduPersonEntitlement /

urn:oid:1.3.6.1.4.1.5923.1.1.1.7) for this.  To scope the entitlement values, we include the SP's principle domain in the value.  

For example, suppose an SP named "bookkeeper.example.org" needs the "FinanceRole" attribute, which can have values "user", "manager", "administrator".  In SURFconext, these are passed on in an eduPersonEntitlement as follows:

• urn:mace:dir:attribute-def:eduPersonEntitlement = urn:x-surf.nl:example.org:FinanceRole:manager

Why is my SP being removed from SURFconext?

 We want to make sure that the connections between SURFconext and SPs that are defined in our systems are both active and functional.

To that end, we check periodically if an SP is still being used.  If no logins are recorded for an SP in a specified amount of time (see below), we will remove the connection from SURFconext.  Before removing the SP, we will notify the registered contacts and give them the opportunity to show the connection to SURFconext is still active and functional by logging in to the SP.  If no new login is recorded, we will remove the connection from SURFconext.  

Of course, if the SP needs to be reactivated in the future, a new connection can be made by following the regular procedure.

Currently, the timeout periods are defined as follows:

Furthermore, test connections will have to receive at least 1 login within the first 6 months after they have been defined in SURFconext.  Otherwise, they will be removed using the procedure specified above.