Configuration of the authentification system - Opencast-Moodle/moodle-block_opencast GitHub Wiki

This section describes the steps you need to take in order to achieve the following goals:

  • Users are able to upload videos via the block.
  • Moodle automatically sets the correct ACLs.
  • Users can be authenticated via LTI to watch the videos of a respective course.

These steps make it necessary that different concepts of authentication and authorization are in place and configured correctly.

How does the authentication and authorization work

How is it possible that a user can upload videos via the block?

For this aspect the user is not authenticated directly within the opencast system. You need to configure an API user in opencast, which is then configured within the administration settings of tool_opencast. This API user, needs to have the ROLEs in Opencast to use multiple API endpoints. It does generally not need ROLE_ADMIN. However, if you want to use new features of block_opencast with an old opencast version, ROLE_ADMIN might still be required. Additionally, the API user needs to have a role, such as, ROLE_GROUP_MH_DEFAULT_ORG_EXTERNAL_APPLICATIONS. The same role has to be added in the block_opencast settings to the list of ACLs with read and write privileges to make sure that the API user has write privileges to all series created by the block_openast.

How can a user watch an uploaded video?

In order that a student or a teacher is able to watch a video the following authentication/authorization chain is used:

  1. The user is authenticated via LTI. This can either happen via an external activity tool (mod_lti) or as part of an embedding created by filter_opencast. In both ways the user is logged in at the opencast system as an LTI user. The user gets a temporary account, which matches the username in the moodle system. This user does not need to have a permanent account within opencast. So you don't have to create one for every student.
  2. You can check the state of the currently logged in user in the opencast system by querying the address: YOUOPENCAST/info/me.json. Keep in mind that you might have multiple opencast servers if you separated your system, for instance, into admin and presentation node. Initially, make sure that you configured LTI in the opencast system correctly (https://docs.opencast.org/r/8.x/admin/#modules/ltimodule/#configure-lti-optional) and that you provided the correct LTI credentials within moodle (either in filter_opencast or in the configuration of the external tool). On this page, you also see the set of roles the user currently has.
  3. The temporary LTI user is given a set of roles by the opencast system. However, in order to function properly in combination with the moodle system, you also need to configure the moodleUserProvider (https://docs.opencast.org/r/8.x/admin/#configuration/security.user.moodle/). This user provider will give the students roles such as 42_Learner, which represents that the student is enrolled in the moodle course with the ID 42 with the role of a student.
  4. The default configuration of the ACL settings of block_opencast ensures that each episode and series has ACL rules for the [COURSEID]_Learner and [COURSEID]_Instructor. In combination with the mentioned user provider the users of moodle get the correct roles so that they have read (and maybe write) privileges for the episodes and series.

How can a teacher upload videos using opencast studio?

For this interaction, you need to configure opencast studio correctly so that it generally works. To actually upload the captured video into opencast, the teacher needs write permissions for the respective series. This can be configured analogously to how students are able to view a video, only that the ACL configuration in block_opencast needs to add write permissions to [COURSEID]_Instructor.

After a video is uploaded with opencast studio, a set of basic ACLs is attached to the new episode. These can be configured in opencast studio using an acl.xml. How this can be achieved can be read in the opencast studio wiki. An exemplary ACL file could look like this:

acl.xml 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Policy PolicyId="mediapackage-1" Version="2.0" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides" xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
  <Rule RuleId="ROLE_ADMIN_read_Permit" Effect="Permit">
    <Target>
      <Actions>
        <Action>
          <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
            <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </ActionMatch>
        </Action>
      </Actions>
    </Target>
    <Condition>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">ROLE_ADMIN</AttributeValue>
        <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
      </Apply>
    </Condition>
  </Rule>
  <Rule RuleId="ROLE_ADMIN_write_Permit" Effect="Permit">
    <Target>
      <Actions>
        <Action>
          <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">write</AttributeValue>
            <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </ActionMatch>
        </Action>
      </Actions>
    </Target>
    <Condition>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">ROLE_ADMIN</AttributeValue>
        <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
      </Apply>
    </Condition>
  </Rule>
  <Rule RuleId="ROLE_GROUP_MH_DEFAULT_ORG_EXTERNAL_APPLICATIONS_read_Permit" Effect="Permit">
    <Target>
      <Actions>
        <Action>
          <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
            <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </ActionMatch>
        </Action>
      </Actions>
    </Target>
    <Condition>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">ROLE_GROUP_MH_DEFAULT_ORG_EXTERNAL_APPLICATIONS</AttributeValue>
        <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
      </Apply>
    </Condition>
  </Rule>
  <Rule RuleId="ROLE_GROUP_MH_DEFAULT_ORG_EXTERNAL_APPLICATIONS_write_Permit" Effect="Permit">
    <Target>
      <Actions>
        <Action>
          <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">write</AttributeValue>
            <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </ActionMatch>
        </Action>
      </Actions>
    </Target>
    <Condition>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">ROLE_GROUP_MH_DEFAULT_ORG_EXTERNAL_APPLICATIONS</AttributeValue>
        <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
      </Apply>
    </Condition>
  </Rule>
  <Rule RuleId="{{ userRole }}_read_Permit" Effect="Permit">
    <Target>
      <Actions>
        <Action>
          <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
            <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </ActionMatch>
        </Action>
      </Actions>
    </Target>
    <Condition>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">{{ userRole }}</AttributeValue>
        <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
      </Apply>
    </Condition>
  </Rule>
  <Rule RuleId="{{ userRole }}_write_Permit" Effect="Permit">
    <Target>
      <Actions>
        <Action>
          <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">write</AttributeValue>
            <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </ActionMatch>
        </Action>
      </Actions>
    </Target>
    <Condition>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">{{ userRole }}</AttributeValue>
        <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
      </Apply>
    </Condition>
  </Rule>
  <Rule RuleId="DenyRule" Effect="Deny"/>
</Policy>
\```

</p>
</details>  

Unfortunately, this does not add the full ACL set as configured for the block_opencast. Thus, the uploaded episode is invisible for students at first. Also other teachers do not have write privileges on the new episode. However, after setting the episode to visible within the block_opencast overview, the ACLs are as they should be.
⚠️ **GitHub.com Fallback** ⚠️