Single Sign-On durch LDAP Anbindung
an den Basler Schulen
Eine Portallösung mit Zugriff auf UCS-LDAP
Markus Bäumler, Hansp...
Agenda
• PZ.BS ICT Medien – über uns
• Anforderungen Single Sign-On
• Projektplanung, Ausschreibung
• eduBS Infrastruktur ...
Erziehungsdepartement Basel-Stadt
• Fortbildung ICT
• Pädagogisches Konzept / Support
• Hardware / Software
• Technischer ...
ICT Medien – über uns
ca. 60 Standorte
ca. 27‘000 User
ca. 3’000 Clients
UCS LDAP – Identity Management
Windows AD-Connector (VDI)
Owncloud, Fileserver
eduBS-Mail mit Adressbüchern
Lernplattform ...
Anforderungen Portallösung
Jetzt Portal
login
login
login
login
Webmail
ILIAS
eduBS-Dektop
eduBS-Intern
login
Webmail
ILIA...
Projektplanung, Ausschreibung
• Einladungsverfahren auf Grund des geschätzten Volumens
(inkl. Support für 4 Jahre, 1000 co...
Unser Umfeld:
eduBS Infrastruktur und UCS-Architektur
• ca. 50 virtuelle –ix Server (Produktion und Testumgebung)
auf 8 XE...
Schulverwaltung
ESCADA2 UCS Master
UCS Backup 1
UCS Slave 1
Samba Homes
UCS Backup 2
Import aus Schulverwaltung
UCS Slave ...
Unser Umfeld:
eduBS Infrastruktur und UCS-Architektur
Neue Komponente: portal.edubs.ch
• Zugriff auf alle Services von ein...
Single Sign-on:
Motivation und Ausprägungen
Problemstellung:
Viele Dienste, die zwar alle mit denselben Zugangsdaten (aus ...
2-Faktoren Authentisierung (2FA)
Definition:
• Zweifaktor-Authentisierung wird definiert durch die Verwendung von zwei,
vo...
2-Faktoren Authentisierung (2FA)
Anforderungen:
Sorgfältige Abwägung des Schutzgrades. (Wo setze ich 2FA ein, wo nicht?)
B...
2-Faktoren Authentisierung (2FA) – Methoden:
SMS
Am einfachsten zu implementierende Lösung.
• Bedingt aber lückenlose Erfa...
2-Faktoren Authentisierung (2FA) – Methoden:
Yubikey
• Wollen wir genauer untersuchen, sieht interessant aus
• Preislich a...
• Standardisiertes Verfahren, publiziert durch OASIS.
OASIS is the Organization for the Advancement of Structured Informat...
Security Assertion Markup Language
Ablauf eines Verbindungsaufbaus
Quelle: Wikipedia,
Scavo
mutual trust!
Profile
Bindings
Protocols
Assertions
Security Assertion Markup Language
Elemente
Assertions: Aussagen über Benutzer
• Aut...
 Standardisierte Verfahren
 Für SSO keine per-Applikation-
Analyse erforderlich
 Sichere und anonyme Einbindung von
ext...
Work in progress!
• Abgeschlossen:
- Anbindung von ca 8 Applikationen mit forms oder IP-based SSO
- Anbindung von 2 Applik...
Live Demo
Vielen Dank für Ihre Aufmerksamkeit!
Kontakt
Markus Bäumler & Hanspeter Rutschmann
Erziehungsdepartement Basel-Stadt
PZ.BS...
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfang, Architektur
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfang, Architektur
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfang, Architektur
Nächste SlideShare
Wird geladen in …5
×

Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfang, Architektur

1.150 Aufrufe

Veröffentlicht am

Markus Bäumler, Co-Leiter Erziehungsdepartement des Kantons Basel-Stadt, berichtet in seinem Vortrag auf dem Univention Summit 2016 darüber, wie die Stadt Basel in der Schweiz zur Zeit eine Single Sign-On Lösung an den Schulen der Stadt implementiert und dabei auf UCS@school zurückgreift. Lehrpersonen und Schüler/innen sollen in Zukunft nach einmaligen Login die verschiedenen Services ohne weitere Anmeldungen nutzen können.

Veröffentlicht in: Bildung
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.150
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
866
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • 1. Request the target resource at the SP (SAML 2.0 only)
    The principal (via an HTTP user agent) requests a target resource at the service provider:
    https://sp.example.com/myresource The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2–7.
    2. Redirect to the SSO Service at the IdP (SAML 2.0 only)
    The service provider determines the user's preferred identity provider (by unspecified means) and redirects the user agent to the SSO Service at the identity provider:
    https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request The value of the SAMLRequest parameter is the Base64 encoding of a deflated <samlp:AuthnRequest> element.
    3. Request the SSO Service at the IdP (SAML 2.0 only)
    The user agent issues a GET request to the SSO service at the identity provider where the value of the SAMLRequest parameter is taken from the URL query string at step 2. The SSO service processes the AuthnRequest and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).
    4. Respond with an XHTML form
    The SSO service validates the request and responds with a document containing an XHTML form:
    <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...> <input type="hidden" name="SAMLResponse" value="response" /> ... <input type="submit" value="Submit" /> </form>
    The value of the SAMLResponse parameter is the base64 encoding of a <samlp:Response> element.
    5. Request the Assertion Consumer Service at the SP
    The user agent issues a POST request to the assertion consumer service at the service provider. The value of the SAMLResponse parameter is taken from the XHTML form at step 4.
    6. Redirect to the target resource
    The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
    7. Request the target resource at the SP again
    The user agent requests the target resource at the service provider (again):
    https://sp.example.com/myresource 8. Respond with requested resource
    Since a security context exists, the service provider returns the resource to the user agent.
    Note: In SAML 1.1, the flow begins with a request to the identity provider's inter-site transfer service at step 3.
  • 1. Request the target resource at the SP (SAML 2.0 only)
    The principal (via an HTTP user agent) requests a target resource at the service provider:
    https://sp.example.com/myresource The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2–7.
    2. Redirect to the SSO Service at the IdP (SAML 2.0 only)
    The service provider determines the user's preferred identity provider (by unspecified means) and redirects the user agent to the SSO Service at the identity provider:
    https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request The value of the SAMLRequest parameter is the Base64 encoding of a deflated <samlp:AuthnRequest> element.
    3. Request the SSO Service at the IdP (SAML 2.0 only)
    The user agent issues a GET request to the SSO service at the identity provider where the value of the SAMLRequest parameter is taken from the URL query string at step 2. The SSO service processes the AuthnRequest and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).
    4. Respond with an XHTML form
    The SSO service validates the request and responds with a document containing an XHTML form:
    <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...> <input type="hidden" name="SAMLResponse" value="response" /> ... <input type="submit" value="Submit" /> </form>
    The value of the SAMLResponse parameter is the base64 encoding of a <samlp:Response> element.
    5. Request the Assertion Consumer Service at the SP
    The user agent issues a POST request to the assertion consumer service at the service provider. The value of the SAMLResponse parameter is taken from the XHTML form at step 4.
    6. Redirect to the target resource
    The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
    7. Request the target resource at the SP again
    The user agent requests the target resource at the service provider (again):
    https://sp.example.com/myresource 8. Respond with requested resource
    Since a security context exists, the service provider returns the resource to the user agent.
    Note: In SAML 1.1, the flow begins with a request to the identity provider's inter-site transfer service at step 3.
  • Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfang, Architektur

    1. 1. Single Sign-On durch LDAP Anbindung an den Basler Schulen Eine Portallösung mit Zugriff auf UCS-LDAP Markus Bäumler, Hanspeter Rutschmann Erziehungsdepartement Basel-Stadt markus.baeumler@edubs.ch
    2. 2. Agenda • PZ.BS ICT Medien – über uns • Anforderungen Single Sign-On • Projektplanung, Ausschreibung • eduBS Infrastruktur und UCS-Architektur • f5 BIG-IP: Integration • Zweifaktor-Authentisierung • SAML • Stand der Arbeiten • Live Demo
    3. 3. Erziehungsdepartement Basel-Stadt • Fortbildung ICT • Pädagogisches Konzept / Support • Hardware / Software • Technischer Support • Netzwerk • Zentrale Services ICT Medien - Über uns
    4. 4. ICT Medien – über uns ca. 60 Standorte ca. 27‘000 User ca. 3’000 Clients
    5. 5. UCS LDAP – Identity Management Windows AD-Connector (VDI) Owncloud, Fileserver eduBS-Mail mit Adressbüchern Lernplattform (Ilias) Schulwebsites mit Intranet (Plone) UCS@school, OTRS, Nagios WLAN UCS-LDAP: User Rechner Netze
    6. 6. Anforderungen Portallösung Jetzt Portal login login login login Webmail ILIAS eduBS-Dektop eduBS-Intern login Webmail ILIAS eduBS-Dektop eduBS-Intern SoLe UMC SMS
    7. 7. Projektplanung, Ausschreibung • Einladungsverfahren auf Grund des geschätzten Volumens (inkl. Support für 4 Jahre, 1000 concurrent user) • Redundanz • Das Portal nutzt das bestehende Benutzerverzeichnis (OpenLDAP Univention Corporate Server) für die Authentifizierung und für die Zuordnung der Benutzerprofile. • Zweifaktor-Authentisierung pro Applikation • Anonymisierung der Userdaten bei Weitergabe möglich • PoC als Voraussetzung für definitiven Zuschlag • Zuschlag: NTT Com Security mit Produkt f5 Big-IP
    8. 8. Unser Umfeld: eduBS Infrastruktur und UCS-Architektur • ca. 50 virtuelle –ix Server (Produktion und Testumgebung) auf 8 XENServer • ca. 30 virtuelle Windows-Server und 600 VDI VMs auf 15 Windows Server • ca. 120TB Storage (NFS, CIFS und iSCSI) • ca. 27’000 Benutzerkonten • ca. 9,3 Mio. Mails/Jahr
    9. 9. Schulverwaltung ESCADA2 UCS Master UCS Backup 1 UCS Slave 1 Samba Homes UCS Backup 2 Import aus Schulverwaltung UCS Slave 2 UCS@School UCS Slave 3 Datensicherung UCS Slave 4 Remote LDAP-Redundanz Plone Web Ilias Lernpattform Owncloud Beziehen Echtzeit- Daten aus LDAPHaben eine LDAP-Kopie Portal Mail eduBS Infrastruktur und UCS-Architektur
    10. 10. Unser Umfeld: eduBS Infrastruktur und UCS-Architektur Neue Komponente: portal.edubs.ch • Zugriff auf alle Services von einem zentralen Punkt aus • Single Sign-on • Wo nötig: Zweifaktoren-Authentisierung • Sitzt «neben der Firewall» zwischen DMZ und Server-Netz
    11. 11. Single Sign-on: Motivation und Ausprägungen Problemstellung: Viele Dienste, die zwar alle mit denselben Zugangsdaten (aus UCS-LDAP) authentisieren sind, aber die Credentials müssen überall neu eingegeben werden. Lösung: „Portal“, das nach einmaliger Anmeldung die Zugangsdaten weitergibt. Übermittlung kann auf mehrere Arten erfolgen: • IP-basierend: Wer übers Portal kommt, darf rein. Keine persönliche Anmeldung erforderlich. Beispiel: Internet-Bibliotheken, für die Campuslizenzen existieren. • „Web-Formular“-basierend: Login- und Passwortfelder werden automatisch ausgefüllt. Persönliche Anmeldung. Beispiel: Webmail, Owncloud • SAML-basierend: Interessant, weil offener Standard. Wird bei uns Schlüsseltechnologie und Standard
    12. 12. 2-Faktoren Authentisierung (2FA) Definition: • Zweifaktor-Authentisierung wird definiert durch die Verwendung von zwei, voneinander unabhängigen, Kenntnissen oder Besitztümern. • Vorteilhafterweise ist eines davon mit einer kurzen Lebensdauer (im einstelligen Minutenbereich) behaftet und/oder nicht mehrfach verwendbar. OTP (One-Time- Password) • Üblicherweise ist die Username / Passwort – Kombination die Grundlage und wird mit einem zweiten Faktor ergänzt. • Caveat: „Orthogonalität“ beachten: Per eMail zugestelltes OTP, das mit Username/Pw abgefragt werden kann, ist kein valabler zweiter Faktor!
    13. 13. 2-Faktoren Authentisierung (2FA) Anforderungen: Sorgfältige Abwägung des Schutzgrades. (Wo setze ich 2FA ein, wo nicht?) Bei eduBS: • Für Erfassung von Noten und Absenzen (Lehrpersonen) • Zum Zurücksetzen von Passwörtern ganzer Klassen (Schul-Admins) • Für diverse Admin-Konsolen unseres Teams „Sicherheit und Bequemlichkeit sind nicht deckungsgleiche Ziele!“
    14. 14. 2-Faktoren Authentisierung (2FA) – Methoden: SMS Am einfachsten zu implementierende Lösung. • Bedingt aber lückenlose Erfassung der Mobile# an vertrauenswürdiger Stelle • Wird bei uns Standard sein • OTP wird generiert und über truesenses.com versandt • Für „Handy-Resistente“ werden wir eine Alternative anbieten müssen Streichliste • Offensichtliche Lösung, Anwendung durch eBanking bekannt • Bei uns wegen wiederkehrendem Aufwand für Distribution nicht leistbar
    15. 15. 2-Faktoren Authentisierung (2FA) – Methoden: Yubikey • Wollen wir genauer untersuchen, sieht interessant aus • Preislich ab ca 30.- €; wesentlich günstiger als andere Dongles (mit mehr Funktionalitäten/Features). • Fungiert als USB-Tastatur, die auf Knopfdruck ein OTP verschickt • „Gegenstück“/Kontrollinstanz ist ein Server, der entweder im lokalen RZ oder als Cloud-Service implementiert wird. • Einmaliger Aufwand: Zuordnen, ausliefern, vergessen • NB: Yubikey ist auch über PrivacyIDEA direkt mit UCS kombinierbar
    16. 16. • Standardisiertes Verfahren, publiziert durch OASIS. OASIS is the Organization for the Advancement of Structured Information Standards, a not- for-profit, international consortium that drives the development, convergence and adoption of open standards for the global information society. Mitglieder sind u.a. IBM, Microsoft, Citrix, Netapp, CA, PaloAlto, Checkpoint, Huawei, SAP • (nicht nur) für SSO • Aktuell V2.0 Security Assertion Markup Language SAML
    17. 17. Security Assertion Markup Language Ablauf eines Verbindungsaufbaus Quelle: Wikipedia, Scavo mutual trust!
    18. 18. Profile Bindings Protocols Assertions Security Assertion Markup Language Elemente Assertions: Aussagen über Benutzer • Authentication Statements: Aussagen über Art und Zeit der Identifikation • Attribute Statements: Zusatzinformationen • Authorization Decision Statements: Aussagen über Berechtigungen zu Resourcen Protocols: Verfahren • Authentication Request • Single Logout • Assertion Query/Request • Artifact Resolution • Name Identifier Management • Name Identifier Mapping Bindings: Übergeordnetes Transportmittel (üblicherweise HTTP oder SOAP) Profile: Bündelung obiger Elemente zB für SSO Profile Quelle: jaxenter.de Krafzig / Yunus
    19. 19.  Standardisierte Verfahren  Für SSO keine per-Applikation- Analyse erforderlich  Sichere und anonyme Einbindung von extern gehosteter Lernsoftware möglich o Single-Sign-Off muss sorgfältig designed werden o Funktioniert nicht, wenn das Passwort weitergereicht werden muss SAML Vor- und Nachteile
    20. 20. Work in progress! • Abgeschlossen: - Anbindung von ca 8 Applikationen mit forms oder IP-based SSO - Anbindung von 2 Applikationen per SAML in finaler Planungsphase - StepUp-Authentication mit SMS - Separates Portal mit Yubikey erfolgreich getestet • Kurz vor «closed beta» mit 5-15 Lehrpersonen • ToDo: - Überprüfung der Architektur mit UCS 4.1 im Sommer 17: Anbindung als IdP sinnvoll? Vor-/Nachteile? - Implementation SAML SPs - Weitere Applikationen einbinden - Einfachen Zugriff auf Laufwerke ermöglichen (Drive Mapping) - SSO aus dem VDI-Desktop Stand der Arbeit
    21. 21. Live Demo
    22. 22. Vielen Dank für Ihre Aufmerksamkeit! Kontakt Markus Bäumler & Hanspeter Rutschmann Erziehungsdepartement Basel-Stadt PZ.BS ICT Medien markus.baeumler@edubs.ch hanspeter.rutschmann@edubs.ch www.edubs.ch/ict

    ×