Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfang, Architektur
•Als PPTX, PDF herunterladen•
0 gefällt mir•3,189 views
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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (13)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfang, Architektur
Ähnlich wie Single Sign-On durch LDAP Anbindung an den Basler Schulen – Anforderung, Umfang, Architektur (20)
Mehr von Univention GmbH
Mehr von Univention GmbH (20)
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
- 6. Erziehungsdepartement Basel-Stadt • Fortbildung ICT • Pädagogisches Konzept / Support • Hardware / Software • Technischer Support • Netzwerk • Zentrale Services ICT Medien - Über uns
- 7. ICT Medien – über uns ca. 60 Standorte ca. 27‘000 User ca. 3’000 Clients
- 8. 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
- 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
- 24. Live Demo
- 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
Hinweis der Redaktion
- 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.