ASP.NET with C# API

ZWEI-FAKTOR-AUTHENTIFIZIERUNG UNTER ASP.NET MIT C#

Verwenden Sie auf Ihrer Seite die SecSign ID ASP.NET Zwei-Faktor-Authentifizierung, die Ihnen eine einfache und zugleich hochsichere Benutzeranmeldung mit einem iOS- oder Android-Gerät bietet sowie Desktop-Anwendungen absichert.


Erfahren Sie, warum unsere Zwei-Faktor Authentifizierung die Beste ist und Sie die Sicherheit Ihres Unternehmens upgraden sollten. Für Entwickler haben wirhier Informationen zusammengetragen.

Erfahren Sie mehr über Inhouse-Installationen und Ihre individuelle Firmen-App mit Ihrem Corporate Design.

Downloaden Sie das Plugin kostenlos in der Cloud für bequemen und sicheren Schutz.


Table of contents

    Die SecSign ID API für ASP.NET ist in C# geschrieben. Im ASP.NET API Archive befindet sich neben der kompilierten API in einer DLL-Bibliothek auch der API-Quelltext, sowie ein kleines Beispiel. Sie finden den Quellcode als auch das Beispiel natürlich auch auf unserer GitHub-Seite SecSignID ASP.NET / C# Interface.

    Der eigentliche Umfang der API sind lediglich zwei Klassen mit Hilfe dessen sich die Zwei-Faktor-Authentifizierung (kurz 2FA) realisieren lässt:


    SecSignIDAPI:
    die Klasse beinhaltet alle Funktionen zum Er- und Abfragen einer sogenannten Authentifizierungs-Session

    AuthSession: die Klasse beinhaltet alle Informationen einer sogenannten Authentifizierungs-Session (kurz eben AuthSession)

    Fragen? Kontaktieren Sie uns, wenn Sie Hilfe beim Setup des SecSign ID Plugins brauchen oder Ihnen ein Plugin für eine andere Programmierumgebung fehlt.

    1. Integration der Zwei-Faktor-Authentifizierung mit SecSign ID ASP.NET / C# API

    ASP.NET (Active Server Pages .NET) ist ein serverseitiges Verfahren von Microsoft auf Basis des .NET Frameworks. Das .NET Framework ist dabei eine von Microsoft entwickelte Software-Plattform einerseits für die Entwicklung als auch für die Ausführung von Programmen. Es enthält eine Laufzeitumgebung (die Common Language Runtime) sowie Klassenbibliotheken, Programmierschnittstellen und Dienstprogramme. Das .NET Framework umfasst mehrere Sprachen, die zunächst in eine Zwischensprache (die sogenannte Common Intermediate Language, kurz CIL) übersetzt werden und später mit einem Just-In-Time in der .NET-Laufzeitumgebung auf die richtige Zielplattform kompiliert.
    Zum .NET Framework dazugehörige Sprachen sind unter anderem C# (C-Sharp), F#, (F-Sharp), J# (J-Sharp) und VB.NET. Daneben gibt es auch implementierte funktionale und logische Sprachen wie Fortran, Lisp und Prolog, die aber nicht Gegenstand dieses Tutorials sein werden. Eine vollständige Liste aller Sprachen sowie deren Implementierung im .NET Framework findet man auf Wikipedia.
    Ein weiterer Vorteil des .NET Frameworks ist die umfangreiche Klassenbibliothek, die unzählige Funktionalitäten zur Verfügung stellen und Zugriffe auf Systemfunktionen bieten.

    ERSTE SCHRITTE

    Nach dem Herunterladen und Entpacken des Archivs kann das Projekt des Beispiels ‚WebExample‘ genutzt werden. Auf Windows nutzt man Visual Studio, auf Linux oder MacOSX kann man Xamarin (Mono) nutzen.

    In das Beispiel muss die Bibliothek bzw. Dll oder die ‚SecSignIDAPI.cs‘ eventuell noch als Verweis hinzugefügt werden.

    Visual Studio

    Im Solution Explorer des Visual Studio sieht man das Beispiel-Projekt ‚WebExample‘ und die Referenzen, die es beinhaltet.
    Eventuell wird die Referenz SecSignIDApi mit einem gelben Ausrufezeichen markiert, weil die Dll nicht gefunden werden konnte.
    In diesem Fall können Sie die Referenz löschen. Anschließend können Sie mittels Rechtsklick auf ‚References‘ neue Referenzen hinzufügen.

    References > Add Reference

    Auf dem Dialog wechseln Sie zum Tab ‚Browse‘. Sie sollten dort in dem Verzeichnis des WebExample sein. Nun gehen Sie dort ein Verzeichnis nach oben bzw. in das Verzeichnis, in dem sich die Dll aus dem Zip-Archiv befindet.
    Diese wählen Sie diese aus und bestätigen mit ‚OK‘

    Sie können natürlich auch einfach die ‚SecSignIDApi.cs‘ als Datei dem Projekt hinzufügen über z.B. Rechtsklick auf das Projekt:

    WebExample > Add > Existing Item

    Auf dem Dialog können Sie dann im überliegenden Verzeichnis die ‚SecSignIDApi.cs‘ hinzufügen.

    Siehe Microsoft how to.

    Xamarin (Mono Framework)

    In Xamarin kann man einen Verweis wie folgt hinzufügen:

    1. In der linken Seitenleiste der Projektmappe Rechtsklick (bzw. CTRL+Linksklick) auf die Verweise des Projekt.
    2. Anschließend wählt man Verweise bearbeiten. Auf dem Tab ‚.NET-Assembly‘ kann man über ‚Durchsuchen‘ die Dll auswählen, die dem Archiv beiliegt./li>

    Eine andere Möglichkeit ist, die Datei ‚SecSignIDAPI.cs‘ einfach in das Projekt einzubinden.

    2. Kommunikation mit dem ID-Authentifizierungsserver

    Die Kommunikation mit dem ID-Authentifizierungsserver, oder kurz ID-Server, erfolgt über die Klasse ‚System.Net.WebRequest‘. Über die Klasse werden url-kodierte Parameterlisten an den ID-Server geschickt.

    Beim öffentlichen ID-Server wird lediglich diese Art der Kommunikation genutzt. Der vor dem öffentlichen Server vorgeschaltete SecSign Routing Server verhindert andere Anfragen. Bei einer Inhouse-Installation sind jedoch auch andere Möglichkeiten der Kommunikation wie z.B. Webservice und SOAP möglich.

    3. Anfordern einer Authentifizierungs-Session

    Das Projekt ‚WebExample‘ besteht aus einer ‚Default.aspx‘, hinter der sich eine einfache Webseite mit einem HTML-Formular verbirgt. Das Formular hat im Wesentlichen nur ein Textfeld, in das die SecSign ID eingegeben werden kann. (Im Beispiel ist zusätzlich noch ein Validator vom Typ RegularExpressionValidator angegeben, um die SecSign ID zu prüfen, bevor diese zum Server geschickt wird. Darauf wird hier allerdings nicht eingegangen.) Wegen Problemen beim Einfügen von HTML-Code-Beispielen sind die öffnenden und schließenden Element-Zeichen durch eckige Klammern ersetzt.

    Zum Anfordern einer sogenannten Authentifizierungs-Session (AuthSession) wird die im Textfeld eingegebene SecSign ID zum ID-Server geschickt. Daneben werden noch die Adresse bzw. URL der Web-Anwendung und ein Name der Web-Anwendung zum ID-Server geschickt. Der Name wird dem Nutzer in einer Push-Notification auf dessen Smartphone angezeigt. Die URL der Web-Anwendung wird dem Nutzer auf dem Smartphone bei der Bestätigung der AuthSession angezeigt. Im Beispiel sieht man am Formular, dass gegen die Seite ~/SecSignID.aspx‘ abgeschickt wird. In der Klasse ‚public partial class SecSignID : System.Web.UI.Page‘ wird die Methode ‚Page_Load“ überschrieben, in der geprüft wird, in welchem Schritt der Anmeldung man sich befindet. Die Methode wird immer aufgerufen, sobald die Seite geladen wird. Wenn das Beispiel in Xamarin oder Visual Studio ausgeführt wird: http://localhost:8080/web-example/SecSignID.aspx Die SecSign ID API muss nun in der ASP.NET-Seite ‚SecSignID.aspx‘ eingebunden werden:

    Beim Senden der SecSign ID an die ASP.NET-Seite ‚SecSignID.aspx‘ wird nun vom ID-Server die AuthSession angefordert:

    Kann vom ID-Server eine AuthSession für die übergebene SecSign ID geholt werden, ist der Rückgabewert vom Typ ‚SecSignID.AuthSession‘. Ansonsten wird eine Exception mit einem Fehlercode und einer Fehlermeldung geworfen. (Im Beispiel wird noch genauer unterschieden zwischen System.Exception und System.Net.WebException. Letztere wird bei einem Verbindungsfehler geworfen, erstere eigentlich nur bei einem Fehler auf dem ID-Server z.B. wenn die angegebene SecSign ID nicht existiert.)

    4. Anzeige des Zugangssymbols und Sichern der Sitzungsparameter

    Nachdem vom ID-Server eine Authentifizierungs-Session für die übergebene SecSign ID angefordert werden konnte, enthält das zurückgegebene Objekt vom Typ ‚SecSignID.AuthSession‘) folgende Werte:

    authSession.GetSecSignID() : die an den ID-Server geschickte SecSign ID

    authSession.GetAuthSessionID() :
    die ID der angeforderten Authentifizierungs-Session

    authSession.GetRequestID() : die ID des Requests, die bei allen folgenden Requests mitgeschickt werden muss

    authSession.GetRequestingService() : der an den ID-Server geschickte Service-Name

    authSession.GetRequestingServiceAddress() : die an den ID-Server geschickte Service-URL

    authSession.GetIconData() : des Access-Pass als base64-kodierte PNG-Bilddaten.

    Das sogenannte Zugangssymbol, die base64-kodierte PNG-Grafik, muss dem Nutzer, der sich anmelden möchte, angezeigt werden. Die gleiche Grafik wird vom ID-Server an dessen Smartphone geschickt, wo er dann durch Vergleich der Grafik die AuthSession auf dem Smartphone akzeptiert. Daneben sollten die anderen Werte der AuthSession ebenfalls gespeichert werden, da sie teilweise später noch benötigt werden, um z.B. den Zustand der AuthSession auf dem ID-Server zu erfragen. Zum Beispiel, ob der Nutzer die AuthSession bereits akzeptiert hat oder nicht. Im Beispiel werden die Daten aus dem AuthSession-Objekt in versteckten HTML-Feldern gespeichert. Ebenfalls denkbar ist das Speichern in einer temporären Session auf dem Webserver oder das Speichern in einer Datenbank. Die Daten werden im Beispiel nun in der ASP.NET-Seite ‚SecSignID.aspx‘ gespeichert, da sämtliche Posts eines Formulars bis zum Abschluss der Anmeldung gegen diese Seite geht.

    Das Formular in ‚SecSignID.aspx‘ sieht wie folgt aus:

    In dem Formular findet man auch die beiden Buttons zum Prüfen der AuthSession sowie zum Abbrechen. Die Unterscheidung der beiden geschieht auf dem Server (runat=’server‘) und anhand Ihrer ID.

    5. Prüfen und Abfragen des AuthSession Status

    Eine AuthSession kann mehrere Zustände haben:

    Pending: die AuthSession ist angefordert worden, aber weder bestätigt noch anderweitig reagiert

    Expired: die AuthSession ist abgelaufen, wobei der Timeout bei 2 Minuten liegt
    Accepted: die AuthSession ist vom Nutzer auf dessen Smartphone bestätigt worden

    Denied: die AuthSession ist vom Nutzer auf dessen Smartphone abgelehnt worden

    Suspended: der ID-Server hat die AuthSession zurückgezogen z.B. wenn der Nutzer mehrere Anmeldeversuche gleichzeitig startet

    Canceled: der Nutzer hat den gesamten Anmelde-Vorgang auf der Webseite abgebrochen

    Fetched: der Nutzer hat den Access-Pass bereits auf seinem Smartphone, aber die AuthSession noch nicht bestätigt

    Zum Abfragen des Zustandes der AuthSession nutzt man die Methode ‚GetAuthSessionState‘. Dabei müssen die SecSign ID, die Request-ID und die AuthSession-ID zum ID-Server geschickt werden.

    Diese Prüfung geschieht im Beispiel wieder in der ASP.NET-Seite ‚SecSignID.aspx‘, da der Button aus obigem Formular die Formulardaten an diese Seite schickt:

    6. Auf den Sitzungs-Status reagieren

    In obigem Beispiel sieht man, wie auf den vom ID-Server gesendeten Zustand der AuthSession reagiert wird: Ist der Zustand ‚PENDING‘ oder ‚FETCHED‘ (sobald der Nutzer auf seinem Smartphone den Prozess der Bestätigung begonnen hat, ändert sich der Zustand der Session auf dem ID-Server von ‚PENDING‘ zu ‚FETCHED‘. Erst wenn der Nutzer auf seinem Smartphone nun den richtigen Access-Pass wählt, ändert sich der Zustand erneut), hat der Nutzer die Sitzung bzw. AuthSession weder abgelehnt noch sie akzeptiert. Im Beispiel wird dem Nutzer dies mitgeteilt und der Access-Pass weiterhin angezeigt. Ist der Zustand zum Beispiel ‚DENIED‘ oder ‚CANCELED‘ wurde entweder der Anmeldevorgang abgebrochen oder der Nutzer hat auf seinem Smartphone den Access-Pass abgelehnt. In diesem Fall wird im Beispiel auf die Startseite zurückgegangen. Bindet man die SecSign ID ASP.NET API in sein eigenes Projekt ein, ist es einem selbst überlassen, wie man intern damit umgeht und ob man z.B. spezielle Seiten anzeigt oder Informationen darüber speichert.
    Für den Anmeldevorgang bedeutet es, dass der Nutzer nicht an der Webseite angemeldet ist. Ist der Zustand der AuthSession ‚ACCEPTED‘, hat der Nutzer auf seinem Smartphone den Access-Pass und somit die Sitzung akzeptiert. Die AuthSession erhält diesen Zustand nur, wenn der Nutzer auf dem Smartphone per Vergleich den richtigen Access-Pass auswählt. Im Beispiel wird eine ASP.NET-Seite ‚Intern.aspx‘ angezeigt.

    Für die Anmeldung heißt es, dass der Nutzer sich erfolgreich angemeldet hat. Je nach vorliegendem System oder CMS kann über die SecSign ID der CMS-Nutzer herausgefunden und auf dem System angemeldet werden. Bindet man die SecSign ID ASP.NET API also in sein Projekt ein, kann nun z.B. Folgendes passieren: Hat man ein CMS-System mit eigener Nutzerverwaltung, wobei einzelnen Nutzern jeweils eine SecSign ID zugewiesen worden ist, kann an dieser Stelle der CMS-Nutzer zu der SecSign ID erfragt werden und anschließend am CMS angemeldet werden. Dabei ist es vom CMS abhängig, wie dies geschieht. Sei es durch Session-Cookies wie z.B. bei WordPress oder Joomla oder durch das Speichern angemeldeter Nutzer in einer Datenbank. In seinem Projekt kann man also an der Stelle, an der der Zustand der AuthSession ‚ACCEPTED‘ ist, einen bestimmten Nutzer anmelden oder einen bestimmten Zustand setzen. Je nach Projekt können so auch Aktionen gestartet werden, je nachdem ob der Nutzer die nötigen Rechte besitzt. Damit ist mit der SecSign ID API nicht nur eine Zwei-Faktor-Authentifizierung möglich, sondern auch, dass in komplexen Systemen der Start von Diensten oder allgemein irgendwelchen Aktionen von einer erneuten Nutzer-Bestätigung abhängig gemacht werden. Der Nutzer, der einen Dienst starten möchte, authentifiziert sich mittels seiner SecSign ID und seinem Smartphone, so dass das System darüber prüfen kann, ob der Nutzer die notwendigen Berechtigungen hat und anschließend die Aktion ausführt. Die Authentifizierung löst somit den Start von Diensten aus.

    7. Abbruch der Sitzung

    Clientseitig kann die AuthSession über die Methode ‚CancelAuthSession‘ abgebrochen werden. Dazu wieder das Beispiel aus ‚SecSignIDAPI.aspx‘:

    8. Integration in anderen Sprachen des.NET Frameworks

    Mit dem SecSign ID ASP.NET Plugin lässt sich einfach eine Zwei-Faktor-Authentifizierung für ASP.NET-Seiten realisieren. Ebenso denkbar ist natürlich eine Zwei-Wege-Autentifizierung an einem Webdienst, indem SecSign ID als Authentifizierungsstufe einfach vor- oder dahinter geschaltet wird. Der genaue Unterschied zwischen Zwei-Faktor-Authentifizierung und Zwei-Stufen-Authentifizierung wird in diesem Blog-Artikel betrachtet. Die API an sich ist jedoch nicht spezifisch für ASP.NET, sondern in C# geschrieben. Dadurch ist es möglich, die API und die Zwei-Faktor-Authentifizierung in jedes Projekt einzufügen, dass auf dem .NET Framework basiert. Da in der C#-API alle notwendigen Methoden zur Verfügung stehen, ebenso die für die Kommunikation mit dem ID-Server, braucht man nur die API ‚SecSignIDAPI.cs‘ einzubinden. Daneben ist es möglich zB in VB.NET-Projekten die kompilierte C#-Bibliothek einzubinden. Beispiel, wie man prinzipiell sprachfremde Bibliotheken einbindet, findet man zB auf Microsofts how to. Um nun die C#-Klasse in VB.NET zu nutzen, muss man lediglich in Visual Studio diese im VB.NET-Projekt als Verweis hinzufügen. Die SecSign ID C# API ist ‚CLS compliant‘ und hat als Mindestvoraussetzung .NET (bzw. Mono) Version 3.5, sodass die Bibliothek auch in Projekten, die das .NET Framework 4.0 oder 4.5 nutzen, verwendet werden kann. Um die eingebundene .NET Dll verwenden zu können, kann man entweder das Schlüsselwort ’new‘ verwenden, oder über ‚CreateObject‘ eine neue Instanz erstellen:

    oder statt:

    könnte man wie oben angesprochen die ‚CreateObject‘-Notation nutzen:

    9. Unsere APIS

    Wir haben eine stetig wachsende Liste an APIs und Plugins um die SecSign ID Zwei-Faktor Authentifizierung einfach und schnell in jedes Projekt zu integrieren.
    Wir bieten nicht nur APIs in zahlreichen Programmiersprachen, sondern auch Plugins für CMS, Server und VPN Umgebungen, oAuth2 und zahlreiche mehr. Die Plugins nutzen unsere APIs und bieten zusätzliche Funktionen, zum Beispiel Nutzer Management, einfache und native Installation, Logging oder die Integration in Firewalls oder Active Directories.

    Das JIRA Plugin beispielsweise nutzt die JAVA-API. Die PHP-API und JS-API wird von WordPress, Joomla, Drupal, Typo3 und vielen anderen genutzt. Die ASP.net/C#-API wird für die Windows und Cisco VPN genutzt und die C-API findet Verwendung um Unix SSH Services zu schützen. Die Objective-C API wird für unsere AppleTV und iPhone und iPad Apps genutzt.

    available_apis

    10. Erfahren Sie mehr

    Sie können die SecSign ID Zwei-Faktor Authentifizierung und den Zwei-Faktor Login durch eine einfach Integration des Plugins in Ihre Website oder Ihre Testumgebung kennenlernen. Oder testen Sie den Login auf unserer Website, ohne sich vorher zu registrieren. Sie haben bereits eine SecSign ID oder hätten gerne eine? Loggen Sie sich jetzt ein und nutzen Sie das Portal oder registrieren Sie sich ganz unkompliziert.

    Erfahren Sie selbst, wie schnell und unkompliziert der Login Prozess mit der Challenge-Response Authentifizierung mit 2048-bit Schlüsselpaaren ist. Sie brauchen keine Passwörter, und es werden keine vertraulichen Logindaten übertragen. Einfache Integration und unkomplizierte Nutzung.

    Für mehr Informationen zum patentierten SafeKey Verfahren finden Sie hier.

    Falls Sie eine API für eine Programmiersprache vermissen kontaktieren Sie uns unverbindlich. Falls Sie Hilfe mit der Integration in ein existierendes System brauchen oder kein passendes Plugin für Ihr Content Management System finden, kontaktieren Sie unser Support Team und wir helfen Ihnen gerne weiter.

    Ihr eigener ID-Server

    Die Inhouse Installation der SecSign ID bietet Ihnen die Flexibilität, sich mit Ihren bevorzugten Server, Services und Geräten zu verbinden. Passen Sie die SecSign ID Ihrer Unternehmensmarke an!

    your_own_id

    Warum sollte ich SecSign nutzen?

    Inhouse oder Cloud Lösungen

    Unsere Lösungen lassen sich leicht anpassen: Wählen Sie zwischen der durch uns betriebenen SecSign Cloud oder betreiben Sie selber den SecSign Authentifizierungsserver Inhouse oder in einem Rechenzentrum Ihrer Wahl. Mehr zum Inhouse Zwei-Faktor Authentifizierungsserver

    Einfache Anpassung an Ihre Bedürfnisse

    Wir passen die App an ihre Unternehmens Look-and-Feel an. Zwei-Faktor Authentifizierung angepasst an Ihre Bedürfnisse, für Ihre Kunden.

    Anwendungsfertiges SDK

    Integrieren Sie die SecSign Zwei-Faktor Authentifizierung in existierende Apps mit unserem SDK. Es könnte nicht einfacher gehen.

    Unkompliziertes Nutzer-Management

    Nutzen sie den Zwei-Faktor Authentifizierungsserver zum Schutz Ihres Active Directory/LDAP. Ihr individuelles Identity and Access Management System, beispielsweise mit verpflichtenden Updates und zahlreichen Sicherheitseinstellungen.

    Schützen Sie ALLE Logins

    Integration in sämtliche Login-Umgebungen: Web, Local, VPN, Remote Desktop, Mobile Logins und viele mehr.

    Plugins für alle Anwendungsgebiete

    Komplexe Integrationen gehören der Vergangenheit an: SecSign bietet Ihnen Plugins für nahezu alle Umgebungen.

    Letzte Blog Einträge, Neuigkeiten & Funktionen

    Crowd SSO

    21.09.2017

    Read More
    Do NOT follow this link or you will be banned from the site!