Difference between revisions of "Bitmask:Main Page"
(More service ideas) |
(Add picture) |
||
(4 intermediate revisions 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. | ||
− | |||
− | |||
− | |||
==== OAuth2 Service ==== | ==== OAuth2 Service ==== | ||
Line 43: | Line 41: | ||
=== Resource Mangement === | === Resource Mangement === | ||
Some Resources are required for many projects, and should be easy for users to claim. | 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 ==== | ==== VPN ==== | ||
− | + | Allows the user to | |
− | Might be extended to allow users to create their own isolated networks | + | * Create a VPN client. (already implemented) |
+ | Might be extended to allow users to | ||
+ | * create their own isolated networks | ||
+ | * invite people to them. | ||
==== Shell ==== | ==== Shell ==== | ||
− | Will allow users to create shell accounts on a shared server | + | Will allow users to |
+ | * create shell accounts on a shared server | ||
+ | * manage some static web space. | ||
==== Containers ==== | ==== Containers ==== | ||
Line 57: | Line 63: | ||
* View the logs | * View the logs | ||
* exec into them | * exec into them | ||
+ | |||
+ | ==== Subdomains ==== | ||
+ | Will allow users to | ||
+ | * Create new subdomains that can be used for their services | ||
==== Database ==== | ==== Database ==== | ||
− | Handled via shell scripts for now. Will allow users to create database access for own projects | + | Handled via shell scripts for now. Will allow users to |
+ | * create database access for own projects | ||
+ | * export them | ||
==== File Storage ==== | ==== File Storage ==== | ||
− | Will allow users to reserve file system space for own projects | + | Will allow users to |
+ | * reserve file system space for own projects | ||
+ | * Add backup plans for data inside | ||
==== Object Storage ==== | ==== Object Storage ==== | ||
− | Will allow users to create S3-Compatible storage on top of a created file storage claim | + | 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 ==== | ==== Mail ==== | ||
Line 71: | Line 92: | ||
* create outgoing SMTP service accounts for projects. | * create outgoing SMTP service accounts for projects. | ||
* optionally create new mailing lists | * 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 |
Latest revision as of 21:47, 24 July 2020
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
andlast_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
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