You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Can I test my (test)service on a permanent basis?

In the Test environment DIY/test IdP is available for testing. Register your service with the Service Provider registration form. Note that the metadata for the Test environment is different from the Production environment.

In the Production environment you can login with Onegini IdP into your application for testing. [Refer to Using Onegini as IdP for testing SPs.]

How does SURFconext guarantee my privacy?

All data are encrypted before they are sent. SURFconext also makes clear agreements with all participants ('Privacy Best Practice') that data will only be used for the purpose for which we agreed.

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. 

For more information on privacy: Contracten en Privacy (dutch).

How can I facilitate guest access for my service?

With Onegini.

Does SURFconext support provisioning?

No, if your service needs provisioning, you must arrange this yourself.

Does SURFconext support Single Logout?

No.

How does SURFconext support rich clients and mobile applications?

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

Please inform us and provide us with the new metadata, before you bring them to the Production environment. If you do so, there will be no downtime for the users.

Can I use SURFconext to login with a social ID (Facebook, Google, etc)?

Yes, with Onegini.

Which attributes can SURFconext supply to my service?

SURFconext operates with a minimal disclosure principle: only the absolute necessary (personal) information is transferred to a service. When you request a connection to the Production environment, you must specify the attributes needed. We 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, you must use Shibboleth 2.0 or higher.

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

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

Can I implement my own discovery screen?

Yes, you can find all the info in this wiki.

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 only SAML2 and OAuth 2 are supported. In the (near) future we will also support other protocols like OpenID.

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?

If an IdP needs to send a custom attribute (not in the standard list) to the SP, the eduPersonEntitlement attribute can be used:

(urn:mace:dir:attribute-def:eduPersonEntitlement / urn:oid:1.3.6.1.4.1.5923.1.1.1.7)

To scope the entitlement values, we include the SP's principle domain in the value.  

The SP "bookkeeper.example.org" needs the "FinanceRole" attribute, with possible values "user", "manager" and "administrator". In SURFconext, this can be passed on in an eduPersonEntitlement:

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

Why is my SP being removed from SURFconext?

We check regularly if an SP is still being used. If no logins are recorded during some time (see below), we will remove the connection. Before doing so, we will notify the SP.

Currently, the timeout periods are defined as follows:

 
timeout
grace period
Test connections1 year14 days
Production connectionsunlimitedn/a

Test connections must receive minimum 1 login within the first 6 months. Otherwise they will be removed.

  • No labels