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.

System.Net.WebRequest request = System.Net.WebRequest.Create(this.secSignIDServer + ":" + this.secSignIDServerPort);
request.Method = "POST";
request.ContentType = "application/x-www-form-urlencoded";
request.ContentLength = requestData.Length;

// send data
System.IO.Stream requestStream = request.GetRequestStream();
requestStream.Write(requestData, 0, requestData.Length);
requestStream.Close();

//Die Antwort des Servers liegt ebenfalls im URL-kodierten Format vor:
// get response
System.Net.WebResponse response = request.GetResponse();

// get data from response
System.IO.Stream responseStream = response.GetResponseStream();
System.IO.StreamReader reader = new StreamReader(responseStream);
string responseString = reader.ReadToEnd();

Dictionary responseDict = new Dictionary();
string[] responseValues = responseString.Split('&');
foreach(string value in responseValues)
{
if(value != null && !value.Equals(""))
{
string[] valuePair = value.Split('=');
responseDict.Add(valuePair[0], valuePair[1]);
}
}

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.

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.

[form runat='server' id='LoginForm']
		SecSign ID: [input id='secsignid' name='secsignid' type='text' size='30' maxlength='30' runat='server' /]
		[asp:button name='login' id='login' type='submit' value='1' runat='server' Text='Login'  PostBackUrl="~/SecSignID.aspx"/]
[/form]

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.

Eine AuthSession kann mehrere Zustände haben:

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:

protected void Page_Load(object sender, EventArgs e)
{
	if(Page.IsPostBack)
	{
		// form was sent back to server.
		if (!string.IsNullOrEmpty(form["checkauthsession"]))
		{
			int authSessionState = AuthSession.NOSTATE;
			try
			{
				NameValueCollection form = Request.Form; // get form which has send the request

AuthSession authSession = new AuthSession(form["secsignid"],
form["authsessionid"],
form["requestid"], null,null, null);

SecSignIDAPI secSignIDAPI = new SecSignIDAPI();

// check authsession state
authSessionState = secSignIDAPI.GetAuthSessionState(authSession);

if(authSessionState == AuthSession.ACCEPTED){
Response.Redirect("Intern.aspx?secsignid=" + authSession.GetSecSignID());
}
else if(authSessionState == AuthSession.PENDING || authSessionState == AuthSession.FETCHED){
this.lblMessage.Text = "the auth session is still pending... it has neither be accepted nor denied.";
}
else
{
if(authSessionState == AuthSession.DENIED){
Response.Write("You have denied the auth session...");
}

// render previous page
if(PreviousPage != null){
Response.Redirect(PreviousPage.AppRelativeVirtualPath);
} else {
Response.Redirect("Default.aspx");
}
}
}
catch(System.Exception ex)
{
handleError(ex, false);
}
}
}
}

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.

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

protected void Page_Load(object sender, EventArgs e)
{
	if(Page.IsPostBack)
	{
		// get post data and decide whether go back when cancel has been clicked or to check authsession
		NameValueCollection form = Request.Form;
		if (!string.IsNullOrEmpty(form["cancelauthsession"]))
		{
			try
			{
				NameValueCollection form = Request.Form; // get form which has send the request
				AuthSession authSession = new AuthSession(form["secsignid"], form["authsessionid"], form["requestid"], null, null, null);
				SecSignIDAPI secSignIDAPI = new SecSignIDAPI();
				// cancel auth session
				secSignIDAPI.CancelAuthSession(authSession);
				// render previous page
				if(PreviousPage != null){
					Response.Redirect(PreviousPage.AppRelativeVirtualPath);
				} else {
					Response.Redirect("Default.aspx");
				}
			}
			catch(System.Exception ex)
			{
				handleError(ex, false);
			}
		}
	}
}

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:

Public Function requestAuthSession() As SecSignID.AuthSession
	Dim secsignString As String = "leonie"
	Dim serviceName As String = "VB.NET example";
	Dim serviceUrl As String = "localhost"
	// request authentication session
	Dim authSession as SecSignID.AuthSession
	Dim objSecSignID As SecSignID.SecSignIDAPI
	Set objSecSignID = New SecSignID.SecSignIDAPI
	authSession = objSecSignID.RequestAuthSession(secsignidString, serviceName, serviceUrl)
   Return authSession;
End Function

oder statt:

Dim objSecSignID As SecSignID.SecSignIDAPI
Set objSecSignID = New SecSignID.SecSignIDAPI

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

Dim objSecSignID As SecSignID.SecSignIDAPI
Set objSecSignID = CreateObject("SecSignID.SecSignIDAPI")

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.