...
Properties of a rich client in SURFconext:
- Is not a browser (either a desktop or mobile application)generic web browser like Firefox, Chrome, Safari, Edge etc
- Communicates with a service connected to SURFconext
- Authentication is required
- Protocol can be anything from the Application layer in the OSI or TCP/IP model, including HTTP, IMAP, POP, SMTP, WebDAV, FTP, SSH
Examples of rich clients?
- Mail and calendar clients like Outlook, Thunderbird, Apple Mail
- Mobile apps for iOS (iPhone or iPad) or Android
...
1) Protocol based rich clients
A Some rich clients often uses its use their own authentication mechanism, often mandated by the protocol it uses. For example, a mail client like Thunderbird uses some mail clients use IMAP as the protocol to retrieve email and in most cases uses username/password authentication. These authentication mechanisms seldom support a browser based login necessary for federated access, and when they do special plugins or modifications are necessary. As more and more of the services are cloud based, there is little to no control over the server side capabilities. This combination of a lack of federated access support and the limited possibilities to modify cloud-based services results in issues with protocol based rich clients in a federated environment like SURFconext.
...
In the past years, many vendors have adjusted their (cloud) services to work with federated access. What this usually means is that the main web based interface can be secured with SAML which allows a login through SURFconext. Good examples of this are Google Apps, MS Office365, WebEx, Yammer, etc. However, with the rise of more and more mobile devices, the web based interface is not the only way customers interact with the service anymore. Mobile apps have become critical in delivering the service's functionality to their customers. These mobile apps use API's to communicate with the service and securing such an API can be implemented in many ways.
...
As described above, it completely depends on the vendor if a rich client can or cannot use a federated login (and thus SURFconext) at a service or application. However, an institution looking to use a service can ask the vendor several questions to evaluate if and how using a rich client can have issues with SURFconext:
- Does the rich client use Open ID Connect (OIDC)? If so: it should be able to work with SURFconext.
- Does the service offer a federated login for their main webbased interface? If not, chances are very slim that usage via SURFconext is possible at allthe rich client will work with SURFconext.
- Does the rich client use a protocol not compatible with a browser based login? If the client uses any protocol other than HTTP it is very likely that a browser based federated login is not possible. Workarounds are possible as demonstrated by Google and Microsoft .
- Is the rich client a mobile app? Support for a federated login is possible, but depends on the apps' implementation.
...
Unfortunately, there is no quick fix when the rich client does not support federated logins and thus does not support SURFconext. The options you are left with are:
- Pressuring the rich client vendor to support SAML for federated login. SURFnet or SURFmarket could play a role in organizing the institutions and building the federation case for the vendor. You can tell the vendor SURFnet has developed a free open source SDK so the vendor can rather easily incorporate federated login into the app.
- You could build your own rich client (see next section). You could use the above mentioned SDK.The easiest way is to ask the vendor whether they can supply a version that uses the OIDC protocol, which SURFconext supports. Read more at Connect your mobile app with OpenID Connect
- Use a product from a different vendor that does support a federation login and SURFconext.
- You could build your own rich client (see next section), taking note of the tips in Connect your mobile app with OpenID Connect
Building your own rich client (mobile app)
When you are in a position that you want/need to build your own mobile app, what could you do to optimally support a federated login and thus identity federations like SURFconext?
Roughly, there are two options:
...
Technical information on the implementation of such a mobile app:
- In 2015 SURFnet has developed a free open source SDK so you can rather easily incorporate federated login into the app. We blogged about this SDK.In 2016 Google developed the AppAuth SDK which they donated to the OpenID-foundationIn 2012 SURFnet has written a document explaining how a mobile app can work with SURFconext. It even contains links to two template applications, one for iOS and one for Android.
- SURFconext supports OpenID Connect, and allows connecting resource servers
...
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 (other than developing the SDK so as to make it as easy as possible for vendors). It is really something the developers should have build into these rich clients.
The result of this is that SURFnet SURF can inform the institutions on what to look for when evaluating services that have rich clients associated with them. SURFnet SURF and it's associated institutions can also join forces to persuade vendors to support federations in their designssoftware. 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 clientsclient, you can make the necessary modifications to support an identity federation and thus SURFconext.
Reference sites and documents
...
SURFconext
...
.
...