U.S. flag

An official website of the United States government

Advanced Distributed Learning Initiative

# User and Identity Management

Access to the TLA Sandbox is managed through the User and Identity Management Service. The TLA Reference Implementation uses KeyCloak (opens new window) to manage users and their access to the TLA components and services. The Learner Profile also tracks a user’s roles and permissions within the TLA and uses the Learner’s OpenID as generated by Keycloak. To see how the User and Identity Management leverages the Learner Profile, see the Learner Profile section of the TLA CMM Level 2 - Rollup of Learner Performance chapter of this document.

# TLA Core Services Portal

A generalizable TLA Portal (opens new window) is the common access point for all connected TLA resources. It’s the front end to TLA / EDLM Data Services such as a local course catalog, local competency registry, and local learner profiles. In that role, the portal includes tools and services required to connect and leverage those data, including dashboards for the different roles (personas) that will be accessing the learning ecosystem. The portal also serves as a common launch point to access connected learning resources such as the LMS, PERLS, PEBL, and the cmi5 player. It also includes other capabilities designed to connect learners with other learners, relevant content, and other experiences that the learner might be interested in. TLA Sandbox users are encouraged to build upon the existing portal capabilities or implement their own portal systems (as an edge system) to access the key features they need.

Currently, the TLA Sandbox supports two login roles (learner and instructor) but this will be expanded to support any number of additional roles in the future (e.g., course manager, competency manager, designer/developer). At this time, the instructor role is the same as an admin role. As the TLA Sandbox matures, the admin role will be separated from the instructor role.

# Keycloak

Keycloak is a free and open-source identity and access management system. For more information on what Keycloak is and how to leverage it, please see its public documentation on GitHub (opens new window).

Currently the registration process for new user accounts is managed through ADL Initiative personnel. Please contact ADL Technical Support to learn how you obtain access. The ADL Initiative staff can create new user accounts for any DoD organizations interested in the TLA and can provide a list of services that can be accessed via the given credentials. Changes to Keycloak’s configuration and the public API require administrator-level permissions, so access is not currently available past a new user account.

2021 work on the TLA sandbox includes numerous additional functions for Keycloak. Integration with Public Key Infrastructure (PKI) certificates will support future emulation of CAC authentication to support conformance to the DoD's ICAM Strategy (opens new window) and the DoD's ICAM Reference Design (opens new window). The ADL Initiative is also working to better integrate KeyCloak with the Learner Profile system, including the automatic initialization of new learner profiles upon registration and improving the security model to enable role-based access.

Details on the service, port usage, and container layouts for the Auth server can be requested from the ADL team.

# Using Keycloak as a client

The ADL Initiative maintains Keycloak and does not provide root access to outside parties. However, the ADL Initiative will create a client account for outside vendors to allow them to leverage the same Single Sign-On (SSO) service as the rest of the TLA.

To use Keycloak as a client, an instance of WildFly (opens new window)must be stood up. Before this service is started, Keycloak’s Open ID Connect (OIDC) (opens new window)adapter distribution needs to be added to the root directory. This code can be found at https://www.keycloak.org/downloads.html (opens new window). After the new adapter is extracted to the correct folder, run the adapter-elytron-install-offline.cli file to automatically configure WildFly to leverage Keycloak, then start the server.

Once the WildFly server has been started, a client can be created. Please contact TLA Technical Support with a preferred ClientID, and the server’s root URL. Once the client has been registered, the appropriate XML code will be provided. This code will look similar to the code below:

<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
  <secure-deployment name="vanilla.war">
    <realm>demo</realm>
    <auth-server-url>http://localhost:8180/auth</auth-server-url>
    <public-client>true</public-client>
    <ssl-required>EXTERNAL</ssl-required>
    <resource>vanilla</resource>
  </secure-deployment>
</subsystem>

This code will need to be copied into the standalone/configuration/standalone.xml file.

This code will replace the single line <subsystem xmlns="urn:jboss:domain:keycloak:1.1"/>.

Make sure the secure-deployment name variable is set to the <client name>.war and not to WAR MODULE NAME.war. Then reboot the Wildfly server.

For alternative methods to leverage the Reference Implementation’s SSO service, please contact the TLA Technical Support. For more information, Keycloak also has an in depth Getting Started (opens new window) guide available.

# Protection of Personally Identifiable Information (PII) and Protected Personal Information

The ADL Initiative analyzed existing policies, commercial best practices, and their relationship to TLA data through the Privacy and Security for TLA (opens new window) project. This research informs the development of a privacy API that promotes privacy awareness and user control over an individual's privacy settings that get applied to all connected systems. The privacy API is not scheduled for development until CMM Level 3 conformance has been achieved.

All learner records in the sandbox are either 1) generated by the DATASIM xAPI data simulator (opens new window), or 2) anonymized to ensure there is no traceability between learner data and an individual. The use of anonymized learner data is often required for Human Subject Testing protocols submitted and approved through an Institutional Review Board (IRB). To learn more about recommended approaches for anonymizing learner data or using DATASIM, please contact the TLA Technical Support.

← TLA CMM Level 1 - Instrumenting Learning Activities with xAPI and Connecting to an LRS →