Beiträge

Partielle Absperrung im Abholbereich außer Haus – Haus Potsdamer Straße

Es war nicht der Regen! Bei Arbeiten an den sanitären Anlagen im 1. OG kam es zu einem Wasserschaden, der Teile des Abholbereichs (außer-Haus-Ausleihe) in der Potsdamer Straße betroffen hat. Seitdem sind diese Bereiche für die Benutzung gesperrt.

Bis zur Behebung der Störung werden vorübergehend die Bestellungen und Vormerkungen der Ausweis-Endnummern 80 und 83 links neben den Regalen auf Holzwagen an der Wand bereitgestellt.

An der Behebung des Problems wird gearbeitet. Bis zum Abschluss der Arbeiten bitten wir um Ihr Verständnis für entstehende Umstände.

UPDATE: Keine Sicherheitsbedenken – Sperrungen aufgehoben

Die Arbeiten an der betroffenen Kalotte und die Überprüfung der anderen Kalotten sind abgeschlossen. Es bestehen keinerlei Sicherheitsbedenken. Turnusgemäß werden derzeit die zusätzlichen Seilsicherungen aller Kalotten ausgewechselt. Da diese Arbeiten ausschließlich nachts durchgeführt werden, können wir Ihnen ab sofort wieder einen uneingeschränkten, sicheren Benutzungsbetrieb gewährleisten.


UPDATE 21.6.: Teil der HB 10 weiterhin gesperrt im Haus Potsdamer Straße
Hier nun der Stand nach der heutigen Begehung:
Am kommenden Montag (26.6.) wird die betroffene Kalotte gesichert und alle im Umkreis geprüft. Dies hat zur Folge, dass die Sperrung bis Montag bestehen bleibt und am Montag ausgeweitet wird bis hin zum Standort HB 10 Qb 388.
An den folgenden Tagen werden auch die übrigen Kalotten geprüft und ggf. gesichert, d. h. es werden weitere Sperrungen nötig. Wir hoffen sehr, dass die Aktion bis zum Ende der kommenden Woche abgeschlossen werden kann. Bitte haben Sie weiterhin Verständnis dafür, dass wir im Interesse der Sicherheit zeitweise Bereiche sperren müssen.


STAND 16.6.:
O.k., wir haben es unterschätzt. Trotz jahrelanger Bauerfahrung sind wir auf die Aussage ‘Das dauert nicht lange’ hereingefallen. Deshalb jetzt erst heute hier der Hinweis, dass ein Teil der HB 10 zurzeit nicht zugänglich ist. Genau ist das der Bereich HB 10 Er 1420 – HB 10 Ev 1500 (deutsches Verkehrsrecht, Finanzrecht, Steuerrecht, Arbeitsrecht und Sozialrecht). Im 2. OG sind einige Arbeitsplätze vor der HB 6 gesperrt, dort besteht aber keine Zugangsbeschränkung zu Beständen.
Der Grund für die Sperrungen ist, dass bei einer der großen Lichtkalotten eine der Halterungen beschädigt ist. Bestimmt haben Sie Verständnis dafür, dass aus Sicherheitsgründen der direkt unter der Kalotte liegende Bereich so lange gesperrt bleiben muss, bis die Reparatur erfolgt ist. Wir haben jetzt die Zusicherung, dass die Reparatur am kommenden Mittwoch erfolgen soll. Bei dieser Gelegenheit sollen auch die Halterungen der übrigen Kalotten überprüft werden. Eventuell muss dann mit weiteren Sperrungen gerechnet werden. Wir legen aber Wert auf diese Überprüfung, um Ihre Sicherheit zu gewährleisten.

UPDATE: Teil der HB 10 weiterhin gesperrt im Haus Potsdamer Straße

Hier nun der Stand nach der heutigen Begehung:

Am kommenden Montag (26.6.) wird die betroffene Kalotte gesichert und alle im Umkreis geprüft. Dies hat zur Folge, dass die Sperrung bis Montag bestehen bleibt und am Montag ausgeweitet wird bis hin zum Standort HB 10 Qb 388.

An den folgenden Tagen werden auch die übrigen Kalotten geprüft und ggf. gesichert, d. h. es werden weitere Sperrungen nötig. Wir hoffen sehr, dass die Aktion bis zum Ende der kommenden Woche abgeschlossen werden kann. Bitte haben Sie weiterhin Verständnis dafür, dass wir im Interesse der Sicherheit zeitweise Bereiche sperren müssen.

 


Stand 16.6.:

O.k., wir haben es unterschätzt. Trotz jahrelanger Bauerfahrung sind wir auf die Aussage ‘Das dauert nicht lange’ hereingefallen. Deshalb jetzt erst heute hier der Hinweis, dass ein Teil der HB 10 zurzeit nicht zugänglich ist. Genau ist das der Bereich HB 10 Er 1420 – HB 10 Ev 1500 (deutsches Verkehrsrecht, Finanzrecht, Steuerrecht, Arbeitsrecht und Sozialrecht). Im 2. OG sind einige Arbeitsplätze vor der HB 6 gesperrt, dort besteht aber keine Zugangsbeschränkung zu Beständen.

Der Grund für die Sperrungen ist, dass bei einer der großen Lichtkalotten eine der Halterungen beschädigt ist. Bestimmt haben Sie Verständnis dafür, dass aus Sicherheitsgründen der direkt unter der Kalotte liegende Bereich so lange gesperrt bleiben muss, bis die Reparatur erfolgt ist. Wir haben jetzt die Zusicherung, dass die Reparatur am kommenden Mittwoch erfolgen soll. Bei dieser Gelegenheit sollen auch die Halterungen der übrigen Kalotten überprüft werden. Eventuell muss dann mit weiteren Sperrungen gerechnet werden. Wir legen aber Wert auf diese Überprüfung, um Ihre Sicherheit zu gewährleisten.

Teil der HB 10 gesperrt im Lesesaal Potsdamer Straße

O.k., wir haben es unterschätzt. Trotz jahrelanger Bauerfahrung sind wir auf die Aussage ‘Das dauert nicht lange’ hereingefallen. Deshalb jetzt erst heute hier der Hinweis, dass ein Teil der HB 10 zurzeit nicht zugänglich ist. Genau ist das der Bereich HB 10 Er 1420 – HB 10 Ev 1500 (deutsches Verkehrsrecht, Finanzrecht, Steuerrecht, Arbeitsrecht und Sozialrecht). Im 2. OG sind einige Arbeitsplätze vor der HB 6 gesperrt, dort besteht aber keine Zugangsbeschränkung zu Beständen.

Der Grund für die Sperrungen ist, dass bei einer der großen Lichtkalotten eine der Halterungen beschädigt ist. Bestimmt haben Sie Verständnis dafür, dass aus Sicherheitsgründen der direkt unter der Kalotte liegende Bereich so lange gesperrt bleiben muss, bis die Reparatur erfolgt ist. Wir haben jetzt die Zusicherung, dass die Reparatur am kommenden Mittwoch erfolgen soll. Bei dieser Gelegenheit sollen auch die Halterungen der übrigen Kalotten überprüft werden. Eventuell muss dann mit weiteren Sperrungen gerechnet werden. Wir legen aber Wert auf diese Überprüfung, um Ihre Sicherheit zu gewährleisten.

Microservices, Sicherheit

Dieser Beitrag in unserer Blogserie zum Thema Microservices, behandelt das Thema Authentifizierung und Autorisierung basierend auf dem OAUTH2 – Verfahren. Es werden die Vorteile und Herausforderungen dieser Lösung erörtert.

Im Rahmen der Entwicklungsprojekte der Staatsbibliothek zu Berlin, ist eine technische Anforderung, die nahezu in jedem Projekt gefordert wird, die Anmeldung von Benutzern und die Verwaltung der entsprechenden Benutzerrechte und Rollen. Es ist dabei zu prüfen, ob diese Anforderung im Rahmen einer Organisationslösung oder als eine individuelle, projektspezifische Lösung umgesetzt wird. Eine mögliche Organisationslösung sollter meiner Meinung nach folgende wichtige Anforderung unterstützen:

  • Integrierbarkeit in eine Microservices Architektur.
  • Unterstützung mehrerer Authentifizierungsverfahren, wie zum Beispiel, LDAP, Shibboleth oder ein individuelles Verfahren.
  • Unterstützung von Single Sign On und Single Sign Out.
  • Unterstützung verschiedenster Anwendungen.
  • Individuelle Erweiterbarkeit.

Im Vorfeld zur Lösungsbeschreibung möchte ich einige Begriffe, welche häufig in diesem Kontext verwendet werden, erläutern.

Authentifizierung
Die Authentifizierung dient der Überprüfung der Benutzeridentität. In der Regel geschieht dies mit der Eingabe eines Benutzernamens und eines Passworts.

Autorisierung
Hierunter werden die Gewährung von Benutzerrechten und das Zulassen bzw. Verweigern der entsprechenden Aktion in der Anwendung verstanden.

Single Sign On / Single Sign Out
Mittels Single Sign On wird das einmalige Anmelden am System ermöglicht, um mehrere Anwendungen ohne wiederholte Anmeldung nutzen zu können. Analog existiert der Single-Sign-Out-Mechanismus zum Abmelden.

LDAP
Ein Verzeichnis Dienst zur Verwaltung von Benutzerinformationen.

Token
Ein codierter Text welcher Nutzer bzw. Zugriffsinformationen enthält. Enthält allerdings keine Passwortinformationen.

Begibt man sich in diesem Bereich auf die Suche nach möglichen aktuellen Verfahren und Lösungen, findet man folgende populäre Lösungsansätze, welche einige der oben genannten Anforderungen unterstützen:

OAUTH2
OAUTH2 ist eine reine Autorisierungslösung und der Nachfolger von OAUTH 1.0. Das OAUTH2 Protokoll ermöglicht Anwendungen, Zugriff auf Webservices mit begrenzten Benutzerinformationen zu erhalten. Es wird bereits durch Anbieter von Webservices, wie zum Beispiel Facebook, Google oder auch Twitter verwendet. Alle Informationen zum Verfahren können Sie unter folgendem Link nachlesen.

OPEN ID Connect
Open ID Connect ist eine einfache Identitätsverwaltungsschicht basierend auf OAUTH2. Es ermöglicht Client Anwendungen die Identität eines Nutzers zu verifizieren und Nutzerinformationen zu erhalten. Es basiert auf HTTP REST Kommunikation.

SAML2, Security Assertion Markup Language
SAML2 ist ein Standard zum Austausch von Authentifizierungs-, und Autorisierungsinformationen und Nachfolger vom SAML Standard. SAML 2.0 ist XML-basiert und benutzt Sicherheitstoken zum Austausch von Nutzerinformationen. SAML basiert auf dem Zusammenspiel von einem Principal, dem Benutzer, einem Serviceprovider, einem Webservice zum Zugriff auf eine geschützte Ressource und einem Identity-Provider zur Prüfung der Identität eines Benutzers. SAML2 ist damit eine sogenannte Enterprise – Lösung, welche im gesamten Unternehmen bzw. der Organisation eingesetzt werden muss.

Für alle diese Verfahren sind bereits vielfältige Softwarebibliotheken und Produkte entwickelt worden. Eine Auswahl an Produkten welche diese Verfahren unterstützen sind folgende:

Eine gute Wahl ist meiner Meinung nach das Spring Security Framework. Die wichtigsten Gründe dafür sind:

  • Die gute Integrationsmöglichkeit für die Nutzung REST basierten Microservices,
  • Die Möglichkeiten der individuellen Erweiterbarkeit,
  • Die Unterstützung aller gängigen Authentifizierungsverfahren und Standards
  • Eine aktive Community und Weiterentwicklung
  • Die gute Integration in die Spring-Technologie.

Wie genau kann nun aber eine Lösung aussehen?

Eine mögliche Lösung hierfür wäre eine Remote-Fassade im Bereich der Sicherheit aufzubauen. Diese kann mögliche Autorisierungsverfahren verstecken und in Richtung der Anwendungen auf ein Verfahren standardisiert werden. Alle Anwendungen sind auf Basis des OAUTH2 Verfahren integriert.Folgende Abbildung veranschaulicht die Komponenten und das Verfahren.

Authentifizierung, Remote Fassade

Authentifizierung, Remote Fassade

Möchte der Benutzer eine Anwendung verwenden, wird dieser bei fehlender Authentifizierungsinformation auf die Anmeldeseite (Login) des Identity-Managementservers weitergeleitet. Dort kann der Nutzer seine Benutzerkennung eingeben und wird nach erfolgreicher Anmeldung zur ursprünglichen Anwendung zurück geleitet. Dieses Verfahren basiert auf dem OAUTH2 Flow „Authorization Code Grant“. Es können hier allerdings auch andere Flows für eine Anwendung verwendet werden. Beim Umleiten der Nutzeranfrage vom Identity-Management zur Anwendung wird dieser Umleitung ein sogenannter Token mitgegeben. Hier sollte meiner Meinung nach ein JSON Web Token (JWT) verwendet werden. Dieser Token enthält alle nutzerspezifischen Informationen und die entsprechenden Rechte und Rollen für diesen Benutzer. Die Anwendungen können nun diesen JWT auswerten und die entsprechenden Aktionen innerhalb der Anwendung zulassen bzw. verweigern. Zusätzlich zu dem OAUTH2 Standardverfahren ist es jetzt aber möglich für jede Anwendung ein Auhentifizierungsverfahren festzulegen. So könnte festgelegt werden, dass Benutzer der Anwendung A sich gegen das LDAP authentifizieren und Benutzer der Anwendung B sich gegen einen SAML2 Identity Provider authentifizieren. Hier agiert das Identity Management als eine Remote-Fassade zur Kapselung möglicher Authentifizierungsverfahren. Mit Hilfe des JWT können alle benutzerspezifischen Informationen platziert und ohne einen erneuten Login durch die Anwendungen ausgewertet werden.

Welche Vorteile bietet eine solche Lösung?

Diese Lösung hat den Vorteil, dass beliebige Authentifizierungsverfahren einmalig integrieren und mehrfach nachgenutzt werden können. Zusätzlich wird in Richtung der Anwendungen auf ein Verfahren standardisiert, was für die Client-Anwendungen weniger Anpassungen bei Erweiterungen des Indentity-Managements bedeutet und letztendlich auch Betriebsaufwände verringern kann. Ein weiterer Vorteil ist, dass jegliche Anwendungen mit allen benötigten Benutzerinformationen versorgen können ohne jemals die Benutzerauthentifizierung im Netzwerk ausgetauscht zu haben. Mit Hilfe des JWT können so auch Microservices ohne Userinterface die Nutzerinformationen erhalten und auswerten.

Welche Herausforderungen bringt diese Lösung mit sich?

Eine Herausforderung ist natürlich die Integration komplexer Authentifizierungsverfahren wie zum Beispiel SAML2. Hierbei müssen die Anmeldeinformationen bei dem entsprechenden Identity Provider der jeweiligen Organisation eingegeben werden und nicht im Standard-Login des Identity-Managements.
Eine weitere Herausforderung ist die unterschiedliche Darstellung derselben Anmeldeseite für unterschiedliche Anwendungen. Mögliche Ansätze zur Lösung dieser Thematik könnten auf Frontend-Komposition basieren. Dies bedeutet, dass die Anmeldeseite in die jeweilige Anwendung integriert und somit dem Anwendungslayout angepasst wird.
Neben der Anmeldung muss ebenfalls eine Lösung für eine einheitliche Abmeldung in allen Anwendungen gefunden werden. Dazu gibt es sogenannte Push Verfahren mit welcher das Identity Management die Anwendungen über die Benutzerabmeldung informieren kann.

Fazit

Das Thema Authentifizierung / Autorisierung und damit das Thema Sicherheit spielt im Bereich der Microservices eine wichtige Rolle. Bei der Konzeption einer Microservice-Architektur sollte aus meiner Sicht dieses Thema im Vorfeld separat und dediziert geplant werden. Es ist ein zentraler Bestandteil der so genannten Macroarchitektur. Denn jeder Microservices hat zur Aufgabe die Geschäftslogik entsprechend der Nutzerrechte zu gestalten. Dafür kann es natürlich nicht für jeden Microservices eine individuelle Sicherheitslösung geben. Die hier vorgestellte Lösung, hat den Vorteil, dass die Verwendung eines JWT und des OAUTH2-Verfahrens sich sehr gut für die Verwendung innerhalb einer Microservices Architektur eignet. Der JWT kann in jeden HTTP Request als Authorization Header mitgesendet werden, sodass ein HTTP REST basierter Microservice diesen auswerten kann. Es sollte allerdings darauf geachtet werden, dass die Anwendungslogik zur Auswertung des Tokens, sich nicht zu stark auf die Struktur des JWT festlegt. Wird diese nämlich im Laufe der Zeit grundlegend geändert müssen sämtliche Microservices angepasst werden. Mit der Auswahl des Frameworks Spring Security, dem OUATH2 Verfahren und dem JSON Web Token ist eine leichtgewichtige Integration sehr gut möglich.