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.
Enough about Gaia-X theory – Let’s shift towards real use cases! - Plusserver...
Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfang, Architektur
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. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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!
16. 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!“
17. 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
18. 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
19. • 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
20. Security Assertion Markup Language
Ablauf eines Verbindungsaufbaus
Quelle: Wikipedia,
Scavo
mutual trust!
21. 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
22. 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
23. 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
25. 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
Notes de l'éditeur
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.