Orchestrator/bahn/project-audit/data/confluence-export/pages/27525695-6.8 Verwaltungsunterstuetzende Services KDV und eBRS.md

6.8 Verwaltungsunterstützende Services (KDV & eBRS)

Confluence Page ID: 27525695 Version: 25 Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.8 Verwaltungsunterstützende Services (KDV & eBRS) Labels:

---

6.8.1 Externe Benutzerverwaltung (eBRS) eBRS steht als System für "externer Benutzer und Rollen Service" mit dem Funktionsumfang einer Benutzerverwaltung, die über ein PowerUser-Konzept von den EVU-Usern selbst bedient wird. Die manuelle und verfahrensspezifische Pflege von Benutzern im Active Directory ist mühsam. Das Verfahren eBRS erleichtert dies durch automatische Prozesse. Auch der administrative Aufwand für DB Netz Mitarbeiter wird dadurch erleichtert, dass die Pflege der eigenen Mitarbeiter an die EVUs und EIUs selbst ausgelagert wird. Pro EVU gibt es so genannte "PowerUser", die das Benutzermanagement für ihr eigenes EVU übernehmen. Neue Benutzer werden von ihren PowerUsern eingeladen, sich für eBRS bzw. myNet zu registrieren. Der PowerUser gibt hierfür lediglich eine E-Mailadresse ein. Der Benutzer erhält dann einen Registrierungslink und kann sich registrieren. Hier wird er aufgefordert, folgende Informationen auszufüllen:

• Pflichtfelder
• Anrede (Herr/Frau)
• Vorname
• Nachname
• Passwort
• Optionale Felder
• Titel (Prof. / Dr.)
• Straße und Hausnummer
• PLZ
• Ort
• Land
• Telefonnummer Weitere Felder (etwa Fax, Initialen) sind derzeit nicht in eBRS vorgesehen und werden zur Zeit daher nicht im AD gespeichert. Folgende Namenskonvention wird für Benutzernamen im DS-AD verwendet: DS[Erste Buchstabe des Vornamen].[Nachname][ggf. Nummer] Zum Beispiel würde Johann-Wolfgang Goethe folgenden Benutzernamen bekommen: j.goethe Zusätzlich sind folgende Regeln zu beachten:
• Die Sonderzeichen ä, ö, ü und ß werden in ae, ou, ue, ss konvertiert.
• Andere Sonderzeichen (wie è, à, …) werden bei der Eingabe blockiert.
• Nur folgende Zeichen sind bei der Eingabe des Vor- und Nachnamens auf der UI zulässig:
• a-z
• A-Z
• üÜöÖäÄ
• ß (groß und klein)
• Leerzeichen Bindestriche und Leerzeichen werden bei der Berechnung des Benutzernamens ignoriert (entfernt), sowohl bei Vor- als auch bei Nachnamen. Bei der Generierung der Benutzernamen werden nur Kleinbuchstaben verwendet.   Wenn ein Benutzerkonto mit dem gleichen Namen bereits besteht, dann wird hochgezählt. Das heißt zum Beispiel:
• Johann-Wolfgang Goethe bekommt den Benutzernamen j.goethe
• Johannes Goethe bekommt dann den Benutzernamen j.goethe1 Die maximale Anzahl von Buchstaben für Vornamenbuchstaben + . + Nachname beträgt 20 Zeichen. Denn aus Kompatibilitätsgründen erlaubt das AD maximal 20 Zeichen für den „SamAccountName“. Sollte der Nachname zu lange sein, wird dieser automatisch gekürzt, zum Beispiel: Johannes Mustermannbeispielname wird zu j.mustermannbeispiel Die Hochzählung funktioniert folgendermaßen: Der erste Benutzer bekommt seinen Benutzernamen mit maximal 20 Zeichen zugeteilt. Der nächste, der den gleichen Benutzernamen bekommen würde, bekommt diesen Namen mit einer 1 im Anschluss. Der nächste bekommt eine 2 usw. Es werden keine redundanten Nullen verwendet, das heißt 1,2,3,4,5,6,7,8,9,10,11, 12… und nicht 01,02,03,04,05,06,07,08,09,10,… Die Höchstmögliche Zahl beträgt 9999. Sollte der Benutzername mit Zahl länger als 20 Zeichen sein, wird der Nachname um die entsprechende Zeichenzahl gekürzt. Beispiele:
• j.mustermannbeispiel
• j.mustermannbeispie1
• j.mustermannbeispie#
• j.mustermannbeispi10
• j.mustermannbeispi##
• j.mustermannbeisp100
• j.mustermannbeisp###
• j.mustermannbeis1000
• j.mustermannbeis####
• j.mustermannbeis9999

Nachfolgendes Systemkontext-Diagramm beschreibt das eBRS-System aus architektonischer Sicht:

Die eBRS-Oberfläche (erreichbar über F5 und in der oberen Hälfte des Diagramms abgebildet) ist lediglich für die Pflege der Berechtigungen durch berechtigte Anwender (u.a. PowerUser) bestimmt. Die Anwendungen im Backend (z.B. Bestellsystem, Click&Ride) können direkt mit dem AD bzw. dem Service BBZ kommunizieren, um die Benutzerkonten bzw. die relevanten Rechte abzufragen. Die externen Benutzerkonten liegen in der Active Directory Domäne ds.db.de. Hier besteht ein einseitiger Trust zur BKU-Domäne (DS vertraut BKU, aber BKU vertraut DS nicht). Folgende Informationen sind für die Anbindung an das Active Directory wichtig:

• Host: ds.db.de
• Port: 389
• LDAP Root-Pfad: OU=MyNet,OU=Verfahren,DC=ds,DC=db,DC=de
• Darunter gibt es umgebungsspezifische OUs, worunter wiederum die Benutzer liegen. Die Struktur sieht folgendermaßen aus:
• MyNet (OU, siehe Root-Pfad oben)
• TU (OU)
• User (OU)
• Groups (OU)
• AU (OU)
• User (OU)
• Groups (OU)
• PU (OU)
• User (OU)
• Groups (OU)
• Zugriff: Da es sich um Active Directory handelt, braucht man für den lesenden Zugriff keine besonderen Rechte. Jeder Benutzer, der sich in dem AD authentifizieren kann, kann auch dort lesen.
• Sofern einem Benutzer eine bestimmte Rolle zugewiesen wird, wird er in der entsprechenden AD-Gruppe aufgenommen.
• Dabei ist die Zuordnung an Kundennummern nicht abgedeckt, da dies in der BBZ geregelt wird. Die AD-Gruppenzugehörigkeit kann aber insofern hilfreich sein, damit jeder, der überhaupt eine Rolle besitzt (z.B. Trassenbestellung), sich in einer Anwendung anmelden kann und die Startseite sieht. So ist die Erstanmeldung performanter und die Zuordnung zu Kundennummern kann später abgefragt werden.
• Folgende AD-Gruppen wurden definiert. Hier ist das "XX" entsprechend durch TU, AU oder PU zu ersetzen. Die Gruppen können in der o.g. OU-Struktur gefunden werden.
• gm-eBRS-XX-PowerUser
• gm-eBRS-XX-Trassenbestellung
• gm-eBRS-XX-Anlagenbestellung
• gm-eBRS-XX-BetriebDisposition
• gm-eBRS-XX-InfrastrukturBauplanung
• gm-eBRS-XX-Abrechnung
• gm-eBRS-XX-Vertrag
• gm-eBRS-XX-NebenleistungenKlein
• gm-eBRS-XX-NebenleistungenGross
• gm-eBRS-XX-Zusatzleistungen
• gm-eBRS-XX-Aufgabentraeger
• gm-eBRS-XX-AlleRollen (Parent-Gruppe: enthält alle o.g. Rollen)
• Zertifikate
• Für .NET Anwendungen sollten die Zertifikate automatisch gezogen werden. Für andere Anwendungen wurden folgende Kenntnisse aus dem Projekt Click&Ride (CnR) gesammelt:
• Die AD Server (Berlin/Frankfurt) haben PK-Zertifikate, welche mit einem der DB Root CA Zertifikaten (DB Root CA 1, ‎Sonntag, ‎21. ‎November ‎2027 17:21:47) signiert wurden.
• In der Regel werden DB Zertifikate mit einem der DB Trust Center Zertifikaten signiert.
• Das entsprechende DB Root CA Zertifikat war - zumindest in der aktuellen - SDE/SDC Installation (=Zertifikate in security/cacerts der Entwickler- JVM) nicht enthalten. In den Browsern etc. werden die z.B. aber schon verteilt.
• In CnR wurde nun ein eigener Truststore angelegt (hat aber vor Allem mit Spring/Docker/AWS zu tun) und das entsprechende DB Root CA Zertifikat dort zur Verifizierung der AD Zertifikate hinterlegt.
• Das DB Root CA bekommt man aus dem Browser oder per Open SSL
• Username und Passwort (Credentials, die gegen das AD verifiziert werden sollen) müssen nicht codiert werden; dies erfolgt mit SSL/TLS. Das jeweilige Kryptoverfahren handeln Client und Server immer vor Beginn der Übertragung aus.

Über den Service BBZ werden die Zuordnung von Benutzerdaten (Benutzername) zu Kundennummern und berechtigte Rolle (für Bestellsystem: "Trassenbestellung") bezogen. Dieser Service ist mittels SOAP anzusprechen.  Detaillierte technische Informationen können der technischen Komponentenspezifikation entnommen werden. Diese ist unter folgendem Link im SharePoint abgelegt. 

6.8.2 Kundendatenverwaltung (KDV)

Das Arbeitsdokument befindet sich im Share Point Link. | | KDV/ KuDav | SOAP, https | Kundendatenverwaltung. Enthält Informationen wie 'Sperrvermerk' auf Kundennummer-Ebene.