The SURFconext team is proud to announce the first newsletter for Service Providers connected to SURFconext. This newsletter will bring you information regarding new developments, plans for the future and tips and tricks. SURFconext News SP-edition will appear on an irregular basis.
Who receives this newsletter?
This new mailing list contains all technical and administrative contacts of a service connected to SURFconext. Subscribe here, or unsubscribe here.
See the following page for an overview of all mailings by the SURFconext team.
In this edition:
- Dashboard for Service Providers in development
- ‘Easier’ Connection Agreement
- SURFconext Strong Authentication
- Offering standardized (de)provisioning
- Attribute best practice
- Connect services via OpenID Connect
- SURFconext: also for mobile apps and other non-web services
- Authorization tools for IdP’s
Dashboard for Service Providers in development
In order to make life easier for suppliers that connect services to the SURFconext platform we’re building a SP dashboard. The SP dashboard enables suppliers to self-service add, remove and change their services connected to SURFconext.
Currently, suppliers are invited to fill out the SP registration form and publish a service to the test environment of SURFconext. A request for production can also be made. After launching the SP dashboard, suppliers will be able to:
- login to their own dashboard (via SURFconext)
- create new entities
- have a view on the currently connected entities on the test environment
- provide information regarding contractual part
Before the end of this year, the SP dashboard will be available. You will be notified via this newsletter when the dashboard will launch.
'Easier' SURFconext Connection Agreement
More and more institutions have started to implement data processing agreements (DPA). Lately, SURF started receiving questions about the fact that certain articles in the SURFconext connection agreement seemed to overlap with articles in the DPA’s.
Therefore, in the first half of 2017 SURF has started to use a new SURFconext Connection Agreement. In this new Agreement, articles that are already part of a DPA have been removed. For instance, the audit requirement is part of a DPA, so it has been removed from the SURFconext Connection Agreement.
Connecting your service to SURFconext doesn’t require an audit anymore, but we assume institutions do inquire about audits before starting to use your service. In case you’re interested in the new agreement, read template at the following wiki-page.
SURFconext Strong Authentication
SURFconext Strong Authentication (SSA) offers secure access to services connected to SURFconext. Better security is particularly important for services handling sensitive data. It reduces the risk of unauthorized access to your service and prevents fishing attacks.
Strong Authentication is achieved by combining a strong second factor registration process with a 2-factor login. The first factor is the user’s institutional username and password, the second factor can be a SMS, Tiqr app or Yubikey. The registration process of the tokens is handled by the institution where the user is identified and the token is activated. The Service Provider does not need to manage any tokens or passwords.
To be able to use SSA, the Service Provider needs to connect to the SSA endpoint. There are only a few differences between a SSA and a SURFconext connection. SSA is pretty flexible as to when a user needs to perform 2-factor login. The Service Provider can request a regular username and password login or it can request a 2-factor login. Another option is to only request the second factor login when the user performs a high-risk operation (step-up).
For more information check the SURFconext Strong Authentication documentation for Service Providers.
General information about SSA is found on the surf.nl website.
Attribute best practice
For most Service Providers, connecting a service to SURFconext changes the way of dealing with users. Since you will receive user information from the identity provider in the form of attributes:
- There is no need for storing usernames and passwords.
- You can do authorisation based on received attributes.
- Little user information is transferred from de identity provider to your service.
But how do you deal with attributes? What are the do’s and don’ts? What attributes shall you request for your service keeping in mind usability and privacy?
Minimal disclosure principle
In line with the forthcoming European General Data Protection Regulation (GDPR), SURFconext assumes a minimal disclosure principle. This means that a service should only maintain (personal) information that is strictly necessary to provide the service. This principle applies to attributes requested from SURFconext, but also other data that is processed in the application.
For example: if your service allows users to share files with each other and sends out notifications to users when a new file is shared, you can use the user's email address attribute. However, if you only use the user's email address for marketing purposes, you might want to reconsider whether this fits the requirements of the GDPR.
In our Attributes best practice we explain the different possibilities, best and second-best options.
Connect services via OpenID Connect
The SAML2 protocol has been the only way to connect services to the SURFconext platform for years. We are glad to announce that last September, the first Service Provider connected their service using the OpenID Connect (OIDC) protocol.
OpenID Connect is a modern protocol (since 2014), but is already being used by major companies such as Google, Microsoft and Salesforce. For OIDC, more implementations are available for more programming languages than with SAML2. This means that you can easily integrate an existing piece of code into your own applications. This makes connecting to SURFconext a great deal simpler and faster.
Read our blog to learn more about the benefits of OIDC, and check the documentation for more information how to connect via OIDC.
Offering standardized (de)provisioning
Over the last months, as a continuation of a 2013 investigation, SURFnet has met with several institutions on the subject of (de)provisioning. While companies as Google and Microsoft (and the parties they work with) are adopting the SCIM-standard, new opportunities seem to arise.
SCIM
SCIM allows you to automatically add or delete (provision or deprovision) accounts for users in external systems, such as Google Apps for Work, Office 365 and Salesforce. We are very curious whether there are SP’s connected to SURFconext that consider making their service even more interesting by supporting SCIM.
If you are considering using SCIM, or have additional questions on this technique, please get in contact with support@surfconext.nl.
SURFconext: also for mobile apps and other non-web services
Many people know SURFconext as a simple and secure way of accessing web-based services. However, not all services can be accessed using a web browser. For example, more and more people are using mobile apps, and researchers often use a command line interface (e.g. for SSH). How can SURFconext help in these situations?
In his blog, Product Manager Raoul Teeuwen explores the different non-web scenarios and their challenges in a federated context. Some scenarios have been tackled, others are more problematic to incorporate.
Best way of authenticating in apps
A new RFC details how to do proper authentication from within an app. The Carnegy Mellon CERT blogged about what makes a proper app authentication. More and more app developers are starting to see the good practice and how this can be used while pitching the app to security conscious customers. SURFnet is informing institutions why proper authentication within apps helps against phishing. For app developers a SDK was developed to easily incorporate proper federated authentication.
For more information about federated login on native mobile applications, read the following blog.
Authorization tools for IdP’s
If you know what features institutions have to their disposal within SURFconext, it might take away existing questions or even problems for your service connected to SURFconext. The following scenario's might sound familiar: institutions often don’t want to allow all their students and employees to access a service due to limited license arrangements, different roles of users, and so forth. SURFconext has several ways to empower institutions to limit who within an institution can or cannot access a service.
All current options are detailed in this blog.
_______________________________________________
Surfconext-sp-newsletter mailing list
Surfconext-sp-newsletter@list.surfnet.nl
https://list.surfnet.nl/mailman/listinfo/surfconext-sp-newsletter