Increasingly, students are studying independently of time and place. The type of device they use is dependent on the situation they find themselves in at the time. Supporting a number of different types of device places constraints on the way in which educational institutions grant access to their services via mobile interfaces. Optimisation of touch interfaces, the application of responsive design principles or other forms of authentication and authorisation are important here.
In this context, on Wednesday 9 December 2015 SURFnet organised a meeting on mobile access to institutional services. During this meeting, advice was given on the design of applications for mobile interfaces, taking good and bad practice as examples: what are design principles for optimum user interaction? When do you choose to develop a native, web or hybrid app? How do you implement authentication and authorisation solutions for mobile apps? And how can a higher education institution incorporate institutional data securely into mobile apps? And: what components do you need for this? Wes Oudshoorn (freelance web designer), Joost van Dijk (technical product manager for SURFconext at SURFnet) and Tom Kuipers (developer at the University of Amsterdam) shared their expertise.
Problems and solutions were also discussed with the ICT advisers, application developers and operations managers of higher education institutions who were present at the meeting: what problems do they encounter when developing or using institutional services for mobile interfaces? What solutions do they see from SURFnet, higher education institutions or suppliers?
Web apps and native apps
In his presentation, web designer Wes Oudshoorn outlined the advantages and disadvantages of the use of native and web apps. A web app is the mobile version of a website and a native app is a platform-dependent version of an application for a smartphone, which is distributed via an app store. Oudshoorn admits that choosing between web and native is a complicated business. As a developer, you sometimes just have to find out what works best. His advice: keep the design simple and test it on real users.
In the second part of his presentation, he looked at design principles for user-friendly mobile applications and responsive design. Wes Oudshoorn advises application developers to pay attention to the transition between web and native apps. A good example of this, he says, is the ING app, where the native app can be opened from the web and Relay, which allows you to buy products through Twitter at the push of a button.
Fluid design and progressive enhancement
He also made reference to single-column mobile first on the website of Dutch broadcaster NOS, where just 1 column of text is displayed on a smaller screen. ‘As soon as you use a bigger screen, the opportunities increase’. Responsive websites work in two ways: not only smaller to a mobile device, but also bigger to a bigger monitor. ‘With a big screen, you can navigate over the entire width.’ As well as responsive design, there’s also fluid design. With fluid design, you can scale in percentages and make optimum use of the space on different sizes of screen.
As to how to manage upgrades to browsers, Oudshoorn said that progressive enhancement was a possible solution. That way, older versions of the browser could still be used even if an upgrade had taken place. You would have to opt for this when creating a new application.
Security and usability
In his presentation, Joost van Dijk, technical product manager for SURFconext at SURFnet, drew attention to the danger of apps where it is unclear which provider is storing the login details. There’s a risk of data falling into the wrong hands (phishing). Users can’t always see who their login details will be received by.
Indirect authentication is a solution for secure login with a third party in the cloud. The higher education institution acts as identity provider and the user authenticates himself as if he was logging into a cloud service, the service provider. The password doesn’t leave the institution. SURFconext, SURFnet’s authentication and authorisation service, supports this scenario for indirect authentication, which uses the SAML protocol. In order to ensure that an application is both user-friendly and secure, use is made of the OAuth2 authorisation protocol. Through this protocol the user consents to a mobile app acting on his behalf. After login, a token is automatically requested for authorisation. This token is stored in the client. It works in the same way as giving LinkedIn access to address details which are stored by a third party.
SAML works well for web applications which are accessed via a web browser. But a native app uses a platform-specific browser, and that is often not compatible with SAML. However, application developers often use a workaround to support indirect authentication for native apps, such as embedded web browsers and application-specific passwords. From a security perspective this is not ideal. So SURFnet went in search of a secure, user-friendly solution and considers in-app URLs as a current best-practice.
With in-app URLs, the default browser is used to complete the login process. In combination with OAuth2 for exchange of the token between the browser and the native app. Advantage: the user can verify both the URL and the cloud service’s server certificate.
In SURFnet’s GitHub environment, Software Developer Kits (SDKs) are made available in order to make indirect authentication and OAuth2 for native apps easier to implement. You can use them for Android, Windows and iOS. SURFnet invites developers to test these SDKs and give feedback on them.
To implement OAuth2, the higher education institution needs an authorisation server. The advantage of hosting an authorisation server at the institution itself is that the tokens stay close to the institution and under its control. But not all higher education institutions want to host this authorisation server themselves. A year and a half ago, it was suggested that SURFnet should offer a centralised authorisation server and that higher education institutions should contract this service out to SURFnet. At the time, there was insufficient interest in this idea from higher education institutions. But this interest is growing. ‘If you’re interested now, just let us know,’ says Van Dijk. Institutions now moving to the cloud where US organisations dominate. ‘If we’re driving people in that direction, there’s a good argument for SURFnet to offer it.’
Open Education API
The presentation by Tom Kuipers, a developer from the University of Amsterdam, linked in well with this: secure access to institutional data with OAuth2. He talked about the University of Amsterdam (UvA)’s integrated platform, in which all the data from different source systems, such as Blackboard and the SIS, is combined and can be accessed from a mobile device through a single portal. He based the API on the Open Education API, a standard REST API for access to educational data. The MyUvA app is a hybrid app which he developed using the Cordova framework. A hybrid app is a combination of a web app and a native app with the flexibility of a web app, but which is developed in a platform-independent way. A hybrid app uses a kind of embedded browser. These embedded browsers differ in functionality from one Android version to another. This means you can use Crosswalk. This gives you a bigger app, but you’ll always have the most up-to-date version of the embedded browser with the same functionality whatever the Android version. Kuipers points out that since iOS9, Apple has imposed more stringent requirements in terms of security, which means that all kinds of certificate issues can occur.
Tom Kuipers sees a number of different solutions for authorisation servers. Standalone versus part of an API Manager and internal versus external hosting. UvA chose to host its integrated platform externally, but to host its authorisation server internally.
Round table sessions
The presentations answered the main questions the institutions had. In the round table sessions, attendees were given the opportunity to broach other problems that they encounter within their own institution and to discuss solutions to them. For example, what determines which framework you have to use to develop a hybrid app, e.g. Cordova or Xamarin? According to Wes Oudshoorn, the user experience (UX) with hybrid apps isn’t ideal because many operating systems adopt the one-size-fits-all principle. ‘If you’re prepared to put up with a lower level of interaction, hybrid is a good choice because, in that case, you only have to work with one code.’ And some design issues can be solved in Cordova.
White label app
This was followed by a question for Kuipers about a white label app. Can he strip the UvA app down so it can be used by other institutions? Developing an app isn’t difficult if access to data sources, authentication and authorisation are well organised at the back end. Some higher education institutions find it hard to implement the back end, with the provision of access to data sources through an integrated platform, interfaces and APIs. ‘If developing the front end is easy, it’s easier to sell the work on the back end’, as one participant put it in a nutshell. SURFnet should be able to offer a development environment that contains a front end.
Boundary between business and private
One participant pointed out that, as of 1 January 2016, the personal data protection legislation will become more stringent. Will we have to move to two-factor authentication as a result? SURFconext has an implementation for two-factor authentication. In this context, the question put by Eric Griep from the University of Leiden is an interesting one: how, as a developer or higher education institution, do you define the boundary between the use of mobile technology for business and private purposes? He says this is a major challenge for both employees and employer. To what extent must the content and data of employees or sensitive data be protected? Is it desirable and feasible for a manager to be able to remove this data? lf this is normal on desktops and laptops, why shouldn’t it be on mobile devices? According to Kuipers, the answer to this question depends on the culture of the institution. Ultimately, the issue is how careful end users themselves actually are. ‘We spend so much time on security, but users still click OK,’ said one participant. But end users must still be given the opportunity to work securely with institutional services. The higher education institution must inform and educate end users but it must also offer them this secure, user-friendly solution. We must work on this.
View the presentations online:
- Native, Web & UX (Wes Oudshoorn)
- Authentication within web and native apps via SURFconext (Joost van Dijk, SURFnet)
- Secure access to institutional data with OAuth2 (Tom Kuipers, University of Amsterdam)