Clients & Accesses

• Introduction
• Use Cases
• Defining clients
• Defining accesses
• Authorization scopes
• Extra permissions

Introduction

TRAX LRS lets you control how third-party applications access the LRS APIs, thanks to the concepts of "clients" and "accesses".

A client is an external application. An access is an entry point for this application, with specific a endpoint, credentials and permissions.

Separation between the client and access concepts provides some benefits:

• It gives a great flexibility to carefully manage permissions of third-party applications.

• It gives the opportunity to isolate xAPI data depending of its source, and then perform specific operations later.

Use Cases

Back-end vs front-end

Let's take the example of an LMS sending xAPI statements to your LRS.

Some statements come from the back-end of the LMS. For example, the course completion which is determined by the server layout of the LMS. Other statements may come directly from the front-end. For example, a video player which detects user interactions (play, pause, etc.) and sends matching statements.

Both come from the same client, but need specific permissions:

• The LMS back-end is usually considered as more secured. It's a trusted application. We can allow it to post statements, but also to get statements for its reporting features.

• The front-end is less secured. It's played in the browser and is easy to hack. We need a CORS policy and we don't want to allow this kind of client to get all the LRS statements.

Testing vs production

Let's take again the example of an LMS sending xAPI statements to your LRS.

• Some courses are currently used by students. They send xAPI statements to the LRS and this data is considered as highly valuable. We want to preserve it.

• Other courses are not in service. Teachers are still building and testing them. They also send xAPI statements to the LRS, but this data does not reflect the learning activity. We want to isolate it in order to remove it later.

Defining clients

To define a client, go to the Accounts > Clients page and create a client with the following information:

• Name
• Entity (optional)
• Status: active clients are allowed to access the LRS, inactive clients are not.
• Authorization scopes (see below)
• Extra permissions (see below)
• A specific authority to be assinged to the incoming statements (optional).

Defining accesses

To define a client access, go to the Accounts > Clients page and click on the accesses link of the client. Then, create a new access with the following information:

• Name
• Credentials: username and password for Basic HTTP authentication.
• CORS: optional
• Status: active accesses are allowed to access the LRS, inactive accesses are not.
• Specific authorization scopes, if you don't want to use those of the client.
• Specific extra permissions, if you don't want to use those of the client.

Authorization scopes

Authorization scopes apply to the standard APIs as defined in the xAPI specification.

All

The client/access has unrestricted read and write access.

All/Read

The client/access has unrestricted read access.

Statements/Write

The client/access is allowed to write any statement.

Statements/Read

The client/access is allowed to read any statement.

Statements/Read/Mine

The access is allowed to read statements written by accesses of the same client.

State

The client/access is allowed to read and write states.

Profile

The client/access is allowed to read and write profiles.

Define

The client/access is allowed to update activities definitions.

Extra permissions

Extra permissions apply to the extended API provided by TRAX LRS.

Observe xAPI data

The client/access is allowed to explore the xAPI data of the LRS with the extended API.

Manage xAPI data

The client/access is allowed to delete xAPI data with the extended API.