Communication with the ID-authentication server, in short ID-server, takes place through the class ‘System.Net.WebRequest’. With this request URL-coded lists of parameters are sent to the ID-server.

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();

//The reply of the server is also present in URL-coded format:
// 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]);
}
}

On the public ID-server only this communication type is used. The SecSign Routing server, which is installed in front of the public server, prevents any other requests. With an on-premise installation, however, other ways of communication like, for example, web service and SOAP are possible.

The project ‘WebExample’ consists of a ‘Default.aspx‘ behind which a simple website with HTML-form is hidden. The form has primarily only one text field where the SecSign ID can be entered. (In the example a validator – type: RegularExpressionValidator – is indicated additionally in order to verify the SecSign ID before it is sent to the server. However, the details will not be discussed at this point). Because of problems integrating html-snippets the opening and closing tag-characters are replaced by brackets.

[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]

After an authentication session for the transferred SecSign ID could be requested from the ID-server, the returned object (type: ‘SecSignID.AuthSession’) has the following values:

authSession.GetSecSignID() : the SecSign ID sent to the ID-Server

authSession.GetAuthSessionID() : the ID requested by the authentication session

authSession.GetRequestID() : the request ID, which is forwarded with all following requests

authSession.GetRequestingService() : the service name sent to the ID-Server

authSession.GetRequestingServiceAddress() : the service URL sent to the ID-Server

authSession.GetIconData() : the access pass as base-64 encoded PNG-picture data

The so-called access symbol, the base64-encoded PNG graphic, must be shown to the user who wants to log in. The same graphic is sent from the ID-server to the user´s smartphone on which the user accepts the authentication after comparison of the graphic.

Also, the other values of the AuthSession should be stored as they will be partly needed later on, for example to request the state of the AuthSession on the ID-server (e.g. whether the user has already accepted the AuthSession or not).

In the example the data from the AuthSession object are stored in hidden HTML fields. It is also possible to store them in a temporary session on the web server or in a database. In the example the data are stored on the ASP.NET-site ‘SecSignID.aspx’ as any post of a form is sent to this page until the end of the login.

An AuthSession can have different states:

For requesting the status of the AuthSession you use the method ‘GetAuthSessionState’. For this SecSign ID, request ID and AuthSession ID must be sent to the ID-server.

In the example this verification takes again place on the ASP.NET-site ‘SecSignID.aspx’, as the button of the above form sends the form data to this site:

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 the above example you can see the reaction to the AuthSession status which was sent by the ID-server: If the status is ‘PENDING’ or ‘FETCHED’ (as soon as the user has started the confirmation process on the smartphone, the session status on the ID-server will switch from ‘PENDING’ to ‘FETCHED’. Only if the user then selects the correct access symbol on the smartphone, the status will change again.), the user has neither accepted nor rejected the session, respectively AuthSession.

In the example the user is notified and the access symbol is still shown to the user. If the status is, for example, ‘DENIED’ or ‘CANCELED‘, the login process has either been canceled or the user has rejected the access symbol on the smartphone. In this case there will be an automatic return to the homepage. If you integrate the ASP.NET API into your own project, you will be able to decide how to handle this internally and if you, for example, show specific pages or record this. This means for the login procedure that the user is not logged in on the website. If the AuthSession status is ‘ACCEPTED’, the user has accepted the access symbol and thus the session on the smartphone. The AuthSession gets this status only if the user has selected the correct access symbol on the smartphone after comparing the four symbols on the smartphone with the symbol on the website. In the example an ASP.NET-site ‘Intern.aspx’ is shown.

For the login this means that the user authentication was successful. Depending on the present system or CMS the CMS user can be found out through the SecSign ID and can be logged into the system. Thus, if you integrate the ASP.NET API into your project, the following might happen: If you have a CMS system with an own user administration in which one SecSign ID is assigned to each user, the CMS user for the SecSign ID might be requested now and will be afterwards logged into CMS. Depending on the CMS this is done with session cookies like, for example, for WordPress or Joomla, or by the storage of registered users in a database. Thus, in your project (where the AuthSession status is ‘ACCEPTED’) a defined user can be registered by you, or a status can be defined.

Depending on the project, this way actions can be started as well, depending on whether the user has the required rights. Thus, SecSign ID API does not only provide you with a two-factor authentication but also with the option that in a complex system the start of services or, more generally, any action depends on another user confirmation. The user who wants to start a service authenticates with the SecSign ID and the smartphone so that the system can use this to verify, if the user has the required rights, and can afterwards perform the action. The authentication, thus, initiates the start of services.

On client side the AuthSession can be canceled with the method ‘CancelAuthSession’ Please see again the example of ‘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);
			}
		}
	}
}

With the SecSign ID ASP.NET plugin a two-factor authentication can be easily realized for ASP.NET-sites. Of course, it is also possible to have a two-step authentication for a web service by operating the SecSign ID either in before or after it.

The exact difference between two-factor authentication and two-step authentication is subject of this blog post. However, the API is not specifically written for ASP.NET, but in C#. By this, it is possible to integrate API and two-factor authentication into any project which is based on the NET Framework. As all required methods are available in C#-API (also for the communication with the ID-server) you only have to integrate the API ‘SecSignIDAPI.cs’. Also, it is possible to, for example, integrate the compiled C#-library into VB.NET-projects. Examples how to integrate libraries using a different language can be found, for example, on Microsofts howto. In order to use the C#-class in VB.NET you only have to add it in Visual Studio as reference to the VB.NET-project. The SecSign ID C# API is compiled ‘CLS compliant’.

Minimum requirement is .NET (respectively Mono) Version 3.5 so that the library can also be used in projects using .NET Framework 4.0 or 4.5. In order to use the integrated .NET Dll you can either use the key word ‘new’ or generate a new instance through ‘CreateObject’:

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

Or, instead of using

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

you could use (as mentioned above) the ‘CreateObject’-Notation:

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

We provide an ever growing list of APIs and plugins to easily integrate the SecSign ID Two-Factor Authentication in any project. An overview is available at Plugin and APIs.
We do not only offer APIs in different programming languages but also plugins for CMS, Server and VPN environments, oAuth2 and many more. These plugins use our APIs and offer additional functionalities, for example user management, easy and native installation, logging or integration in firewalls or Active Directory.

The JIRA plugin for example uses the JAVA-API. The PHP-Api and JS-API is used by WordPress, Joomla, Drupal, Typo3 and many more. The ASP.net/C#-API is used for the Windows and Cisco VPN and the C-API is used for protecting Unix SSH services. The Objective-C API is used by our AppleTV and iPhone/iPad apps.

You can experience the SecSign ID two-factor authentication and the two-factor login by simply integrating the plugin into your website or test environment. Or you can try out the login process on our website without having to register first. You already have a SecSign ID or you want one? Login now and use the portal or use our hassle free registration.

See for yourself how fast and convenient the login process using challenge-response authentication with 2048-bit key pairs is. There is no need for passwords, and no passwords or other confidential information are ever transmitted. It is easy to integrate and simple to use.

For more information about the patented SafeKey procedure and it's unique security can be found here.

If you are missing an API for the programming language you are working with, feel free to contact us and we’ll find a solution with you. If you need help with the integration into an existing system or you can’t find the plugin for your content management system you are working with, don’t hesitate to contact our support team.