Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

Angular in der Praxis
Angular in der Praxis
Angular in der Praxis
Ebook80 pages36 minutes

Angular in der Praxis

Rating: 0 out of 5 stars

()

Read preview

About this ebook

Angular-Experte Manfred Steyer beschäftigt sich in diesem shortcut zusammen mit Hans-Peter Grahsl und Daniel Schwab mit drei verschiedenen Themen, die in der praktischen Entwicklung von Angular-Applikationen ihre Anwendung finden: Authentifizierzung, wiederverwendbare Pakete und Testen. Wie immer wird das Wissen gekonnt nah an der Praxis vermittelt, so dass jeder Entwickler die einzelnen Schritte nachvollziehen und selber anwenden kann.
LanguageDeutsch
Release dateMay 24, 2017
ISBN9783868027556
Angular in der Praxis

Read more from Manfred Steyer

Related to Angular in der Praxis

Titles in the series (100)

View More

Related ebooks

Internet & Web For You

View More

Related articles

Reviews for Angular in der Praxis

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    Angular in der Praxis - Manfred Steyer

    GmbH

    1 Authentifizierung und Autorisierung mit Angular 2.0

    Mit den Standards OAuth 2.0 und OpenID Connect lassen sich flexible Authentifizierungs- und Autorisierungslösungen auf der Basis von Security-Tokens entwickeln. Sie erlauben die Integration bestehender Identity-Lösungen wie Active Directory sowie die Nutzung zentraler Benutzerkonten für unterschiedliche Anwendungen.

    Die wenigsten Geschäftsanwendungen kommen ohne Authentifizierung aus. Häufig müssen bestehende Identity-Lösungen wie Active Directory oder LDAP-Systeme integriert werden, um Single Sign-on zu ermöglichen. In modernen Webanwendungen muss der Client auch das Recht erhalten, im Namen des angemeldeten Benutzers auf Services zuzugreifen. All diese Anforderungen lassen sich elegant mit Security-Tokens lösen. Dieses Kapitel zeigt anhand eines Beispiels, wie tokenbasierte Sicherheit in einer Angular-Anwendung genutzt werden kann. Dazu kommen neben einer Angular-Anwendung ein auf Spring Boot basierendes Web-API und die zertifizierte Identity-Lösung Keycloak [1] aus der Feder von Red Hat zum Einsatz. Der gesamte Quellcode findet sich unter [2] und [3].

    Wer sich heutzutage mit tokenbasierter Sicherheit beschäftigt, kommt wohl kaum an den beiden populären Standards OAuth 2.0 [4] und OpenID Connect [5] vorbei. Sie beschreiben unter anderem, wie sich ein Benutzer bei einem verteilten System anmelden kann und wie ein Client das Recht erhält, im Namen des Benutzers Services zu konsumieren. Dazu kommt, dass diese Standards direkt auf HTTPS aufsetzen und sich somit wunderbar für leichtgewichtige Web-APIs eignen. Abbildung 1.1 verdeutlicht die Funktionsweise von OAuth 2.0 aus der Vogelperspektive. Der Client leitet den Benutzer zur Anmeldung zu einem so genannten Authorization-Server weiter. Diese Instanz hat Zugriff auf zentrale Benutzerkonten. Hat sich der Benutzer dort angemeldet, erhält der Client ein so genanntes Access-Token, das ihm im Namen des Benutzers Zugriff auf Services im Backend gibt, so genannte Resource-Server.

    Abbildung 1.1: Funktionsweise von OAuth 2.0 aus der Vogelperspektive

    Ein Access-Token informiert den Resource-Server unter anderem über den entsprechenden Benutzer sowie über die Rechte, die der Client im Namen des Benutzers wahrnehmen darf. Zusätzlich finden sich im Token meist auch Metadaten, wie der Aussteller, das Ausstellungsdatum oder die Gültigkeitsdauer. Diese vom Prinzip her einfache Vorgehensweise hat mehrere Vorteile. Jeder Benutzer kann ein zentrales Benutzerkonto für verschiedene Clients und Services nutzen. Da die Anmeldung beim Authorization-Server erfolgt, erhält der Client das Passwort nicht. Die Authentifizierung ist vom Client entkoppelt und lässt sich somit in bestehende Identity-Lösungen integrieren. Tokens erhöhen außerdem die Flexibilität. Beispielsweise könnte ein Service das Token an einen weiteren Service weiterreichen, um zu beweisen, dass er im Namen des Benutzers agiert. Zum Zugriff auf andere Sicherheitsdomänen kann der Service das Token auch gegen eines für diese Domäne tauschen. Die Lösung kommt ohne Cookies aus. Somit kann der Client auch auf Services zugreifen, die auf anderen Servern laufen oder eine andere Origin haben. Zusätzlich schränkt der Verzicht auf Cookies bestimmte Angriffe ein.

    Das Format des Access-Tokens sowie die Maßnahmen, die der Resource-Server zum Validieren des Tokens unternimmt, sind von OAuth 2.0 nicht näher beschriebene Implementierungsdetails. Häufig kommen digitale Signaturen zum Einsatz, damit der Resource-Server einfach prüfen kann, ob das Token von einem vertrauenswürdigen Authorization-Server stammt. Alternativ dazu könnte das Token auch nur aus einer nicht vorhersehbaren ID bestehen, mit welcher der Resource-Server sich erneut an den Authorization-Server wendet.

    Benutzer mit OpenID Connect authentifizieren

    Als Ergänzung zu OAuth 2.0 definiert OpenID Connect (OIDC) unter anderem, wie der Client Informationen über den Benutzer bekommen kann. Diesen Aspekt deckt OAuth 2.0 nicht ab. Selbst das ausgestellte Token muss für den Client nicht lesbar sein. Dazu spezifiziert OIDC unter anderem ein so genanntes

    Enjoying the preview?
    Page 1 of 1