Providing student access to EdPotential

Step 1

You first need to confirm students use the same Single Sign-On (SSO) system as school staff. This is essential to providing student access.

Step 2

If you do not have Teacher as a role in your EdPotential application in your Google Workspace or Microsoft Entra ID you will need to create this role. 

In Google Workspace: 

• Click the SAML attribute mapping section in the EdPotential app settings
• Under Group membership (optional), select the group(s) you would like to have access to EdPotential.
• Set the App attribute value to mlepRole
• Click Save.

In MicrosoftEntra ID:

In the Microsoft Entra admin centre, go to Enterprise applications and select the EdPotential SAML application

• Click on Edit at the right of Attributes & Claims
• Click on Add a group claim

• In the Group Claims section that opens on the right select Groups assigned to the application

• For the Source attribute select sAMAccountName
• Click Save

Now that you've added the claim, you need to assign the group/s to the application

• Go to Users and groups
• Select Add user/group

• Click on None selected and select the group/s to be added, typically Teachers (check senior leaders are in this group.)

We will then check that teachers can still log in by using the test account provided during onboarding. If this account is no longer active we will ask the Deputy Principal (DP) to log in.

Step 3: Add a Student role

Our next step is to differentiate between teachers and students in your SSO setup so that we can assign different permissions to the two groups.

Repeat Step 2, this time adding a role Student and a group of students. 

This group must only contain the students who are to have access. For example, if you are only wanting to provide access to Year 12 and Year 13 students, only these students (and a test student account, as explained in Step 5 below) should be in the Students group.

Step 4: Add Student ID as an attribute

You will need to add Student ID as an attribute. Here is how you can map that attribute so it’s sent as a claim to your application.

• Identify where the Student ID is stored. Before you can send it, you need to know which field it lives in. In a school environment, it is typically in one of these three places:
  • EmployeeID: The most common field used for student/staff numbers
  • ExtensionAttribute1-15: Common if the school syncs from an on-premises Active Directory
  • ExternalID: Common if they use School Data Sync (SDS).
• Add the Student ID Claim
  • Go to Single sign-on > Attributes & Claims > Edit
  • Click + Add new claim
  • Configure the claim:
    • Name: student_id (or whatever your app expects)
    • Namespace: (Leave this blank unless your app specifically requires a URI)
    • Source: Keep this as Attribute
    • Source attribute: Search for the field identified in the first step (e.g., user.employeeid or user.extensionattribute1).
  • Click Save.

Step 5: Add a test student account

As the next step of testing we need a test student account which has an account in KAMAR. This will enable us to check that a student only sees their own report when they log in.

One possibility is to share with us the account of a student who has left (with a new password), if that student still has an active account in KAMAR.

The test account will need to have the Student ID attribute set. 

Please provide the full email address of the test account, as sometimes students are on a different domain.

We will test that this login gives access to only this student's report on EdPotential.

Step 5: Final testing (to be completed by the DP)

While we have tested access with a test student account, it's advisable we have one further check. We suggest the DP runs through this process with one student while they oversee so they can confirm everything works as expected.

To do so they will need to direct a student to log in at their EdPotential sign-in page. The student should only see their own report.