Users of SURFconext often have questions around the usage of rich clients. This page tries to explain the different problems that can arise and the possible solutions or work-arounds for them.

What are rich clients?

The term "rich clients" or "fat client" is used frequently, but can mean different things. In the broadest sense, rich clients can mean any piece of client software that has functionality of it's own but also needs to communicate with software running on a server over a network (http://en.wikipedia.org/wiki/Rich_client). But, we are discussing this topic in the context of identity federations and SURFconext which means we already limit the type of rich clients. To be able to discuss the topic of rich clients we first need to determine what we mean by "rich clients".

Properties of a rich client in SURFconext:

  • Is not a 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

Issues with rich clients

When we look at the types of rich clients, we can divide them in two categories:

1) Protocol based rich clients

Some rich clients use their own authentication mechanism, often mandated by the protocol it uses. For example, some mail clients use IMAP as 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.

Common examples of protocols that fall into this category are IMAP, POP, SMTP, WebDAV, FTP, SSH. Examples of this type of rich client are Outlook, Thunderbird, Apple Mail and any of the mobile versions of these clients.

Some major vendors have recognized this issue and added functionality to their services that enable protocol based rich clients to work. Note that in these cases, the rich clients themselves have no special capabilities added.

2) Mobile apps

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, 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.

Many vendors that support a federated login to their main web based interface have developed their mobile apps in such a way that they can also be used in a federated environment. These apps use the mobile device's browser to handle the actual login. This is possible because on most mobile devices, an app can communicate with the browser and vice versa. See Google's Authenticating Users in Mobile Apps page for details.

Examples of mobile apps that support this method:

  • Most of Google's mobile apps (Google Drive, Google Search App)
  • Microsoft has added 'modern authentication' to their apps. See SURFconext's Microsoft Office365 wiki page for more details.
  • WebEx

Needless to say, when a vendor does not support a federated login for their main web based interface they will also not support it for their mobile apps. 

So what works and what doesn't work?

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 the 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.

So what then are the characteristics of a service with a high chance of supporting rich client federated access?

  • When the main webbased interface is configurable for federated login
  • The service uses the HTTP protocol for exposing the user's data

Please note that the above guidelines do not provide an exact method of evaluating rich clients. This always depends on the exact implementation of the rich client itself.

What if the rich client does not support SURFconext?

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:

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:

1) Build a website tailored for viewing on mobile devices. According to the definition presented at the beginning of this document, this is not considered a rich client. It is however a good alternative when you are considering building a mobile app and one that can easily support federated logins. The login for the mobile website could very well be handled federative and thus support SURFconext. This is not different from any other website. For more information on connecting a web application to SURFconext, see here. Some extra advantages from this approach are that you do not need to develop a separate app for iOS and Android.

2) Build a mobile app, specifically for one or more mobile platforms (iOS or Android for example). These types of apps use a data service that provides the data for the app to function. For example, a course scheduling application could contain a data service that mobile apps can use to show a student his personal schedule of the day or week. Currently, the method for retrieving this data is mostly done using REST API's combined with OAuth for the security. Note that for such a mobile app to work, the data service needs to implement OAuth as well and have that connected to SURFconext.

Technical information on the implementation of such a mobile app:

Conclusion

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 SURF can inform the institutions on what to look for when evaluating services that have rich clients associated with them. SURF and it's associated institutions can also join forces to persuade vendors to support federations in their software. 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 client, you can make the necessary modifications to support identity federation and thus SURFconext.


Bewaren

Bewaren

Bewaren

  • No labels