SAML2 und OAuth in der Cloud - hias222.files.wordpress.comDownload SP Daten Download IDP Daten. Konfiguration SAML2 in der Cloud - Schritt 3a Anmelden 30 20.11.2017 SAML2 und OAuth

SAML2 und OAuth in der CloudUlf Lämmerhirt, Matthias Fuchs

20.11.2017 SAML2 und OAuth in der Cloud, Ulf Lämmerhirt / Matthias Fuchs1

V1 12.11.2017

Agenda

1. Übersicht SAML2 vs. OAuth 2

2. User Integration / Federation

3. SAML2 Konfigurationa. In-House Installation

b. Cloud

4. OAuth2 Konfigurationa. In-House Installation

b. Cloud

5. Zusammenfassung und Fazit

SAML2 und OAuth in der Cloud

Agenda

1. Übersicht SAML2 vs. OAuth2



b. Cloud


b. Cloud



Einleitung: SAML 2.0 /OAuth 2.0/(OpenID Connect)

Beide Verfahren ermöglichen SSO für Web-Anwendungen decken aber unterschiedliche Anforderungen ab.

- Security Assertation Markup Language

- Open Authorization

Beide Verfahren haben eine ähnliche Inrastruktur (aber unterschiedliche Namensgebungen)

SAML Historie

- 2002: SAML 1.0 wird OASIS Standard

- 2003: SAML 1.1

- 2005: SAML 2.0

OAuth Historie

- ca. 2008: OAuth 1.0 durch IETF Arbeitsgruppe

- 2012: OAuth 2.0

- ca. 2014 OpenID Connect (Erweiterung auf Basis von OAuth 2.0)


Unterschiede SAML 2.0 / OAuth 2.0

SAML 2.0

XML-Basiertes Austauschprotokoll

Nutzt HTTP POST Messages- Eher Ungeeignet für Mobile Apps- Gut für Browser-Basiertes SSO

Token enthält UserID und ggf. weitere Informationen- Kann auch zur Autorisierung verwendet werden

OAuth 2.0

Protokoll zur Autorisierung von Zugriffen auf Ressourcen

Nicht direkt für SSO geeignet da keine Credentials des Benutzers im Token- Sicherheitsgewinn- Erweiterung durch OpenID Connect für SSO

Kann Nachrichten auch über URL-Parameter versenden

- Für Mobile Apps geeignet Standardmäßig keine Signierung des Token

- Zusätzlicher Round-Trip notwendig


SAML 2.0 Rollen und Architektur

Identity Provider (IdP)- Hält die Benutzeridentitäten- Authentisiert Anwender

Service Provider (SP)- IdR. Anwendung o.ä.- Akzeptiert Token von IdP

IdP und SP vertrauen einander


Identity Provider

Service Provider

ClientUser

TrustRelationship

OAuth 2.0 Rollen und Architektur


Authorization Server

Resource Server

OAuth 2 ClientResource OwnerUser

Resource Owner vergibt Rechte an Resourcen (Anwendungen, APIs) auf dem Resource Server an Client

Authorization Server - Authorisiert Anwender- Stellt Token aus

Resourcen Server - Hält Resourcen des User (Resourcen

Owner)

- Anwendungen, APIs, Userdaten

- Authorization und Resourceserver vertrauen sich nicht

Session-based Authentication vs Token-based Authentication

Session-based

Session_id

Server merkt sich alles anhand der Session_ID

Stateful

Wird im Memory oder einer Datenbank gespeichert (coherence)

Die Skalierung hängt vom Server ab

Token

Token

Stateless

Geringerer Speicherverbrauch am Server

Skalierbarkeit

Total Flexibilität

Überprüfung nach dem Request des Clients zum Server




b. Cloud


b. Cloud



User Integration / Federation OAM

Unterstützung einer Vielzahl von LDAP-Verzeichnissen.- Bestehende Benutzerverzeichnisse können

direkt genutzt werden Kann als Federation-Serviceprovider zu einem

externen IdP-Partner auftreten Nutzung von Social-IdPs (OAuth)

Benutzerdaten bleiben lokal!


User Integration / Federation Cloud

Anbindung von ADs über eine Directory Bridge

Konfiguration von externen Identityprovidern (SAML) oder „Social IdPs“ (OAuth/OIDC)

z.Z. nur eingeschränkte Möglichkeiten

Nutzung bestehender Benutzerverzeichnisse nicht ohne Aufwand möglich!


Unterscheidung SAML und OAuth: Einsatzgebiete

SAML OAuth

Applications Architektur Applikations Server Mobile- und Browser Applikationen

Beispiele ADF, JSP, JSF, PHP, .. Angular, Mobile Apps, React, Jet

Webservices SOAP REST

Etablierung Ausgereift Neuer

Bevorzugte Einsatzgebiete

User Integration Hybrid Cloud – Server Application1. User Requests Protected Website (z. B.

ADF)

2. Authentifizierung erforderlich

3. Anmeldung über SAML Identity Provider

4. User Daten werden aus lokalem Active Directory geholt

5. Zugriff mit SAML Token

SAMLIdentity Provider

SAMLIdentity Provider

SAMLService Provider

SAMLService Provider

11

22

33 44

55

CloudOracle, AWS,...




User Integration Hybrid Cloud – Browser Application1. User fordern den Zugriff auf eine

Resource an (z.B. Angular auf REST)

2. Resource verlangt Authorisierung über Token

3. Applikation erfragt Token über OAuth

4. User wird über Unternehmensverzeichnis mit SAML verifiziert

5. Zugriff mit OAuthToken

6. Verifizierung Token am OAuth Server

OAuthOAuth

Protected ResourceProtected Resource

11

22

33 44

55

66




b. Cloud


b. Cloud



SAML2 Konfiguration Lokal 1/5 IdP Konfiguration


OAM – Identity Federation

Identityprovider anlegen

SAML2 Konfiguration Lokal 2a/5 IdP Konfiguration


Konfiguration durch XML-Datei

Name: beliebig aber eindeutig

Protokolle: SAML1.1, SAML2.0, OpenID2.0

NameID: UserID im Token

SAML2 Konfiguration Lokal 2b/5 IdP Konfiguration


Manuelle Konfiguration

Provider-ID: Kennung des SP Assertation Consumer-URL:

Adresse des Assertation Consumer Service

Angaben vom jeweiligen Service Provider

SAML2 Konfiguration Lokal 3/5 SP Konfiguration


Export der IdP-Metadaten

SAML2 Konfiguration Lokal 4/5 SP Konfiguration


Auszug aus den IdP Metadaten

SAML2 Konfiguration Lokal 5/5 Einlog Vorgang


Zugriff auf SP Einlog-Maske vom IdP- SAML-Token mit konfigurierten

Attributen wird erstellt

Identity Management Cloud


Konfiguration SAML2 in der Cloud - Schritt 1


Konfiguration SAML2 in der Cloud - Schritt 2a


Manuelle Konfiguration Entity-ID=Provider-ID- Kennung des SP

Konfiguration SAML2 in der Cloud - Schritt 2b


Manuelle Konfiguration

z.Z. Keine Konfiguration überXML-Upload möglich!

Konfiguration SAML2 in der Cloud - Schritt 2c Metadaten


Manuelle Konfiguration Metadaten werden auf SP Seite u.U. in

unterschiedlichen Formaten bereitgestellt

z..B. SimpleSAML PHP Download SP Daten Download IDP Daten

Konfiguration SAML2 in der Cloud - Schritt 3a Anmelden


Zugriff auf SP Einlog-Maske vom IdP- SAML-Token mit konfigurierten

Attributen wird erstellt

Konfiguration SAML2 in der Cloud - Schritt 3b Anmelden


Agenda




b. Cloud


b. Cloud



OAuth Workflow

https://tools.ietf.org/html/rfc6749

Abstract Workflow Übersicht zwei Komponenten

Resource Server Authorization Server

Ergebnis: Token

OAuth 2.0 Tokens and Extensions

Tokens

Bearer Token Usage—RFC 6750

Assertions

JSON Web Token—RFC 7519

JWTs represent a set of claims as a JSON object that is encoded in a JWS and/or JWE structure.

Standard Fields: Issuer (iss), Subject (sub), Audience (aud), Expiration time (exp), Not before (nbf), Issued at (iat) , JWT ID (jti)

OPEN ID Connect

obtain basic profile information about the end-user in an interoperable and REST-like manner

sub, iss, aud , Zweck- nonce:, auth_time, Additional Request Details acr, iat, exp

The Authorization Grants

Authorization Code Grant (Auth Code, Native Apps)

Implicit Grant (for Browsers)

Resource Owner Password Credentials Grant (Trusted)

Client Credentials Grant

Lokale Konfiguration - OAM

http://www.ateam-oracle.com/implementing-oauth-2-with-oracle-access-manager-oauth-services-part-i/

Vorraussetzung

OAM – Installation

Funktionsfähige Anmeldung

User sind integriert

Webgate Konfiguration für OAM

OAM über Webgate erreichbar R2

OAuth OAM

OAuth Konfiguration Beispiel Spring

20.11.2017 Fußzeile: Präsentationstitel, Autor, Ort39

Client:

Spring Boot APP

Properties Local OAuth

Konfiguration OAuth2 in der Cloud 1


Trusted Application


Konfiguration Cloud Client Types Resources and Scopes

https://en.wikipedia.org/wiki/REST

Mobile Application

Konfiguration Cloud Authorization Code Implicit Device Code

Configuration Resource Access

Cloud - Installation

Änderungen an Endpoints

Beispiel Konfiguration Spring App

Beispiel - Client Credentials Grant

Einfachste Weise Token zu holen

Nur für sehr vertraute Appliaktionen

Beispiel - Postman Examples


Agenda




b. Cloud


b. Cloud



Zusammenfassung / Fazit

SAML 2.0 - Etablierte Verfahren für Browser-basierte Anwendungen- ID-Token/Assertation in XML- Gut geeignet für browserbasierte Anwendungen- Ermöglicht Authentisierung und Autorisierung in einem Schritt

OAuth 2.0 (mit OpenID Connect) - Keine Informationen über Authentisierung daher nicht direkt für SSO geeignet

Benötigt Erweiterung durch OpenID Connect.- Etabliert in Sozialen Netzwerken- Gut geeignet für mobile Anwendungen- JSON Web Token (JWT) für Token/Assertation

Cloud Angebot ist übersichtlicher und „einfacher“

- Weniger Möglichkeiten z.B. Anbindung Benutzerverzeichnisse, Optionen

- Lücken in der Konfiguration (z.B. kein XML- Metadaten Upload)


Q&A


Documents

SAML2 und OAuth in der Cloud - hias222.files.wordpress.comDownload SP Daten Download IDP Daten. Konfiguration SAML2 in der Cloud - Schritt 3a Anmelden 30 20.11.2017 SAML2 und OAuth