Overview

uPortal Sessions

Using uPortal always requires passing through the uPortal /Login servlet, even for "guest" (unauthenticated) use.  When a user first visits any uPortal URL, the user is redirected through the /Login servlet to establish a session.  As a result, the uMobile native application will first visit the /Login servlet during unauthenticated use to ensure that a session is appropriately created. (See uMobile Native Session Handling).  SSO systems generally redirect the user's browser to /Login after establishing authentication.

The uMobile native application uses the "service" parameter to redirect the browser to the "/layout.json" user layout service after the session is established.  The native code compares the username attribute contained in the layout document with any submitted credentials and assumes any mismatch is the result of failed authentication.

Credential Storage

uMobile native currently offers users a settings dialog that contains username and password fields.  If the user supplies values for these parameters, both values will be encrypted using a two-way encryption function, then stored in the app's local storage.  Each time the application is launched, uMobile uses these credentials in combination with the configured authentication strategy to attempt to establish an authenticated session.  When no credentials are provided, a guest session is established.

Local Authentication

In this context, "local authentication" refers to the portal's bundled non-CAS authentication capabilities.  This login option is available as the "/Login" path servlet in the uPortal application itself and typically authenticates against a local database store of test users.  In practice, this system is not often used in production, and the uPortal community recommends preferentially adopting an SSO strategy such as CAS or Shibboleth.

This system is used as the default option in the uMobile download, due to its simplicity and performance.  To use local authentication, the uMobile app simply needs to add userName and password parameters to the /Login servlet.

CAS

uMobile currently performs CAS authentication by manually stepping through the CAS login form on the user's behalf.  This requires the native application to parse the initial CAS login form, extract two dynamic form parameters, and submit a new request with those parameters and the user credentials.

Roadmap

Shibboleth

Shibboleth authentication is available in the Titanium Appcelerator uMobile client, but not yet implemented in the PhoneGap client.  Shibboleth authentication should likely be developed using ECP, and advice and assistance from the Shibboleth community would be valuable.

OAuth

While the current authentication strategy is effective, a number of institutions share concerns around storing user credentials on a local device.  Stepping through forms on behalf of the user is also less than ideal from both performance and maintainability perspectives.  A simple change to a login form has the potential to break native application authentication.

As an alternative, the uMobile community has considered implementing OAuth authentication.  OAuth would allow uMobile to store an authentication token which is application-specific and is not the user's university credentials.  This strategy would be most effective when paired with a web tool providing users with the ability to audit and revoke their OAuth tokens as desired.

Adopting OAuth does present some challenges, as it would prevent the portal from replaying credentials to services like IMAP or to other external websites.   Many universities also do not yet offer any OAuth authentication servers.  A new CAS module may help universities offer this authentication option.