add account changes (post)
Dieser Commit ist enthalten in:
Ursprung
a24a986227
Commit
845e154cc8
GPG-Schlüssel-ID:
A28671573AA347CC
|
|
@ -0,0 +1,107 @@
|
|||
---
|
||||
title: Bevorstehende Kontoveränderungen
|
||||
subtitle:
|
||||
date: 2023-06-19T19:00:00+02:00
|
||||
draft: false
|
||||
author:
|
||||
name: Nick Slowinski
|
||||
link:
|
||||
email: nick@nick-slowinski.de
|
||||
avatar:
|
||||
description: Noch im Laufe diesen Jahres werden bestehende Konten vom Git-Service zu einer neuen Single-Sign-On Platform migriert.
|
||||
keywords: SSO, Git, Konto
|
||||
license:
|
||||
comment: false
|
||||
weight: 0
|
||||
tags:
|
||||
- Konto
|
||||
- SSO
|
||||
- Git
|
||||
categories:
|
||||
hiddenFromHomePage: false
|
||||
hiddenFromSearch: false
|
||||
summary: Noch im Laufe diesen Jahres werden bestehende Konten vom Git-Service zu einer neuen Single-Sign-On Platform migriert.
|
||||
resources:
|
||||
- name:
|
||||
src:
|
||||
- name:
|
||||
src:
|
||||
toc: true
|
||||
math: false
|
||||
lightgallery: false
|
||||
password:
|
||||
message:
|
||||
repost:
|
||||
enable: false
|
||||
url:
|
||||
|
||||
# See details front matter: https://fixit.lruihao.cn/documentation/content-management/introduction/#front-matter
|
||||
---
|
||||
|
||||
_**TL;DR: Euer Benutzerkonto befindet sich später auf einer separaten Webseite von mir mit gleichem Datenschutz.**_
|
||||
|
||||
## Vorwort
|
||||
|
||||
Noch im Laufe dieses Jahres werden bestehende Konten vom Git-Service zu einer neuen Single-Sign-On Platform migriert.
|
||||
|
||||
Aktuell bietet mein [Git-Service](https://git.nick-slowinski.de) bereits in eingeschränkter Form diese Funktionalität, aber es gibt viele Kleinigkeiten, die deutlich besser sein könnten.
|
||||
|
||||
## Was Forgejo/Gitea bisher gut macht
|
||||
|
||||
* Unterstützung für Zwei-Faktoren-Authentisierung und Hardware Sicherheitsschlüssel
|
||||
* OAuth2[^2] / OpenID Connect[^2] Provider
|
||||
* so gut wie alles andere :smile:
|
||||
|
||||
## Was Forgejo/Gitea bisher nicht so gut macht
|
||||
|
||||
* Keine gute Möglichkeit eine erneute Zustimmung bei Änderungen der Nutzungsbestimmungen oder ähnlichen einzuholen.
|
||||
* Schlechte Spam- und Bot-Abwehr, trotz hCaptcha.
|
||||
* Nutzungsbestimmungen und Datenschutzerklärungen sind kein Standard - aktuell wird ein "hacky way" (Umweg) verwendet, um geltende Gesetze einzuhalten.
|
||||
|
||||
## Was sich ändert
|
||||
|
||||
Ende Q3 dieses Jahres plant Red Hat die neueste Version von *Red Hat Build of Keycloak* (fortlaufend als *RHBK* bezeichnet), bisher unter dem Namen *Red Hat Single-Sign-On* bekannt, zu veröffentlichen.[^1]
|
||||
Mit dem Erscheinen der ersten Vorabversionen werde ich erste Tests starten und RHBK in einer geschlossenen Testphase parallel zum bisherigen System einsetzen.
|
||||
|
||||
RHBK wird es mir ermöglichen weitere sehr interessante Software einzusetzen und in das bestehende System von Services zu integrieren. RHBK bietet mir nicht nur die Möglichkeit bestehende Services über OAuth2[^2] und OpenID Connect[^2] anzubinden, sondern auch über SAML 2.0[^2]. Keycloak und RHBK stellen zudem auch die Möglichkeit der Authentisierung über [Kerberos](https://de.wikipedia.org/wiki/Kerberos_(Protokoll)) und entsprechende Schnittstellen für [LDAP](https://de.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) und [Active Directory](https://de.wikipedia.org/wiki/Active_Directory)[^3]. Es besteht weiterhin die Chance mehrere sogenannte Realms (Benutzerumgebungen) zu erstellen, sodass ein RHBK-Server mehrere Sets an Anmeldedaten bevorraten kann, z.B. für andere Projekte oder als Identitätsprovider für Partner.
|
||||
|
||||
## Mögliche Fragen
|
||||
|
||||
### Wann genau findet der Wechsel statt?
|
||||
|
||||
Ein genaues Zeitfenster kann ich zum jetzigen Zeitpunkt nicht festlegen, da es bisher noch keine genauen Informationen zur Veröffentlichung von RHBK 22 gibt. In der Zwischenzeit bis zur Veröffentlichung werde ich mich bereits mit Keycloak vertraut machen, damit ich später nicht bei null anfange.
|
||||
|
||||
### Wo finde ich später das neue Anmeldeportal?
|
||||
|
||||
Dies ist bisher auch noch nicht zu 100 Prozent beschlossen. Mein aktueller Favorit ist `accounts.nick-slowinski.de`, welcher es mir mit Namen (in E-Mails, als Service, etc.) recht einfach macht.
|
||||
|
||||
### Was passiert mit bestehenden Konten bei Nicks Git-Service?
|
||||
|
||||
Eine genaue Auskunft kann ich zum jetzigen Zeitpunkt auch noch nicht geben, aber [bestehende Konten](https://git.nick-slowinski.de/explore/users) werden notfalls von mir händisch übertragen, sodass Ihr nur nochmal den Nutzungsbestimmungen zustimmen und ggf. euer Passwort neu setzen müsst. Nach der Umstellung wird es einen separaten Artikel geben, was genau getan werden muss, welcher auch hier verlinkt wird.
|
||||
|
||||
### Warum RHBK und nicht gleich [Keycloak](https://www.keycloak.org)?
|
||||
|
||||
Ich arbeite Vollzeit (40 Stunden) pro Woche und betreibe meine Webseiten und Services aus persönlichen Interesse nebenbei - meine Zeit für die Pflege der Server ist also begrenzt. Umso mehr muss ich mich darauf verlassen können, dass eingesetzte Software stabil läuft und sie keine Probleme verursacht.
|
||||
|
||||
Ich könnte zwar auch einfach jetzt schon Keycloak, den Upstream von RHBK, einsetzen und das gleiche Ziel erreichen und kommende Features eher erhalten, aber die Gefahr von unplanmäßigen Arbeiten ist mir zu hoch. In meinen Augen verhält sich Keycloak zu RHBK wie Fedora zu Red Hat Enterprise Linux - man kann mit Fedora durchaus kompetente Server betreiben und die neuesten Cutting-Edge Techniken einsetzen, doch Cutting-Edge bedeutet auch, dass hin und wieder mal was kaputtgeht und das ist schlecht, wenn genau der zentrale Anmeldeserver ausfällt. :sweat_smile:
|
||||
|
||||
### Wenn RHBK eine Enterprise Lösung ist, entstehen dann nicht auch Kosten?
|
||||
|
||||
Wahrscheinlich nicht, denn meine aktuelle Subskription (Red Hat Developer Subscription for Individuals) deckt alle benötigten Softwarelizenzen bereits ab und ich erwarte nicht, dass Red Hat eine extra SKU für RHBK einführen wird.
|
||||
|
||||
### Warum setzt du bis zur Veröffentlichung von RHBK nicht Red Hat Single Sign-On 7.6 ein?
|
||||
|
||||
Das Ende des 3. Quartal ist nun auch nicht mehr weit entfernt und ich möchte einfach doppelte Arbeit vermeiden, da doch ein großer Unterschied zwischen RHBK und RH-SSO besteht - RH-SSO wird daher nicht eingesetzt.
|
||||
|
||||
### Kann sich noch etwas ändern?
|
||||
|
||||
Natürlich, aber ich denke schon, dass die oben beschriebene grobe Richtung eingeschlagen wird.
|
||||
|
||||
|
||||
# Fußnoten
|
||||
[^1]: [Red Hat Customer Portal](https://access.redhat.com/articles/6644111): {{< center-quote >}}
|
||||
RH-SSO will be rebranded as the Red Hat Build of Keycloak (RHBK). The product version of RHBK will align with Keycloak community versioning. The first release of RHBK will be RHBK 22 which is currently planned for end of Q3 2023. RHBK will be based on Quarkus as the runtime platform used to build and run Keycloak. RHBK aims to provide a reduced startup time, lower memory footprint, container-first approach, better developer experience, zero-downtime upgrade, and a strong focus on usability and scalability.{{< /center-quote >}} (letzter Abruf: 2023-06-19 16:00 MESZ)
|
||||
|
||||
[^2]: OAuth2, OpenID Connect und SAML 2.0 sind Protokolle für die übergreifende Anmeldung auf Webseiten.
|
||||
|
||||
[^3]: LDAP und Active Directory werden für die Anmeldung an Computersystemen verwendet, damit können Benutzer und Ihre Rechte über mehrere Systeme hinweg synchronisiert werden.
|
||||
Laden…
In neuem Issue referenzieren