Linking research & learning technologies through standards

Late last year Link Affiliates carried out some research for the Australian Flexible Learning Framework’s E-Standards for Training business activity to

identify and document the potential applications of a trust federation approach in the Australian Vocational Education and Training (VET) sector

We were asked to create use cases (scenarios) that clarify the benefits of a VET trust federation, and to identify appropriate technologies for each scenario (the research brief recognised that different technologies might be appropriate for different scenarios).

The resulting analysis identified a number of VET services that could benefit from a trust federation, but also uncovered a complex trust environment with overlapping identity and service providers, and found that no single technology was appropriate for all of the use cases. This post summarises of our findings. Check out the report on the E-standards for Training website for full details …

Potential services

After interviewing a selection of VET stakeholders about authenticated access to services and identity management, we uncovered many services that might benefit from a trust federation approach to authentication and access control, including

• providing student access to portals, learning environments, collaboration environments, e-portfolios and learning  content;
• employer access to learner e-portfolios; and
• purchaser access to cost centres in publisher systems.

A complex trust environment

We analysed the VET trust environments described in our interviews based on a simple diagram from the Towards a Trust Federation for the VET sector paper. The diagram shows organisations in a trust federation either

1. contributing services to the federation,
2. providing identity information about registered users to the federation, or
3. consuming services in the federation.

The VET sector trust environment turned out to be quite complex, reflecting the heterogeneous nature of organisations in the sector. VET organisations range from small private training organisations with little I.T. capability, through to large TAFE institutions that act relatively independently, right up to government jurisdictions that manage and support a number of TAFE institutions. The picture gets complex when you realise that:

• identity might be provided within the organisation (e.g. a TAFE) or outside the organisation (e.g. via the jurisdiction or delegated to a 3rd party identity provider)
• services might be provided by the organisation or the jurisdiction or a 3rd party service provider
• users might have identities in many organisations

There were also significant differences around philosophies of sharing services – within a jurisdiction or system, between jurisdictions, and between public and private organisations. Some service providers were set up to provide free access to services for all (e.g. the national Learning Object Repository Network), some service providers provided commercial access to all (e.g. commercial licences under AEShareNet) and some provided a mixture of free access to some, commercial access to some and no access to some (e.g. a learning environment hosted by a jurisdiction might be freely available to TAFEs in the jurisdiction, commercially available to businesses and not available outside the jurisdiction at all).

The picture was further complicated by whether a user’s role influenced access to a service. Several use cases allow the possibility that any user authenticated from a given organisation may access any service from the service provider. Others required finer grained access, determined by role (more on this below).

Technologies

Once we had identified use cases, we investigated trust federation technologies that might usefully support them. A few viable trust federation technologies were identified, each differing in both their level of complexity and the level of trust they supported:

Low complexity, low trust

• Shared secret: A very simple trust federation where the service provider supplies a simple ’secret‘ to a user that gives access to the service. Access is typically only open for a short period of time, after which the secret will no longer work.
• Self-asserted OpenID: This form of OpenID is commonly used on the web. Service providers delegate the responsibility of authenticating a user to identity providers. Services chose which identity providers they trust, but don’t care that most identities are self-asserted. That is, the don’t care that the identity provider doesn’t verify that the user ‘tsmith’ is in fact the Tamara Smith she claims to be.

Medium complexity, medium trust

• Trusted OpenID: In this form of OpenID, identity providers vouch for the trustworthiness of user identity assertions and these assertions are trusted by service providers. For example, a jurisdiction might act as an OpenID identity provider. The jurisdiction only creates student identities through a student enrolment process that checks documentation. A service provider might only trust users authenticated through the jurisdiction identity provider.
• Trusted OpenID plus Attribute Exchange: This is an extension of the basic OpenID specification that allows an identity provider to exchange user information with a service provider. For example, a service provider may require information about the user’s institutional affiliation or their role (eg teacher, student, etc).

High complexity, high trust

• Shibboleth: Shibboleth supports federated authentication and authorisation using the OASIS SAML standard. It is being deployed as part of the Australian Access Federation supporting the higher education sector. Like OpenID with Attribute Exchange it allows an identity provider to exchange user information with a service provider. There is a perception that Shibboleth is more complicated and difficult to deploy than OpenID, but the complexity does have advantages in some scenarios: unlike OpenID, it can support anonymous access to services (where no identifying information is provided to the service). Shibboleth also has security mechanisms that mean it is not susceptible to some of OpenID’s security vunerabilities.

Mapping use cases to technologies

A couple of use cases are presented below to illustrate how different use cases are supported by different technologies. See the full report for more detail.

Employer access to an e-portfolio

A scenario that only required low level trust involved a potential employee sharing a view of their e-portfolio with an employer that they already know:

An employer wishes to view a potential employee’s e-portfolio. Learner creates a view of their e-portfolio and gives the employer a ’secret‘ to access the e-portfolio.

The scenario could be supported by the shared secret trust federation technology. For example, the learner might give the potential employer a limited-time URL to access his/her e-portfolio. Another example of a shared secret is a four digit PIN that provides limited-time access to the e-portfolio.

Self-asserted OpenIDs could also support this scenario: The employer gives the potential employee their OpenID, and the employee provides limited time access for the OpenID. Even though the OpenID is self-asserted (not sourced from the employers identity management system), the employee trusts the OpenID because they get it directly from the employer (e.g. via an email).

Managing organisational purchases from LORN

A scenario requiring a medium level of trust and complexity involved reviewing an organisation’s purchases from the Learning Object Learning Network (LORN).

User logs into LORN via their own organisation using credentials normally used to log into their own organisation’s portal. The organisation then lets LORN know that the user has been authenticated. Based on their role, the user can discover financial details of all LORN purchases made by individuals from their organisation.

In this scenario the service provider needs to know more about the user: where they are from and what role they play in the organisation (only users with financial delegation should see purchasing information). Self asserted OpenIDs would not support this scenario: the service provider wants to be sure that the user is from an organisation they trust. Trusted OpenIDs are also not enough to support this scenario: the service provider needs to know that the user has an appropriate role in the organisation. For that reason, for this scenario we only considered trust federation technologies that vouch for the user’s credentials and can share user attribute information, namely Shibboleth and OpenID with Attribute Exchange.

Where to from here?

Our analysis and final report identifies obvious advantages for deploying trust federation technologies in the VET sector, but more work needs to be done:

• Some technologies support all the scenarios (Trusted OpenID with Attribute Exchange and Shibboleth), but are complex to roll out. Some technologies are simple to roll out but only support a few scenarios (Shared Secret, Self-asserted OpenID). Clearly a cost / benefit analysis of the technologies and the scenarios they support needs to be done.
• It is not clear if users are willing to move in this direction: our project did not talk to users of services and get their perspectives on how they would like to participate in trust federations. For example, do users have privacy concerns about trust federations?
• Our consultations highlighted that small private RTOs do not necessarily have the wherewithal to be identity providers, and may want or need to use third-party identity providers. This raises issues of governance and how to provision third party identity providers
• The relationship with trust federation work in the schools and higher ed sectors also needs to be considered: a number of jurisdictions have dual sector considerations (combined schools and TAFE departments) and some have dual sector institutions (TAFE and higher education).
• Finally, analysis of other trust federation technologies is warranted. In particular, OAuth is emerging as a technology that can support a number of the use cases we uncovered. (Unfortunately, we didn’t have time to consider OAuth in our analysis). Experience from the SIF-AU pilot projects in the schools sector shows that a combination of trust federation and provisioning technologies (like SIF) can support the use cases. The pilots have shown it is possible to use SIF to provision user information (such as roles) across services and trusted openID to authenticate users into those services.

In our opinion, none of these issues should be a barrier to moving forward. Probably the next step is to fund a project that addresses the points above and develops a prototype trust federation based on OpenID with Attribute Exchange for a widely used service like LORN. While many VET service providers and organisations are in a state of flux in terms of determining their policies and service offerings and indeed who can access those services, a prototype would provide a useful forum to test approaches. It could then be used as a foundation to build a wider VET Trust Federation.