• Der Nutzer gibt die SecSign ID über den Internetdienst ein, welcher eine Authentifizierungsanfrage für die eingegebene SecSign ID an den SecSign ID Server sendet.
• Der ID Server sendet die Push Notification an das Mobilgerät des Nutzer
• Der ID Server sendet ein Zugangssymbol an den Internetdienst
• Der Internetdienst zeigt das erforderliche Zugangssymbol an
• Der Nutzer wählt die SecSign ID auf dem Smartphone aus und gibt eine PIN ein. Die mobile App bestätigt, dass der Nutzer auch der Besitzer der SecSign ID ist
• Der ID Server sendet das Zugangssymbol an die mobile App
• Der Nutzer bestätigt das richtige Zugangssymbol und die mobile App sendet dieses an den ID Server
• Der Internetdienst überprüft den Status der Authentifizierungssitzung
• Der ID Server bestätigt die Zugangserlaubnis
• Der Webdienst gewährt dem Nutzer den Zugriff

Endpunkte der SecSignID API sind folgende URLs:

https://httpapi.secsign.com, Port 443
https://httpapi2.secsign.com als Fallbackserver, Port 443

Die Schnittstelle erwartet HTTP-POST Anfragen und URL-kodierte Parameterlisten als Antwort.Die Antwort des Servers liegt ebenfalls im URL-kodierten Format vor.

Das URL-kodierte Format ist in einigen Sprachen wie Perl und C einfacher zu parsen. In Zukunft wird es aber so sein, dass über die Request-Header das Format mitgegeben wird und dann JSON auch unterstützt wird, so dass man JSON zum Server hinschicken kann und JSON zurückbekommt.

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.

Im ID-Server befindet sich eine Web Application Firewall, die kontrolliert, ob die Anzahl der erforderlichen Parameter übereinstimmt. Außerdem wird das Format der Parameter-Werte überprüft. Wenn die API zum Beispiel entweder true oder false erwartet, aber ein anderer Wert gesendet wird, dann wird ein Bad-Request-Fehler zurück gegeben (siehe 7. Fehlermeldungen).

Um einen Nutzer authentifizieren zu können, muss zuerst eine Authentifizierungs-Sitzung gestartet werden. Wird vom Client die Authentifizierungsanfrage gesendet, erhält der Client den Accesspass zurück und das Smartphone des Nutzers zeigt an, dass ein neuer Login bestätigt werden kann

Anfrage

Der Client sendet eine POST Anfrage zum SecSignID API Server um eine AuthSession anzufragen. Die zu übertragenden Parameter sind URL codiert, d.h. alle Schlüssel-Wertpaare sind durch ein „=“ getrennt und werden mit „&“ konkateniert: ParameterName1=Wert1&ParameterName2=Wert2…

“&”:ParameterName1=Value&ParameterName2=Value2…

Beispiel für einen Request zur Authentifizierung der SecSignID „johndoe“, auf einer Website mit Accesspass:

request=ReqRequestAuthSession&secsignid=johndoe&servicename=Testwebsite&serviceaddress=localhost&pluginname=wordpress&apimethod=SecSignIDApi_PHP

ANTWORT

Wenn die zuvor gesendete Anfrage akzeptiert wird, sendet der Server eine Antwort mit HTTP Statuscode 200 und folgende url-kodierte Parameter im Nachrichtenrumpf. Kommt es zu einem Fehler, wird der entsprechende Statuscode übergeben und die übertragene Parameterliste enthält Fehlerbeschreibungen (siehe 6. Fehlermeldungen).

authsessionid=9162914906710510618&servicename=libsecsignidC&secsignid=johndoe&authsessionstate=1&serviceaddress=localhost&requestid=134B0110289F76FE58A5449868187B99BB7FC59D8689A59EC809D50F6C1E234C&authsessionicondata=iVB...YC

Der Accesspass befindet sich unter authsessionicondata und kann im Falle von HTML direkt in das img Element eingebunden werden:

<img id="secsignid-accesspass-img" style="display: block;" src="data:;base64,iVB...YC=" alt="" />

Um zu erfahren, ob der Nutzer die Authentifizierungs-Sitzung bereits auf dem Smartphone akzeptiert oder abgelehnt hat, muss der Client den Status der Authentifizierung abfragen. Dies kann je nach Client in regelmäßigen Abständen (Polling) erfolgen, bis ein Statuscode geliefert wird, wo entsprechend reagiert werden kann (zum Beispiel bei Bestätigung des Logins kann der Nutzer eingeloggt werden).

ANFRAGE

Wie schon zuvor beim Starten der Authentifizierungs-Sitzung, muss der Client eine POST Anfrage zum SecSignID API Server stellen um in diesem Falle den Status abzufragen. Die zu übertragenden Parameter sind URL codiert.

Beispiel für die Anfrage des Sitzungs-Status:

request=ReqGetAuthSessionState&secsignid=johndoe&authsessionid=9162914906710510618&requestid=134B0110289F76FE58A5449868187B99BB7FC59D8689A59EC809D50F6C1E234C&apimethod=SecSignIDApi_PHP

ANTWORT

Die Antwort vom SecSignID Server enthält den Parameter „authsessionstate“, welcher den Status der Authentifizierungs-Sitzung beschreibt. Je nach Status kann entsprechend beim Client reagiert werden. Gilt der Status als bestätigt (3), kann der Nutzer eingeloggt werden. Wurde die Authentifizierung suspendiert (5) oder abgelehnt (4) kann der Nutzer zurück zum Login geführt werden. Wird noch auf die Bestätigung oder Abbruch gewartet (1) sollte der Status nach kurzer Zeit noch einmal abgefragt werden.

Beispiel für die Antwort zur Abfrage des Sitzungs-Status:

authsessionid=9162914906710510618&secsignid=johndoe&authsessionstate=3

Beispiel für die Antwort zur Abfrage des Sitzungs-Status, wenn der Nutzer die Authentifizierung abgelehnt hat:

message=You have denied the access pass.&authsessionid=9162914906710510618&authsessionstate=4

Eine Authentifizierung kann jederzeit abgebrochen werden, solange der Nutzer noch nicht den Login auf seinem Smartphone bestätigt hat. Eine Sitzung kann freigegeben werden, wenn der Nutzer korrekt angemeldet wurde und die Sitzungsinformationen nicht noch einmal vom Server abgerufen werden müssen.

REQUEST

Beispiel für den Abbruch der Authentifizierungs-Sitzungs:

request=ReqCancelAuthSessionState&secsignid=johndoe&authsessionid=9162914906710510618&requestid=134B0110289F76FE58A5449868187B99BB7FC59D8689A59EC809D50F6C1E234C

ANTWORT

Die Antwort des Servers enthält die ID der Sitzung, welche beendet wurde, sowie noch einmal den Status der Sitzung. Wird nach Freigabe oder Beendigung der Sitzung noch eine Statusanfrage gesendet, so wird ein Fehler zurück gesendet, da die Sitzung nicht mehr existiert.

Beispiel für die Antwort zur Freigabe der Sitzung nach erfolgreicher Authentifizierung:

authsessionid=9162914906710510618&authsessionstate=3

Es gibt zwei verschiedene Arten von Fehlermeldungen:

1. Technische Fehler können zum Beispiel durch fehlerhafte Syntax der Parameterlisten entstehen. Diese Fehlermeldungen werden mit einem HTTP Statuscode 400 zurückgegeben und enthalten einen HTML Nachrichtenrumpf, z.B.:

<h1>Bad Request HTTP/1.1 400</h1>
The server could not understand this request.
<p class="errormsg">bad parameter: Parameter is missing for request 'ReqReleaseAuthSession'.</p>

2. Kontextfehler können auftreten wenn es Probleme mit der Authentifizierung an sich gibt, das heißt wenn die angegebene SecSignID nicht existiert oder die Sitzung abgelaufen ist.

error=400&errormsg=No session could be found therefor the request could not be processed.&errorcode=10013 

Ein Nutzer kann sich nicht gleichzeitig bei mehreren Diensten mit seiner SecSignID authentifizieren ohne die vorherige zu bestätigen oder abzulehnen. Dieser Fall ist sicherheitsrelevant, denn so kann es nicht zu Verwechslungen oder versehentlich bestätigten Logins führen.

Werden zwei Login Sessions (mittels ReqRequestAuthSession) hintereinander angefragt, ohne dass der Nutzer die Authentifizierung auf seinem Smartphone bestätigt, werden alle Logins suspendiert und ein entsprechender Fehler kommt zurück.

Der Nutzer kann die Suspendierung aufheben, indem er auf seinem Smartphone seine SecSignID antippt.

Besteht das Problem weiterhin, wird auf dem Smartphone ein Priority Code angezeigt, welcher statt der SecSignID für ein Login genutzt werden kann. Wird der Login auf dem Smartphone bestätigt, liefert „ReqGetAuthSessionState“ die echte SecSignID des Nutzers zurück.

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.

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.