Single Sign On
User identity verification, or authentication belongs to basic task of each of intranet. According to user identity we can permit, or forbid relevant actions like display sensitive data, transaction in database etc. Control of user access rights to directories and files for single user on level of system administrator is for intranet application unsuitable and complicated.
More flexible solution is to create list of required roles (according to character of application) and to test whether user requesting the page has assigned required role. List of users and their roles is saved in table and according to identity of actual user we can test any time whether actual user has permission to do required activities. Administration of such a table is very simple and transparent.
To verify user identity you may use IP address of actual user (easy to imitate), or rap out login form on poor user. It prooved to me to use integrated login (Single Sign On) which exploit login to domain at start up PC.
Remind of, that it is possible to use Single Sign On only in intranet, more precisely in the net, where web server and clients are running in same domain and clients have valid accounts in this domain and clients are regulary logged to this domain. It is impossible to use SSO in Internet.
Now let's go into promised Single Sign On. Configuration is done on web server, not on client. Start up IIS console, and go to desired directory or file, to which you want to set up security and select Properties in context menu.
Now select Directory Security tab, here in part Anonymous access and autentication control click on button Edit and next window opens: Autentication Method. Here must be checked only one single item Integrated Windows autentication. Older systems call this item as NTLM, or Chalenge Response.
At this way of autentication server requires user account name (for user who requests the page in that directory). Only encrypted user account name is sent over network, not user password. Because at request of secured page communication between server and client is done in several additional steps, response time is always slower, than request for pages which have granted anonymous access. Therefore use secured setup only for that directories, or single files (scripts), where it is really necessary to autenticate user.
For testing of Single Sign On function you can use following subroutine, which is placed on intranet server into secured directory and request this script from different PC. Routine writes out all server variables. In variable LOGON_USER you can find the account name of PC from which routine is called. If there is IP address in that variable, setting of security is not correct. If calling ends up with error 401.1, probably this PC is not correctly logged in to domain. Script is written in ASP.Clasic.
<html>
<head>
<title>List Server Variables<title>
<meta http-equiv="Expires" content="0">
</head>
<body>
<p>UserName: <%= Request.ServerVariables("LOGON_USER") %> </p>
<table><th colsp="2">ServerVariables</th><tr>
<%
For Each var in Request.ServerVariables
Response.Write "<tr><td>" & var & ":</td>"
Response.Write "<td>" & Request.ServerVariables(var) & "</td></tr>"
Next
%>
</table>
</body>
</body>
</html>
Next code is example of testing user role. This is server script written in VBScript. Each part of application may require explicit user role to execute specific action. For example when edit record in database script requires user role edit. Function Autentic("edit") returns empty string if user requesting this page has not granted corresponding role. If the user has granted this role, function returns the name of user account. According to returned value server script can ignore / execute database update, or hide / display form, data table etc.
Database table (PCuser) contains list of users, and their roles. One user may have assigned more roles (separated by comma). If your application is working with sensitive data, then all users should be listed in table with role e.g. view. All other users without record in table can be redirected to some harmless page (with Anonymous Access setup). In case of general data, passive user does not have to be listed in the table. We set up e.g. Edit directory as secured and only in scripts situated here we test user autentication. Home directory of this application can have Anonymous Access set up than.
FUNCTION Autentic(ByVal reqRole)
' === LOGON_USER is user account name. Find dedicated
' === role in database and compare with requested role.
Dim dbRole, userName
Autentic = ""
reqRole = UCase(reqRole) ' === convert to uppercase letters
userName = UCase(Request.ServerVariables("LOGON_USER"))
userName = Mid(userName, InStrRev(userName, "\")+1)
' === user account name only (remove domain name and slash)
If userName <> "" Then
query = "SELECT * FROM PCuser WHERE name='" & userName & "'"
Set Rf = Conn.Execute(query)
If Not Rf.BOF Then
dbRole = UCase(Rf("role"))
If (InStr(dbRole, reqRole) < 0) Then
Autentic = userName
End If
End If
Rf.close
End If
END FUNCTION
How acts individual browsers in that MS technology. Seamless integration in IE is fact. FireFox supports SSO, but at first access to secured page, FF will display log in form. It is possible to set up FF browser, so that behave the same way as IE. To the address line of FF write about:config, than find item ..ntlm.. and fill in that according to following picture. intranet is the name of your intranet server, localhost is used only on developer FF browser.
Opera browser, since version 9 already supports user autentication, but after each browser start up and the first access to secured page it is necessary to fill in log in form. Then until Opera is shut down, SSO is running without problem. This is not true Single Sign On however. User ought to enter his password only at system start, at the time when his spyware is inactive yet.
updated 05.11.2006