Self-Service Portal

1. About

Self-Service Portal (SSP) serves three main purposes - providing information, enabling self-service and assisting users with support requests.

1.1 Information

Questions users often have are:

  • “What ressources can I request?”, or

  • “What ressources do I already have and where are they?”

Questions staff often have are:

  • “What ressources does a user have?”, and

  • “What permissions does a user have?”

Since all access and permissions to LNI Services are hierarchically structured based on LDAP groups, SSP can show a lot of (otherwise already public) information to both users and staff in a useful and integrated way.

1.2 Self-Service

Commodity ressources and services that do not necessarily need requirements engineering from staff should be created by users themself, at the time they need it and be immediately available to them.

Therefore, we have always worked on making all LNI Services available to users through self service. SSP continues this by handling both creating ressources and support requests in one central place.

1.3 Support Requests

Users understandably just want their problem to be fixed as fast as possible. Staff need the right information in order to do that.

As we often get support requests like “the server doesn’t work” which are not directly actionable due to lack of specificity, SSP assists users to select the involved ressource when creating servicedesk tickets.

2. Functionality

2.1 Current functionality

Depending on the role (see below), users currently can:

  • enable and update their SSH keys

  • create or request storage shares on Ceph

  • request Linux containers

  • enable or request access to other services

  • create servicedesk tickets

With the introduction of OpenStack, users can enable their access to OpenStack to create VMs.

2.2 Current limitations

Some LNI ressources or services do not yet follow our revised 2025-scheme for LDAP groups. With every lifecycle of a service or system, they will automatically show up in SSP (e.g. managed Linux containers).

3. Roles

3.1 Summary

Feature User (default) Admin (privileged) Guest (restricted)
See own page ✅ (no searchbar) ✅ (with searchbar) ✅ (no searchbar)
See other users' pages ✅ (with searchbar)
Update own SSH key
Support requests for own ressources 🎫 (creates ticket) 🎫 (creates ticket) 🎫 (creates ticket)
Request access to network (VPN, WLAN)1 🎫 (creates ticket) 🎫 (creates ticket) 🎫 (creates ticket)
Request access to applications (Nextcloud, SSP)1 🎫 (creates ticket) 🎫 (creates ticket) 🎫 (creates ticket)
Request access to existing storage ✉️ (send mail) ✉️ (send mail) ✉️ (send mail)
Request access to compute ressources 🎫 (creates ticket) 🎫 (creates ticket) 🎫 (creates ticket)
Request OpenStack limits 🎫 (creates ticket) 🎫 (creates ticket) 🎫 (creates ticket)
Create storage shares 🎫 (creates ticket)
Enable access to OpenStack 🎫 (creates ticket)
1 Staff and students have access to these ressources already by default, no need to request it.

3.2 Users

Requirements:

  • any BFH account of type staff, or

  • any BFH account of type student, or

  • any BFH account which is a member of IDM.perm.infrastructure.ssp.users.

3.3 Admin

Requirements:

  • any BFH account which is a member of IDM.ser-its.pers-vma, or

  • any BFH account which is a member of IDM.perm.infrastructure.ssp.admin.

We added all AKOs to IDM.perm.infrastructure.ssp.admin.

3.4 Guest

Requirements:

  • any BFH account of type ext which is not a member of IDM.perm.infrastructure.ssp.*, or

  • any BFH account of type guest which is not a member of IDM.perm.infrastructure.ssp.*.

4. Backlog

Features

  • Review all strings and complete German/French translations.