Services Access Roles

Each service can define its own roles that are not limited to “admin” or “user”. Specific services roles are stored in the OpenTera service in the TeraServiceRole database model.

Service can further refine those roles by optionally attaching them to a specific project or site.

Access roles association

Access roles can be attached to either of the following: user group, device or participant group. This architecture allows to adapt to various configurations, but adds more complexity to the use or implementation. The TeraServiceAccess database model in the OpenTera service defines those relationship.

Specific uses case includes associating an user group as “Admin” of a videoconferencing service, for example, allowing that user group to have additional access in that service.

OpenTera projects and sites roles

OpenTera main server (TeraServer) uses that mechanism to define access to projects and sites. On the creation of a new site or project, the server creates “admin” and “user” roles for the OpenTera service and the specific site or project.

Services and projects association

Each service can be associated to projects. This association is defined in the TeraServiceProject database model in the OpenTera service. This association allows to expose only some of the services in the system to a specific project, limiting the options for services linked to Session Types and allowing to use a single server instead for various projects that depends on different services.