<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<table width="100%" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td class="mPadding0" style="padding-bottom: 20px;"
valign="top" align="left">
<table width="100%" cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr>
<td valign="top" bgcolor="#FFFFFE" align="center">
<table class="mWidth100" style="width: 620px;"
cellspacing="0" cellpadding="0" align="center"
border="0">
<tbody>
<tr>
<td class="mHdrPadding" style="padding: 15px
0px;" valign="top" align="left">
<table width="100%" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<td align="left">
<table width="100%" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<td class="nb_title"
style="font-family: Arial,
Helvetica, 'Helvetica Neue',
sans-serif; font-size: 19px;
color: #000001; font-weight:
bold; line-height: 22px;"
align="left">SURFconext News
SP-edition 2017 #1</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td class="mHdrPadding" style="padding: 0px
0px;" valign="top" align="left">
<table width="100%" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<td style="padding: 0px 0px;"
valign="top" align="left"><img
src="cid:part1.AD5C87F2.DF6A326B@surfconext.nl"
alt="" moz-do-not-send="false"
class="" width="600" height="125"></td>
</tr>
<tr>
<td style="padding: 0px 0px;
line-height: 0px; font-size: 0px;"
height="16" valign="top"
align="left"><br>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<table width="100%" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td class="mFlexPadding" style="padding-bottom: 5px;"
valign="top" align="center">
<table class="mWidth100" style="width: 660px;"
cellspacing="0" cellpadding="0" align="center" border="0">
<tbody>
<tr>
<td valign="top" align="left"><br>
<table width="100%" cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr>
<td class="mPadding0" style="padding-bottom:
20px;" valign="top" align="left">
<table width="100%" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<td valign="top" align="left">
<table width="100%" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<td class="mHide"
style="width: 12px;
line-height: 0px; margin:
0px; font-size: 0px;"
valign="top">
<h2> </h2>
</td>
<td style="height: 12px;
line-height: 0px; margin:
0px; font-size: 0px;"
height="12"
bgcolor="#FFFFFF"> </td>
<td class="mHide"
style="width: 12px;
line-height: 0px; margin:
0px; font-size: 0px;"
valign="top"> </td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFFFF"
align="center">
<table class="mWidth100"
style="width: 620px;"
cellspacing="0" cellpadding="0"
align="center" border="0">
<tbody>
<tr>
<td class="nb_kop"
style="font-family: Arial,
Helvetica, 'Helvetica Neue',
sans-serif; color: #1570a6;
font-size: 15px;
line-height: 20px;
font-weight: bold; padding:
4px 0px 2px;" valign="top"
align="left"> </td>
</tr>
<tr>
<td valign="top" align="left">
<table width="100%"
cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<td valign="top"
align="left">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.<br>
<br>
<span
style="font-weight:
bold;">Who
receives this
newsletter?</span><br>
This new mailing
list contains all
technical and
administrative
contacts of a
service connected to
SURFconext.
Subscribe <a
moz-do-not-send="true"
href="https://list.surfnet.nl/mailman/listinfo/surfconext-sp-newsletter">here</a>,
or unsubscribe <a
moz-do-not-send="true"
href="https://list.surfnet.nl/mailman/options/surfconext-sp-newsletter">here.</a><br>
<br>
<a
moz-do-not-send="true"
href="https://wiki.surfnet.nl/pages/viewpage.action?pageId=60701393">See
the following page</a>
for an overview of
all mailings by the
SURFconext team.<br>
<br>
<b> In this edition:</b><br>
<ol>
<li>Dashboard for
Service
Providers in
development</li>
<li>‘Easier’
Connection
Agreement</li>
<li>SURFconext
Strong
Authentication</li>
<li>Offering
standardized
(de)provisioning</li>
<li>Attribute best
practice</li>
<li>Connect
services via
OpenID Connect</li>
<li>SURFconext:
also for mobile
apps and other
non-web services</li>
<li>Authorization
tools for IdP’s</li>
</ol>
<h1>Dashboard for
Service Providers
in development</h1>
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.<br>
<br>
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:<br>
<ul>
<li>login to their
own dashboard
(via SURFconext)</li>
<li>create new
entities</li>
<li>have a view on
the currently
connected
entities on the
test environment</li>
<li>provide
information
regarding
contractual part<br>
</li>
</ul>
Before the end of
this year, the SP
dashboard will be
available. You will
be notified via this
newsletter when the
dashboard will
launch.<br>
<h1>'Easier'
SURFconext
Connection
Agreement</h1>
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.<br>
<br>
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. <br>
<br>
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 <a
moz-do-not-send="true"
href="https://wiki.surfnet.nl/display/surfconextdev/Contractual+part">the
following
wiki-page</a>.<br>
<h1>SURFconext
Strong
Authentication</h1>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
For more information
check the <a
moz-do-not-send="true"
href="https://wiki.surfnet.nl/pages/viewpage.action?pageId=50110873">SURFconext
Strong
Authentication
documentation for
Service Providers.</a><br>
<br>
General information
about SSA is found <a
moz-do-not-send="true"
href="https://www.surf.nl/en/services-and-products/surfconext/what-is-surfconext/surfconext-strong-authentication/index.html">
on the surf.nl
website</a>.<br>
<h1>Attribute best
practice</h1>
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:<br>
<ul>
<li>There is no
need for storing
usernames and
passwords.</li>
<li>You can do
authorisation
based on
received
attributes.</li>
<li>Little user
information is
transferred from
de identity
provider to your
service.</li>
</ul>
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?<br>
<h3>Minimal
disclosure
principle</h3>
In line with the
forthcoming European
General Data
Protection
Regulation (<a
moz-do-not-send="true"
href="http://www.eugdpr.org/eugdpr.org.html">GDPR</a>), 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.<br>
<br>
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.<br>
<br>
<a
moz-do-not-send="true"
href="https://wiki.surfnet.nl/display/surfconextdev/Attribute+best+practice">In
our Attributes
best practice</a>
we explain the
different
possibilities, best
and second-best
options.<br>
<h1>Connect services
via OpenID Connect</h1>
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.<br>
<br>
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.<br>
<br>
<a
moz-do-not-send="true"
href="https://blog.surf.nl/en/connection-to-surfconext-becomes-easier-for-service-providers-with-openid-connect/">Read
our blog</a> to
learn more about the
benefits of OIDC,
and <a
moz-do-not-send="true"
href="https://wiki.surfnet.nl/display/surfconextdev/Preparation+with+OpenID+Connect">check
the documentation</a>
for more information
how to connect via
OIDC.<br>
<h1>Offering
standardized
(de)provisioning</h1>
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.<br>
<h3>SCIM</h3>
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.<br>
<br>
If you are
considering using
SCIM, or have
additional questions
on this technique,
please get in
contact with <a
class="moz-txt-link-abbreviated"
href="mailto:support@surfconext.nl">support@surfconext.nl.</a><br>
<h1>SURFconext: also
for mobile apps
and other non-web
services</h1>
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?<br>
<br>
<a
moz-do-not-send="true"
href="https://blog.surf.nl/en/surfconext-also-for-mobile-apps-and-other-non-web-services/">In
his blog</a>,
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.<br>
<h3>Best way of
authenticating in
apps</h3>
<a
moz-do-not-send="true"
href="https://www.rfc-editor.org/info/rfc8252"> A new RFC</a> 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.
<a
moz-do-not-send="true"
href="https://blog.surf.nl/phishing-hoe-maak-je-het-je-gebruikers-makkelijker/">SURFnet
is informing</a>
institutions why
proper
authentication
within apps helps
against phishing.
For app developers <a
moz-do-not-send="true"
href="https://blog.surf.nl/en/secure-login-from-apps-surfconext/">a
SDK was developed</a>
to easily
incorporate proper
federated
authentication.<br>
<br>
For more information
about federated
login on native
mobile applications,
<a
moz-do-not-send="true"
href="https://blog.surf.nl/en/federated-login-to-native-applications-sdk/">
read the following
blog</a>.<br>
<h1>Authorization
tools for IdP’s</h1>
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.<br>
<br>
All current options
are detailed <a
moz-do-not-send="true"
href="https://blog.surf.nl/en/making-surfconext-services-available-to-a-restricted-group-users/">in
this blog</a>.<br>
<br>
<hr></td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</body>
</html>