Difference between revisions of "Bitmask:Main Page"

From Zombi Wiki
Jump to navigation Jump to search
m (More service ideas)
(Add picture)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 +
[[File:Bitmask-login.png|thumb|right|The login view of the bitmask account manager]]
 
'''Bitmask''' is a Fork of the Zombi infrastructure. The reason for the fork was to provide a Platform where new aproaches can be tried out, without compromising the stability of the existing Zombi services. It is still tightly connected with the Zombi Platform, and thus shares some of the infrastructure.
 
'''Bitmask''' is a Fork of the Zombi infrastructure. The reason for the fork was to provide a Platform where new aproaches can be tried out, without compromising the stability of the existing Zombi services. It is still tightly connected with the Zombi Platform, and thus shares some of the infrastructure.
  
Line 15: Line 16:
 
* Only password-authentication is supported; Multi-Factor authentication can not be implemented, and neither can alternative login methods (such as key or certificate-based authentication).
 
* Only password-authentication is supported; Multi-Factor authentication can not be implemented, and neither can alternative login methods (such as key or certificate-based authentication).
 
* New attributes cannot easily be added to user accounts.
 
* New attributes cannot easily be added to user accounts.
 
==== Keycloak ====
 
Until all the required components are finished, A Keycloak server is be set up for authentication. After all the core features can be handled by the auth system, it will disappear again.
 
  
 
==== OAuth2 Service ====
 
==== OAuth2 Service ====

Latest revision as of 21:47, 24 July 2020

The login view of the bitmask account manager

Bitmask is a Fork of the Zombi infrastructure. The reason for the fork was to provide a Platform where new aproaches can be tried out, without compromising the stability of the existing Zombi services. It is still tightly connected with the Zombi Platform, and thus shares some of the infrastructure.

There are no guarantees regarding the stability of any of the provided services.

Roadmap

The current main goal is to Provide a well-integrated user management system, so that other projects can be implemented on top of it.

Authentication

Zombi has used an LDAP-based user management for the last 10 Years, and it has proven to be stable so far. However there are some shortcomings that became apparent:

  • Users need to have mandatory attributes, such as given_name and last_name, which are not really of great interest for us, and should be left out for data protection reasons in the future.
  • All services using LDAP need to handle user passwords; this becomes a problem when one of these services is compromised.
  • Only password-authentication is supported; Multi-Factor authentication can not be implemented, and neither can alternative login methods (such as key or certificate-based authentication).
  • New attributes cannot easily be added to user accounts.

OAuth2 Service

Already implemented. This component will deal with authorizing and authenticating the clients. It will have no GUI and will be configured via an API, in order to keep it simple.

Consent UI

This component displays Login and consent forms for the OAuth2 Service. It is also responsible for mapping scopes to attributes to the access_token and oidc_token.

Registration

Either handled via the consent UI itself or a dedicated service.

User self-service endpoint

Allows the user to:

  • Change password
  • Add new email addresses and verify them
  • Change primary email
  • Add TOTP
  • Add oauth2 clients for own projects
  • See and modify own profile (firstName, lastName, displayName, address, phone, xmpp, website…)
  • See own attributes (credit, quotas, permissions…)

Client registration

Handled via shell scripts for now, will be handled via the user self-service endpoint.

Resource Mangement

Some Resources are required for many projects, and should be easy for users to claim.

Git

Version control is important, and so every user should have access to a namespace where they can add public and private repos.

VPN

Allows the user to

  • Create a VPN client. (already implemented)

Might be extended to allow users to

  • create their own isolated networks
  • invite people to them.

Shell

Will allow users to

  • create shell accounts on a shared server
  • manage some static web space.

Containers

Will allow users to

  • run their own images on the shared infrastructure
  • Assign ressources
  • View the logs
  • exec into them

Subdomains

Will allow users to

  • Create new subdomains that can be used for their services

Database

Handled via shell scripts for now. Will allow users to

  • create database access for own projects
  • export them

File Storage

Will allow users to

  • reserve file system space for own projects
  • Add backup plans for data inside

Object Storage

Will allow users to

  • create S3-Compatible storage on top of a created file storage claim
  • access them via a web interface

Private Docker registry

Will allow users to

  • create namespaces to upload their images into
  • upload images

Mail

Will allow users to

  • create outgoing SMTP service accounts for projects.
  • optionally create new mailing lists

Project CI/CD

Using CI/CD to build projects should be supported, but here it is hard to implement permissions and access control.

VMs

Will allow users to:

  • create an isolated VM for their projects