So, is federation doomed when it comes to rich clients? Not really. It depends on many aspects of the rich client in question whether or not a solution is available. For example, it is important to know what protocol an existing client is using. Is it based on HTTP, or is it something completely different like IMAP? Is it a mobile client, or a client you use on a desktop or laptop? If a protocol like SAML is somehow involved, how is the user supposed to authenticate to the service? Is it possible to build your own client, or are you forced to use a vendor’s client?
As can be read in our report from January 2012, there are many different activities, taking different approaches in solving this problem. Some of them are still subject to experimentation, some have been deployed successfully. But it can be hard to determine if a solution exists for a specific service. Sometimes there are different solutions, and then it can be hard to decide what solution is best for a particular use case.
Your mileage may vary
So, what to do when trying to assess a rich client’s ability to use a federated identity?
Most importantly, it is crucial to know if the protocol used by the client to communicate to a federated service is based on HTTP, the web protocol used by browsers. If it is, it may be possible to use that client with a service connected to a Web-based federation like SURFconext.
If it isn’t, there are some tricks to get things working. Either you will need technology that is currently not implemented by SURFconext, like project moonshot (and with which our colleagues at Janet are experimenting) or the SAML ECP profile (which unfortunately is very rarely deployed in both clients and IDP software). We would love to hear from you if you have a use case for these technologies.
If the protocol in use is HTTP, some vendors have tried to enhance their clients with the common browser capabilities that are required to implement the SAML Web SSO profile that is used in most Identity Federations. On some platforms this is done by embedding a browser component into the client application. Google Drive is a good example of this approach.
Mobile apps
On mobile devices, like Android and iOS phones and tablets, there are some additional challenges. For example, if an IDP requires authentication using a client certificate, the embedded browser will not automatically have access to that certificate when installed on the phone (for instance using the iOS keychain). Mobile apps can use an effective paradigm to work around problems with embedded browsers. Instead of trying to act as a browser themselves, they simply “borrow” the system default browser to authorise themselves access to a user’s resources on the server. So instead of authenticating to the service directly, the app launches a browser, authenticates the user at their IDP, and asks for permission to access the federated service. After granting permission, the user is sent back to the native app (typically using a custom URL scheme like googledrive://) with a special code that the app can subsequently use to access the service. This whole process is more or less standardised in a protocol called OAuth.
Want to know more?
As you may have noticed, there is no trivial solution to the problem of rich clients. A blog post like this is not the right place for an extensive discussion on all possible options. If you want to know more about what options are available today when using rich clients in a federation, you can join us online during the upcoming SURF academy online webinar on Friday, December 13. And if you cannot make it to the webinar, we will make sure we will also publish our findings on our wiki.
0 Praat mee