/ GURU UPDATES

Guru 2 - Access Control (Business)

One of the challenges we encountered in Guru was around access control and determining who has access to certain provided functionality. Typically, access would be determined primarily by the assignment of certain roles to provide granular levels of access.

For example, in order to access the functionality for review of examination papers, a user would need the following roles:

  1. School Administrator OR Exam Office Administrator OR Superuser OR System Administrator
  2. Examination Processing Role

Unless both of these “rules” are satisfied, then the user would be refused access.

In Guru 1, there was no feedback to the user to indicate WHY they were refused access. In addition, there were no tools available to User Managers to debug access control issues for users they had set up.

The Guru 2 Solution

In Guru 2, we are implementing a service known as Open Policy Agent (OPA). This is a standalone service that all of our newly developed services talk to in order to determine authorisation for accessing resources.

Standalone Policy Service

We won’t get into technical details here - that’s for a separate technical post! The policy service takes some “inputs” (e.g. it might take the logged-in user’s roles). It then applies some “rules” and will give an “output” back to the requesting service.

To give a real example:

  1. A user attempts to access the examination paper facility in the exam-service
  2. The exam-service passes the users details to the policy-service (OPA)
  3. The policy services checks the rules defined for that service and sends a response to the exam-service
  4. The exam-service returns a response to the user
  5. If the rule was successful, the requested resource is returned
  6. If the rule was unsuccessful, the requesting user receives an authorisation failure AND a reason for this failure

OK. But what does this look like?

Access control is shown in a number of places and in a number of different ways.

  1. By hiding certain functionality in the person’s interface
  2. By putting an interactive lock symbol beside certain functionality
  3. By restricting certain pages entirely (e.g. someone goes directly to a link they don’t have permission for)

Of course, we did all these things in Guru 1. Where Guru 2 provides added functionality lies in five areas:

  1. We provide feedback to users who fail to access resources
  2. We provide reports to both users and user managers about resources they have/don’t have access to
  3. We can change policies instantly without any downtime
  4. We can apply different policies for different institutions without affecting code
  5. Any system in the University could potentially use our policy service for access control or data filtering

For example, if a user attempts to directly access a restricted resource:

Example Forbidden Page

This person has no roles assigned, so clearly satisfies neither of the two required rules. Therefore, their access is blocked and they are given a reason for this that helps with debugging the reason why they don’t have access.

What about user managers?

This reporting becomes particularly useful for user managers, who have a responsibility for managing access control within the system. In Guru 1 this was challenging at times, as user managers may not have been 100% sure about which combinations of roles were required for particular services. This often led to an over-assignment of access which is not ideal as we want to keep access sufficient but not excessive.

Policy Access Report

In this scenario, we are looking at an access report for a user with a system administration role who has much wider access within the system. The green tick or red cross on the right hand side shows whether the person will have access to this particular resource. By clicking one of the accordion titles, the user manager can expand to retrieve further information regarding the overall result for the rule.

In this situation, we can see that Tom Smith meets the requirements for both rules for ‘exams.examportal’.

This provides a number of benefits around the day-to-day management of users and the understanding of how access is managed. It will also provide additional information when it comes to external audit review.

Looking forward to releasing in Guru v2.0!

dave

David Molloy

David is the Head of the Guru Development Unit at Dublin City University. He spends his days doing a little bit of everything.

Read More