Beiträge

,

privacyIDEA 2.20 ermöglicht verteilte Authentifizierung

Heute wurde privacyIDEA 2.20 veröffentlicht. Pakete sind in den öffentlichen Launchpad-Repositories für Ubuntu 14.04LTS und 16.04LTS verfügbar. Über den Python Package Index kann privacyIDEA auf beliebigen Distributionen installiert werden.

Neue Funktionen in privacyIDEA

Federation-Handler

Der neue Federation-Handler erlaubt es, Authentifizierungsanfragen an untergeordnete privacyIDEA-Instanzen weiterzuleiten.

So lassen sich beliebige Berechtigungsstrukturen abbilden, in denen zum Beispiel die Authentifizierungs-Anfrage einer zentralen privcayIDEA-Instanz zu dedizierten, untergeordneten Instanzen in verschiedenen Abteilungen weitergeleitet werden.

Geschäftsbereiche, Subunternehmer oder Abteilungen können somit die Token der eigenen Mitarbeiter unter eigener Kontrolle verwalten. Dennoch gibt es einen zentralen Einstiegspunkt für Authentifizierungsanfragen.

Diese Funktion eröffnet auch im Providerumfeld neue Möglichkeiten.

Neuer Tokentyp OCRA und DisplayTAN

In Version 2.20 wurde der allgemeine Tokentyp OCRA und damit die spezielle Ausprägung DisplayTAN eingeführt. Die DisplayTAN-Karte ist eine Hardware-Karte, die über Bluetooth-LE OCRA-Challenge-Daten entgegennehmen kann. Der Benutzer kann dieser auf dem eingebauten eInk-Display verifizieren und erhält auf Basis dieser Challenge-Daten einen OTP-Wert angezeigt.

OCRA ist in RFC 6287 spezifiziert. Ein üblicher Anwendungsfall ist das Signieren von Bank-Transaktions-Daten und die Erzeugung der TAN. Mit dem DisplayTAN Token kann dies sicher auf einer dedizierten Hardware geschehen. privacyIDEA ist nun das ideale System, um diese Geräte für Bank-Anwendungen zu verwalten. In einem früheren Blog-Post berichteten wir bereits.

Login mit mehreren Loginnamen

Der LDAP Resolver gestattet es nun, mehrere LDAP Attribute zu definieren, die als Login-Name verwendet werden können. So kann der Administrator konfigurieren, dass sich Benutzer mit ihrem sAMAccountName, der Email-Adresse oder bspw. der Telefonnummer anmelden können.

Authentifizierungs-Cache

Weiterhin kann der Administrator nun definieren, ob in bestimmten Fällen für bestimmte Benutzer für eine gewissen Zeit die Authentifizierungsanfrage gecacht werden soll. Somit ist für einen gewissen Zeitraum die erneute Anmeldung mit dem gleichen OTP-Wert möglich. Zwar führt dies den Sinn von 2FA mittels OTP ad absurdum, wenige ungünstig implementierte Applikationen können jedoch davon profitieren. Ein kleiner Vorteil ist, dass sich dieses Verhalten über eine Zeit- und Client-IP-abhängige Richtlinie steuern lässt.

Weitere Funktionen

Viele Richtlinien erlauben nun auch die Nutzung von Resolvern. So lässt sich noch feiner granuliert das Verhalten für unterschiedliche Benutzergruppen anpassen.

Während des Rollout-Prozesses einer Smartphone-App kann der Benutzer, wenn er glaubt, dass ein Angreifer den angezeigten QR-Code abgegriffen hat, diesen neu generieren.

Die Ereignisse im Eventhandler-Framework können nun in einer selbst definierten Reihenfolge sortiert werden. Damit lassen sich die Reaktionen von privacyIDEA noch genauer festlegen.

Die Eventhandler können nun Zeiten und Zeitdifferenzen in den Bedingungen nutzen.

Mit einem Challenge Response-Token lässt sich ebenfalls die UI entsperren.

Während der Installation der Ubuntu-Pakete wird automatisch PGP-Schlüssel erzeugt, mit dem später die Import-Dateien der Token-Seeds verschlüsselt werden können.

Ein komplettes Changelog finden Sie bei Github.

Enterprise Edition und Beratung

Die NetKnights bieten Ihnen Beratung und Support im Rahmen der privacyIDEA Enterprise Edition. Damit haben Sie den Investitionsschutz von Open Source und die Betriebssicherheit durch einen professionellen SLA. Stabile Enterprise-Pakete runden das Angebot ab.

Sie wollen auf dem Laufenden bleiben? Dann abonnieren Sie unseren Newsletter!

Sie wollen mehr wissen? Rufen Sie uns an!

,

World Wide Web Consortium implementiert Zwei-Faktor-Authentifizierung mit privacyIDEA

Kassel, 26.09.2017. Das World Wide Web Consortium (W3C) führt privacyIDEA ein, um den Zugang zur eigenen Infrastruktur mit einem zweiten Faktor abzusichern. W3C hat sich auf Grund der Flexibilität und im Falle von Sigle Sign on wegen der einfachen Handhabung für Benutzer für privacyIDEA entschieden.

Die Dienste, die das W3C anbietet, und vor allem auch die Benutzer sind weltweit verteilt. Authentisierungsgeräte an die Benutzer zu verteilen ist nicht praktikabel. Ebenso ist es nicht sinnvoll, nur einen Typ von Authentisierungsgeräten zuzulassen. Für das W3C ist es ein großer Vorteil, dass privacyIDEA viele verschiedene Typen solcher Authentisierungsgeräte auch unterschiedlicher Hersteller verwalten kann. Dies können Smartphones mit Apps oder SMS, klassische Hardware-OTP-Token, Nitrokeys, YubiKeys, U2F-Geräte, TiQR-Token uvm. sein.
Die schlanke REST API von privacyIDEA macht es dem W3C einfach, Funktionen auch in das bereits bestehende Benutzerportal zu integrieren. privacyIDEA wird mit der bereits bestehenden Benutzerverwaltung verbunden. Die Benutzer werden auswählen können, ob sie sich selber eine Smartphone-App (wie den Google Authenticator) oder ein U2F-Gerät registrieren möchten. Abhängig von dem Typ, kann dem Benutzer dann Zugriff auf Resourcen unterschiedlicher Sicherheitstufen gewährt werden.

„Die Arbeit mit NetKnights ist sehr effektiv. Von Ihnen beziehen wir genau die richtige Beratungsleistung, um die Open Source Software privacyIDEA in unser Netzwerk und unsere Abläufe zu integrieren“ sagte Ted Guild, Head of W3C Systems. Cornelius Kölbel, Geschäftsführer der NetKnights, fügte hinzu: „W3C steht für Web-Standards. Daher freut es uns sehr, dass sich das W3C für privacyIDEA entschieden hat. Für eine offene Lösung, die offenen Entwicklungsstrategien folgt und offene Standards beherzigt und implementiert.“

Über das World Wide Web Consortium (W3C)

Das World Wide Web Consortium (W3C) ist ein internationales Konsortium, in dem Mitgliedsorganisationen, ein fest angestelltes Team und die Öffentlichkeit gemeinsam daran arbeiten, Standards für das World Wide Web zu entwickeln. Das Ziel des W3C ist es, das Potential des Web vollständig zu entfalten, indem technische Standards und Richtlinien definiert werden, so dass das Web offen, interoperabel und für alle auf der Welt nutzbar bleibt. Die W3C Standards HTML5 und CSS sind grundlegende Technologien auf denen moderne Webseiten aufbauen. Für seine Arbeit, Videos mit Titeln und Untertiteln im Web leichter nutzbar zu machen, erhielt das W3C 2016 den Emmy Award.

Die Vision „eines Webs“ bringt viele tauschend Menschen aus mehr als 400 Mitgliedsorganisationen zusammen. Die Mitglieder repräsentieren viele verschiedene Branchen. Organisatorisch wird das W3C gemeinschaftlich vom MIT Computer Science and Artificial Intelligence Laboratory (MIT CSAIL) in den U.S.A., dem European Research Consortium for Informatics and Mathematics (ERCIM) mit Hauptsitz in Frankreich, der Keio Universität in Japan und der Beihang Universität in China betrieben.

Mehr Informationen finden Sie unter www.w3.org.

Über NetKnights und privacyIDEA

Die NetKnights GmbH, Kassel, ist ein unabhängiges IT-Security-Unternehmen, das Dienstleistungen und Produkte aus den Bereichen starke Authentisierung, Identitätsmanagement sowie Verschlüsselung anbietet.

Die NetKnights GmbH stellt das Core-Entwickler-Team für die modulare Authentifizierungslösung privacyIDEA, die sich auf einfache Weise in bestehende IT-Infrastrukturen integrieren lässt. privacyIDEA hat als Open-Source-Software kein herstellerbestimmtes End-of-Life und lässt sich damit auf unbegrenzte Zeit nutzen. Für den kritischen Einsatz von privacyIDEA in Unternehmen bietet die NetKnights GmbH eine Enterprise Edition mit verschiedenen Subskriptions- und Support-Stufen an.

Die NetKnights GmbH präsentiert privacyIDEA vom 10.-12. Oktober 2017 auf der it-sa in Nürnberg, Stand 10.1-208.

2FA.jetzt will für starke Authentisierung sensibilisieren

Gestern Abend ging die Webseite 2FA.jetzt online. Dahinter steckt die Initiative „Starke Authentisierung – Jetzt“ bei der sich viele Experten unterschiedlicher Branchen zusammenfinden. Da sind Bankenverbände, IT-Verbände, IT-Sicherheitsunternehmen, eine Universität.

NetKnights engagiert sich

Kerngeschäft der NetKnights GmbH sind Dienstleistungen und Produkte rund um das Thema Zwei-Faktor-Authentifizierung. Mit der Opensource Produkt privacyIDEA bieten wir eine flexible und skalierbare Lösung für Behörden, Unternehme und Organisationen jeglicher Größe. Deswegen war es uns auch ein Anliegen, uns in der Initiative 2FA.jetzt zu engagieren.

Auch die NetKnights GmbH ist dort aktiv. Ziel der Initiative ist es die Endbenutzer von Online-Dienste zu sensibilisieren, dass ein sicheres Anmeldeverfahren auch die persönlichen Daten sichert, die der Benutzer einem Online-Dienst anvertraut. Den Diensteanbietern soll gleichzeitig eine Übersicht gegeben werden, wie und mit welchen Lösungen sie eine nachhaltige Zwei-Faktor-Authentifizierung für ihre Kunden umsetzen können.

2FA etabliert sich

Inzwischen haben die meisten wahrscheinlich von Zwei-Faktor-Authentifzierung gehört und habe eine grobe Vorstellung davon. Es ist Zeit, dass aus dieser groben Vorstellung fundiertes Wissen, Überzeugung und echte Anwendungen entstehen.

Mehr zu 2FA.jetzt in der aktuellen Pressemitteilung.

About Enterprise File Encryption

This article was first published at owncloud.

Your Data is at risk. And thus is your personal life and your company’s values.
You avoid hackers, trade espionage and rogue governments getting your data by using your own cloud storage like ownCloud. Your data under your control.

But depending on where your storage is located some risks still remain. The connection to your ownCloud installation in the hosted datacenter is TLS protected. All data are encrypted on their transport to the datacenter. But within the datacenter your data is plain text.
You are using ownClouds integrated encryption? You even have the full disk encrypted using LUKS or similar methods? This is fine but only protects you from certain attacks like stealing the sole hard disk.
But if the attacker gains access to the very location where the actual encryption takes place, the encryption is useless, since this location also contains the encryption key! Thus, if the attacker has access to the datacenter or – more probably – is a rogue or bribed employee of the datacenter the attacker can get physical access to your encryption key and finally to your data.

This is why client side encrpytion is such a good idea. With client side encryption the data is encrypted on your own client. The key material is only available on your client, not on the ownCloud server. The data is sent already encrypted to the server. Not only is the transport layer encrypted using TLS but the payload itself within the TLS can not be read anymore.
The ownCloud server and the storage never sees any clear text data and never has access to the encryption key.
The tool cryptomator which was introduced in this[link] previous blog post works this way.

Requirements

But enterprise scenarios come with a longer requirements list than tools like the slick cryptomater can cover.
Even smaller companies have to comply with the requirements of the enteprrises if they are supplier for the bigger ones.
I have run several projects where supplying companies were confronted with the requirements for encrpytion and two factor authentication since they delivered to bigger enterprises, that simple defined those requirements. Let us take a look at the requirements when you run a company or bigger organization.

File Encryption

In such scenarios when encrypting data it is important to encrypt files. In contrast to full disk encryption and encrypted containers encrypted files can be moved around without breaking the encryption. Even the encrypting file system does not provide this sticky encryption. If the user moves the file to another disk or a USB stick, the file would not be encrypted anymore, since with full disc encryption and container encryption the encryption is bound to the storage and not to the data.
The data should not be decrypted when the file is moved. This is why we require to encrypt the files and keep them encrypted when moving the file to another locatoin.

Client Side Encryption

As mentioned in the beginning the files should be encrypted and decrypted on the client. This way only encrypted data is transferred via the network. The user can also move the files as in the previous requirement but most important the encryption gets independent from the storage location.
The administrator can access the file but can not read the data in the file. This way all backup mechanisms still work, but the data is persistently protected.

Groups

When working with data in a company users are usually working on projects with other colleages.
Thus several users need access to the encrypted data. The project leader or data owner might need to add other users to the group and grant them access to the encrypted data or withdraw this access again.

It is important to note, that usually not *the* administrator gives access to the data. Complying to the concept of duty of separation, the administrator may be responsible for providing the storage and taking care of the backup, but he might not be allowed, to read the data and probalby will not be allowed to decide who is allowed to read the data.

This leads us to the requirement for a bit more sophisticated key management.

Key Management

If files are encrypted with passwords then a password based key derivation function (PBKDF) is used to generate the encryption key. A badly implemented encryption would use this key to encrypt the file. This would result in the problem, that – if you change the password – the complete file needs to be decrypted with the old password and re-encrypted with the new password. This might be fine for one small file but totally fails with a complete directory, a harddisk or a huge storage.

When you look at encryption a multi-step encryption has proven to be sensible. Even in the case of a PGP encrypted Email, the email is for many reasons not encrypted with the public key of the recipient directly but with a symmetric data encryption key (DEK), which is unique to this email.
Only this DEK is encrypted with the public key of the recipient. This is called Key Encryption Key (KEK).

The other great thing when using a DEK and KEK is, that several users can have access to the same data with different passwords – or different KEKs. This way a user who has access to the data can also be allowed to grant access on the data to a new user. The software can access the DEK with the KEK of the old user and encrypt the DEK of the file with the KEK of the new user.

This way, each file has a list of KEK-encrypted DEKs attached to it. Thus an enterprise encryption software needs to allow adding users with their key encryption key to files.
Users need to have different roles like adding users to access groups or only being allowed to access the data.

(Of course you can not effectively avoid the user breach: The user who has been granted access to the data can go rogue and print the data, take a photograph or copy. If you want to tackle with this threat you need to think about implementing data leakage prevenion.)

So what the heck with the KEK?

You might use the latest and greatest symmetric unbreakable encryption algorithms for actually encrypting the data. But these are of no use, if the access to this encryption – usually the password – is week. An attacker would always target the KEK (a.k.a. Passwords) and not the DEK (The encryption itself).

Thus, another important requirement is not only to encrypt the data but also to protect the access to this encryption. A good way to do this is not to use a password based access but to use public key cryptography.
As mentioned with the PGP example, the KEK is the public key of the user. The DEK is encrypted with the public key.
The user has to provide his private key to decrypt the DEK to access the data.

Perfectly the private key is located on a smartcard, so that the private key can not (easily) be copied or stolen.
If the private key was initially created on the smartcard, you can in addition be sure that the private key was not stolen or copied.

Data Read Escalation

As we required earlier the administrator usually can not read the data and can not add users to the group of data users, who can read the encrypted data.
But in certain cases – when all users have lost their smartcard, forgotten their passwords, have quit the job – the company needs to be able to access the encrypted data without one of the originial users available.

In this case the encryption solution needs to provide a process with preferably 4 eyes principle to regain access.
4 eyes principle is important to increase the trust and allow full deniability for all participants.

Technicaly the key management can to this by adding a system-KEK or recovery-KEK to all files.

Hardware Security Modules

Besides using smartcards for the user’s KEKs, the support for hardware security modules can be a good idea. The HSM can be used to protect the system-KEK or recovery-KEK or to sign configuration data. Otherwise a user with the right to only read encrypted data could escalate his rights to „assign-new-users to the encryption group“ by flipping some bytes in the database.

Reencryption

We already said, that reencrypting the data is a bad idea and should be avoided. Nevertheless it can be necessary. E.g. if the symmetric encryption algorithm used to encrypt the files is know to have weeknesses. This is especially important if you need to upgrade the encrpytion algorithm.
In a worst case scenario the system- or backup-key could be compromized, then this keys need to be changed.
The solution should provide the possibility to reencrypt the data.

Possible Solutions

There is a quite nice long list of commercial products, which cover those requirements. Some are better and more convenient in smartcard support, some in group management and some in automation.
It is always a good idea, to identify your own needs and evaluate the right solution.
Most of the tools are products of companies located in Germany and thus comply to the (still) stirct data protection laws.

Why is there no open source?

Nevertheless there is no open source tool, which is capable of covering the requirements and competing with the commercial tools available. This might be due to the scratch-your-own-itch concept of open source development. Individuals start open source projects, which will provide a solution to their own problem. A perfect example is the tool cryptomator. It does a great job in file encryption and covers a lot of requirements but totally lacks the key management and because of this will only work for a single user, but not for project groups in a company.
Another reason might be, that the customers for such an enterprise file encryption tool in 95% of the cases runs Windows on their clients and may thus be used to install and use closed source software – so why should the software vendor bother about an open source busines model?

With the growing pressure of undemocratic survailance requests even by the German government the threat through backdoors and unpublished zero days increases dramatically. In a sensitive area like data encryption, where data obviously is to be protected from preying eyes, open source solutions can help to regain the trust in such software.
So I urge all open source companies with data storage centric products to think about enhancing their portfolio with an open source project for a trustyworthy, modern, enterprise ready file encryption solution. In my opinion this is not only a gap in the market but would also be a great help for a mature and democratic society.

,

ownCloud X Launch Event

Zwei-Faktor-Authentifizierung für ownCloud mit privacyIDEA.

Am 23. Mai 2017 fand in Köln das ownCloud X Launch Event statt. Die NetKnights GmbH war als Sponsor dort vertreten und ich selber hielt einen Vortrag über Zwei-Faktor-Authentifizierung – speziell mit ownCloud.

In den Pausen konnten die Besucher an den Ständen der Sponsoren vorbeischauen oder etwas zu Trinken oder zu Essen genießen.

Zwei-Faktor-Authentifizierung im ganzen Unternehmen

Die Gespräche mit den Interessenten zeigten erneut deutlich:

Der Wunsch nach Zwei-Faktor-Authentifizierung ist nicht isoliert auf eine Anwendung wie ownCloud zu betrachten sondern Teil einer übergeordneten Sicherheitsstrategie.

privacyIDEA bietet einen zentralen Authentifizierungs-Dienst der die ideale Ergänzung für das Identity-Management im Unternehmen ist. ownCloud kann mit Hilfe der privacyIDEA ownCloud App an privacyIDEA angebunden werden – doch genauso kann das Authentifizierungsobjekt des Benutzers für die Anmeldung an Firewall, VPN, CRM, CMS oder jedem anderen beliebigen TLA genutzt werden.

Möchten Sie gerne mehr erfahren, wie Zwei-Faktor-Authentifizierung auch in Ihrem Unternehmen sinnvoll umgesetzt werden kann?

Dann kontaktieren Sie uns!

Möchten Sie auf dem Laufenden bleiben? Dann abonnieren Sie unseren Newsletter!

,

privacyIDEA 2.19 – Performance, U2F und sichere Smartphone Apps

Heute wurde privacyIDEA 2.19 veröffentlicht. Pakete sind in den Launchpad-Repositories für Ubuntu 14.04LTS und 16.04LTS verfügbar. Über den Python Package Index kann privacyIDEA auf beliebigen Distributionen installiert werden.

Neue Funktionen in privacyIDEA

Performance bei der Authentifizierung

privacyIDEA 2.19 ist bis zu 72% schneller!

Die Version 2.19 verzeichnet in Labortests einen Geschwindigkeitszuwachs. Die Zeiten für eine Authentifizierungsanfrage konnten um bis zu 72% gesenkt werden. Dies ist unter anderem einem neuen, generischen User-Cache zu verdanken. Dieser speichert die Zuordnung von Loginname zu Benutzerobjekt in der lokalen Datenbank und macht somit die Zugriffe auf das Benutzerverzeichnisse für einen konfigurierbaren Zeitraum übeflüssig.

Ausgewählte U2F Geräte für Benutzer

Der Administrator kann nun über Richtlinien definieren, welchen Typ eines U2F-Gerätes ein Benutzer registrieren kann. Außerdem kann der Administrator ebenfalls über Richtlinien steuern, mit welchem Typ U2F-Gerät sich ein Benutzer an einem bestimmten System anmelden darf. Somit können gewissen U2F-Geräte von der Nutzung in Ihrem Unternehmen ausgeschlossen werden bzw. die Nutzung von Geräten spezieller Hersteller erzwungen werden.

Sichere Smartphone Apps mit privacyIDEA

Der klassische Rollout-Prozess beinhaltet viele Probleme, die privacyIDEA 2.19 lösen kann.

In einem früheren Beitrag haben wir bereits auf die Beschränkungen der üblichen Smartphone-Apps wie dem Google Authenticator hingewiesen. Es ist nachteilig, als Unternehmen oder große Organisation nicht die volle Kontrolle über den Rollout-Prozess beim Benutzer zu haben. Daher wurde in der Version 2.19 von privacyIDEA nun eine bessere Rollout-Möglichkeit geschaffen, bei der sowohl eine Smartphone-App als auch privacyIDEA Komponenten zur Berechnung des geheimen Schlüssels beitragen können. Dies verhindert ein einfaches Kopieren des QR-Codes.

Mehr Details zu diesem Thema finden Sie im privacyIDEA Blog.

Weitere Funktionen

Die Version 2.19 kommt mit weiteren Detail-Verbesserungen wie der Nutzung von IP-Adressen oder Browser Agents im Event-Handler. Außerdem wurde die Speicherung von Datums- und Zeitangaben in privacyIDEA konsolidiert. So werden nun bei jeder Zeit die Zeitzone mitgespeichert, was die Arbeit in internationalen, weltumspannenden Setups erleichtert.

Es lohnt sich ein Blick auf das komplette Changelog zu werfen.

Enterprise Edition und Beratung

Die NetKnights bieten Ihnen Beratung und Support im Rahmen der privacyIDEA Enterprise Edition. Damit haben Sie den Investitionsschutz von Opensource und die Betriebssicherheit durch einen professionellen SLA. Stabile Enterprise-Pakete runden das Angebot ab.

 

Sie wollen auf dem Laufenden bleiben? Dann abonnieren Sie unseren Newsletter!

Sie möchten Sich das System selber ansehen? Beantragen Sie eine Testinstanz!

Sie wollen mehr wissen? Rufen Sie uns an!

,

Einfache Unternehmens-2FA für ownCloud X

Vor wenigen Tagen hat ownCloud seinen Marketplace gestartet. Dieser gestattet die einfache und schnelle Installation von ownCloud Apps in ownCloud. Die privacyIDEA ownCloud App der NetKnights GmbH war eine der ersten verfügbaren Apps im Marketplace. Mit der privacyIDEA ownCloud App kann der Zugang zu einer ownCloud Installation um eine zentral verwaltete Mehr-Faktor-Authentifizierung erweitert werden. Die Authentisierungsgeräte der Mitarbeiter werden dabei im privacyIDEA Authentication Server verwaltet.

Installation der privacyIDEA ownCloud App

In ownCloud X erreicht der Administrator den integrierten Marketplace über der obere linke Menü.

In den Kategorien kann er nach „Security“ filtern. Über den Vorteil einer zentralen 2FA-Verwaltung gegenüber der integrierten TOTP-App schrieb ich bereits im Security Insider.

Ein Klick auf den Titel der privacyIDEA ownCloud App bzw. „privacyIDEA Two Factor Authentication“ zeigt die Details der App im Marketplace.

Der Administrator installiert mit Klick auf den blauen Knopf „Install“ die App. Dies geht sehr schnell. Danach ist der blaue Knopf grau.

privacyIDEA ownCloud App konfigurieren

Nun muss die privacyIDEA ownCloud App noch konfiguriert werden.

Dazu geht der Administrator im rechten Menü auf Settings-> Additional  und kann nun im Bereich privacyIDEA 2FA angeben, wo der privacyIDEA Server zu finden ist. Dazu gibt er die URL des privacyIDEA Servers an.

Achtung: Eventuell ist beim ersten Test der Haken bei „SSL Zertifikat überprüfen“ zu entfernen. Natürlich sollte in einem produktiven Setup die SSL Zertifikate immer überprüft werden!

Dies ist nun schon alles, was der Administrator innerhalb von ownCloud tun muss.

Konfiguration in privacyIDEA

Wir gehen davon aus, dass Sie privacyIDEA entsprechend einer möglichen Installationsvariante bereits installiert haben. Im Folgenden binden wir die Benutzerverwaltung von ownCloud an privacyIDEA an, so dass der Administrator innerhalb von privacyIDEA allen Benutzern einen Token zuweisen kann.

Benutzerquelle definieren

Als erstes definiert der Administrator die ownCloud-Datenbank als Benutzerquelle. Dies macht er in Konfiguration->Benutzer.

Benutzer-Realm anlegen

Danach wird unter Konfiguration->Realm mit dieser Benutzerquelle ein Realm erzeugt. In unserem Beispiel heißt dieser „oc“.

Wenn der Administrator nun das Benutzer-Tab aufruft, sind die Benutzer aus ownCloud innerhalb von privacyIDEA sichtbar.

Token ausrollen

Nun kann der Administrator einen Benutzer auswählen, und diesem einen Token – bspw. einen TOTP/Smartphone-App – ausstellen. Alternativ können sich die Benutzer selber innerhalb von privacyIDEA anmelden und sich selber einen Token ausrollen.

privacyIDEA unterstützt viele unterschiedliche Tokentypen, so dass hier genau definiert werden kann, welchen Token jeweils ein Benutzer hat.

So kann der Administrator bzw. die IT-Abteilung an zentraler Stelle regeln, dass Benutzer für ownCloud einen zweiten Faktor verwenden müssen und welcher Faktor dies sein soll. Verloren gegangene Authentisierungs-Geräte sind ebenfalls kein Problem. privacyIDEA unterstützt viele verschiedene Möglichkeiten und Workflows, solche Szenarien abzubilden.

Anmeldung

Nun kann sich der Benutzer im ersten Schritt mit seinem ownCloud-Passwort und im zweiten Schritt mit dem von privacyIDEA verwalteten Authentisierungs-Gerät an ownCloud anmelden.

Für den produktiven Betrieb von privacyIDEA und der privacyIDEA ownCloud App benötigen Sie eine Subskriptions-Datei.

Viel Erfolg beim sicheren Anmelden!

, ,

Zwei-Faktor-Anmeldung überall mittels privacyIDEA LDAP-Proxy

Um die Anmeldung an einer Applikation mit einem zweiten Faktor abzusichern gibt es verschiedene Ansätze, die wir mit privacyIDEA bisher auch verfolgt haben.

Zwei-Faktor-Authentifizierung mittels Standard-Protokolle und Plugins

Wenn die zu schützende Applikation Standard-Protokolle wie bspw. RADIUS oder SAML unterstützt, dann kann die Überprüfung des zweiten Faktors im RADIUS Server oder im SAML Identity Provider vorgenommen werden. An der Applikation sind somit keine Änderungen vorzunehmen. Mit privacyIDEA konnte dies bisher mit dem privacyIDEA FreeRADIUS Modul oder mit dem privacyIDEA SimpleSAMLphp Plugin gelöst werden.

Andere Applikationen bieten ein flexibles Authentifizierungs-Framework, so dass die Anmeldung an einer solchen Applikation durch die Entwicklung eines kleinen Plugins um einen zweiten Faktor erweitert werden kann. Hierzu gibt es eine breite Auswahl an Plugins für verbreitete Applikationen wie TYPO3, ownCloud, Nextcloud, WordPress, dokuwiki, django, OTRS, Apache, NGINX, PAM/OpenVPN oder die Anmeldung am Windows Desktop.

Doch manche Applikationen bieten keine RADIUS-Schnittstelle und auch kein einfaches Authentifizierungs-Framework. Manchmal ist auch einfach die Zeit zu knapp oder die Programmiersprache der Applikation zu unangenehm.

privacyIDEA LDAP-Proxy

Um in solchen Fällen ebenfalls auch diesen Applikationen die Sicherheit einer starken Authentifizierung gegen privacyIDEA zu ermöglichen, entwickeln wir den privacyIDEA LDAP-Proxy.

Der privacyIDEA LDAP-Proxy kommt dann zum Einsatz, wenn eine Applikation die Benutzer gegen einen LDAP-Server wie OpenLDAP oder Microsoft Active Directory authentifiziert. Der privacyIDEA LDAP-Proxy wird dabei zwischen die Applikation und den LDAP-Server gesetzt. Die Applikation wird derart umkonfiguriert, dass sie nicht mehr den originalen LDAP-Server sondern den LDAP-Proxy kontaktiert. der privacyIDEA LDAP-Proxy entscheidet dann, wie die Benutzer mit zwei Faktoren zu authentifizieren sind und welche Anfragen an den originalen LDAP-Server weitergeleitet werden.

Die Authentifizierung erfolgt für den Benutzer also völlig Transparent.

Der Vorteil für die IT-Abteilung liegt auf der Hand: Der originale LDAP-Server wird nicht angetastet und die Applikation erfährt lediglich eine Konfigurationsänderung im Rahmen der vorgesehen und vom Hersteller unter Support stehenden Rahmenbedingungen.

Gegenüber Zwei-Faktor-Lösungen, die rein auf OpenLDAP basieren, hat die Variante des LDAP-Proxies zusätzlich zur Unveränderbarkeit des originalen LDAP-Servers weiterhin den Vorteil, dass sie eben nicht nur mit OpenLDAP sondern auch mit jedem anderem LDAP-Dienst wie dem weit verbreiteten Microsoft Active Directory oder Samba4 funktioniert.

Das Beispiel-Szenario

In diesem beispielhaften Szenario betrachten wir die Anmeldung an SuiteCRM. SuiteCRM ist eine Open Source Customer Relation Managemet Lösung, für die es kein Zwei-Faktor-Plugin gibt. Allerdings kann SuiteCRM die Benutzer gegen LDAP authentifizieren. Daher soll in diesem Fall der privacyIDEA LDAP-Proxy zum Einsatz kommen.

Wir könnten genauso jede beliebige andere Applikation betrachten, die Benutzer aus einem LDAP-Verzeichnis verwendet. Wir installieren SuiteCRM auf einem Univention Corporate Server, da die Installation und Konfiguration sich hier als extrem einfach erweist. Nach der Installation ist SuiteCRM sofort so konfiguriert, dass Benutzer, die im Univention Corporate Server Domain Controller angelegt sind, sich an SuiteCRM mit ihrem LDAP-Passwort anmelden können. Statt eines UCS Domain Controllers hätten wir genauso eine native OpenLDAP-Instanz oder ein Microsoft Active Directory verwenden könnten.

Auch der privacyIDEA Authentication Server kann wahlweise auf einer beliebigen Linux-Distribution oder auf einem Univention Corporate Server installiert werden. privacyIDEA ist ebenfalls im Univention App Center enthalten, so dass auch privacyIDEA automatich gegen den LDAP-Server konfiguriert wird und lediglich den Benutzern die zweiten Faktoren in Form von Yubikeys, OTP-Token oder Smartphone-Apps zugewiesen werden müssen.

SuiteCRM wird schließlich derart umkonfiguriert, dass nicht mehr der UCS LDAP-Server sondern der LDAP-Proxy gefragt wird.

Bei Bedarf können mehrere der beteiligten Komponenten auf einem System installiert werden.

Integration

LDAP-Proxy installieren und konfigurieren

Der LDAP-Proxy ist in einer Beta-Version zur Zeit über Github erhältlich. Durch die Implementierung auf Basis von Python und Twisted ergibt sich eine Vielzahl von Möglichkeiten für das Deployment. Die nötigen Einstellungen werden in einer zentralen Konfigurationsdatei vorgenommen. Unter anderem muss dem LDAP-Proxy hier mitgeteilt werden, wo der UCS LDAP-Server und die privacyIDEA-Instanz zu finden sind. Außerdem wird ein Service Account auf dem UCS LDAP-Server benötigt, dessen Zugangsdaten in der Konfigurationsdatei hinterlegt werden.

Für genauere Informationen konsultieren Sie die Datei README.md.

Der LDAP-Proxy wird wie folgt gestartet

twistd -n ldap-proxy -c config.ini

Im produktiven Betrieb würden Sie den LDAP-Proxy später automatisch als Service über systemd starten. Die Konfigurationsdatei config.ini kann entsprechend an beliebiger Stelle liegen. Die Datei example-proxy.ini enthält entsprechende ausführliche Kommentare, so dass schnell ersichtlich sein sollte, welche Konfigurationen vorzunehmen sind.

Die Konfigurationsdatei

Entscheidend sind die folgenden Konfigurationen:

In der Sektion privacyidea geben Sie mit dem Parameter instance an, wo der LDAP-Proxy den privacyIDEA Server erreicht.

In der Sektion ldap-backend geben Sie an, wo der originale LDAP-Server steht und ob die Verbindung über LDAP oder LDAPS oder LDAP+STARTTLS durchgeführt wird.

Auf welchem Port der LDAP-Proxy selber lauscht können Sie in der Sektion ldap-proxy mit dem Parameter endpoint angeben.

Schließlich müssen Sie noch definieren, welches LDAP-Attribut als Loginname verwendet wird. Dies geschieht im Parameter attribute in der Sektion user-mapping.

Der Service-Account ermöglicht allgemeines Suchen

Für einfache Applikationen, die lediglich den Benutzer mittels eines Binds überprüfen, reicht dies bereits aus. SuiteCRM nutzt allerdings für allgemeine Suchanfragen zusätzlich einen Service-Account. Dieser muss in der Sektion ldap-proxy bei passthrough-binds und in der Sektion service-account eingetragen werden.

SuiteCRM konfigurieren

In SuiteCRM muss der Administrator lediglich den zu kontaktierenden LDAP-Server ändern. Dazu geht er ins Administrations-Menü, das man oben rechts erreicht.

Dort wählt er den Punkt „Passwordmanagement“.

Dort erreicht man schließlich die Konfigurationsmöglichkeiten für den LDAP-Server. Der dort eingetragene LDAP-Server muss nun auf den FQDN bzw. IP des LDAP-Proxies abgeändert werden.

Fazit

Der Benutzer im SuiteCRM wird nun über den LDAP-Proxy in Zukunft gegen privacyIDEA authentifiziert. Das komplette Passwort-Feld bei der Anmeldung an SuiteCRM wird an privacyIDEA gesendet. Wie ansonsten auch muss der Benutzer also sein statisches Passwort und einen OTP-Wert eingeben.

Die konkrete Art des verwendeten zweiten Faktors kann über privacyIDEA individuell für jeden Benutzer geregelt werden. Denkbar sind wie bereits erwähnt Yubikey, OTP-Token und OTP-Karten, Smartphone-Apps wie Google Authenticator aber auch der Versand eines Einmalpasswortes per SMS oder Email.

Der LDAP-Proxy wird weiter ausgebaut und wir freuen uns über jegliches Feedback. Wollen Sie auf dem laufenden bleiben, so beobachten Sie das Github Repository oder abonnieren Sie unseren Newsletter.

,

Zwei-Faktor-Authentifizierung an ownCloud mit modernen U2F-Geräten

Sichere Anmeldung an ownCloud

Zwei-Faktor-Authentifizierung an ownCloud mit modernen U2F-Geräten dank privacyIDEA

Nürnberg, Kassel – 06. Februar 2016. Das IT-Security Unternehmen NetKnights GmbH ermöglicht mit der Version 2.2 der privacyIDEA ownCloud App die Anmeldung an ownCloud mit U2F-Geräten. Somit ist der Zugriff auf ownCloud nur mit einem zweiten Faktor möglich. Unternehmen können die Anmeldung der Benutzer mit einem zweiten Faktor erzwingen und dadruch Sicherheitsrisiken weiter minimieren.

Mit der privacyIDEA ownCloud App können Unternehmen sicherstellen, dass Benutzer bei der Anmeldung an ownCloud einen zweiten Besitzfaktor vorweisen müssen. Nur dann erhalten die Mitarbeiter Zugriff auf die sensiblen Unternehmensdaten. Die Besitzfaktoren werden dabei zentral in privacyIDEA verwaltet. Dies können OTP-Token wie klassische Hardware-Schlüsselanhänger, Smartphone Apps wie FreeOTP oder Google Authenticator, SMS oder OTP-Karten sein.

In der neuesten Version 2.2 der privacyIDEA ownCloud App können sich die Benutzer nun auch mit U2F-Geräten wie dem Yubikey 4 authentisieren. Das entsprechende U2F-Gerät wird entweder vom Administrator oder vom Benutzer zentral in privacyIDEA registriert und steht danach sofort für die Anmeldung an ownCloud zur Verfügung.

Der Vorteil für Unternehmen liegt hierbei auf der Hand. Alle Authentisierungs-Geräte stehen unter der zentralen Kontrolle des Authentisierungssystems und die Nutzung durch die Benutzer folgt fest definierten Richtlinien. Somit lassen sich auch die strengsten Compliance-Anforderungen umsetzen.

Über ownCloud

ownCloud ist die offene Plattform für die digitale Zusammenarbeit. ownCloud ermöglicht den bequemen Zugriff auf Dateien unabhängig von deren Speicherort oder dem verwendeten Gerät und steigert dadurch sowie durch eine Vielzahl kollaborativer Funktionen die Produktivität. Dabei können die Anwender selbst bestimmen, welche Daten in welche Cloud verlagert werden und welche im Unternehmen verbleiben (On-Premises). Gleichzeitig bietet ownCloud volle Kontrolle und Transparenz bei der Verwaltung sensibler Daten. Durch die Einbindung in bestehende sicherheits- und compliancekonforme Systeme können vorhandene Geschäftsprozesse weiter genutzt werden. Möglich wird dies durch die hohe Flexibilität von ownCloud auf Basis einer offenen, modularen Architektur mit vielfältigen Erweiterungsmöglichkeiten und einzigartigen Funktionen für die Modernisierung der Dateninfrastruktur.

Weitere Informationen unter http://www.owncloud.com/de.

Über NetKnights GmbH und privacyIDEA

Die NetKnights GmbH, Kassel, ist ein unabhängiges IT-Security-Unternehmen, das Dienstleistungen und Produkte aus den Bereichen starke Authentisierung, Identitätsmanagement
sowie Verschlüsselung anbietet. Die NetKnights GmbH stellt das Core-Entwickler-Team für die
modulare Authentifizierungslösung privacyIDEA, die sich auf einfache Weise in bestehende IT-
Infrastrukturen integrieren lässt. privacyIDEA hat als Open-Source-Software kein herstellerbestimmtes End-of-Life und lässt sich damit auf unbegrenzte Zeit nutzen. Für den
kritischen Einsatz von privacyIDEA in Unternehmen bietet die NetKnights GmbH eine Enterprise
Edition mit verschiedenen Subskriptions- und Support-Stufen an.

Weitere Informationen unter https://netknights.it.