Single Sign On
Web server, which generates HTML pages for Web application often needs to know the identity of the user who requested the Web page. According to that identity, list of ordered goods in eshop is displayed, list of mail for that user is selected, and outside users are prevent to read your mails. To determine the identity of the user, login form is used often.
Inside of corporate network, on intranet, you can utilize the fact that the user is logged on to the corporate network at system startup. Then the Web server in conjunction with the domain server can determine the identity of the user who is requesting the intranet page. Log in form can be omitted then. Such a procedure is called Single Sign On. Users can work on the intranet in an easier, more comfortable and faster way.
Note that the Single Sign On can only be used on intranet, precisely in network where the Web server and clients are running in the same domain, clients have a valid account in the domain and are logged in under this account. Windows network is o.k. for SSO running and testing. In any case you can not use SSO on the Internet.
IP address of the device also can be used to obtain the identity (be afraid of IP fraud and DHCP change IP). Or system administrator can set permitions for various user to directories and files of Web server to control users activity. Much more flexible solution is to create a list of users and their associated roles. Then the web server script, when generates the page, tests the current user's role, if can display sensitive data or if can allow to edit record in database. Managing such a table with the login names of users and their roles is very simple and clear.
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 displays 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, not listed in table, can be redirected to some harmless page (with Anonymous Access setup).
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
When intranet user first requests the page that requires user authentication with SSO, he is asked to fill in the login form. Use the same name and password as when boot system. Next requests of secured pages on intranet server are authenticated automatically. After a long stop of using the intranet, it is sometimes necessary to resend the login form.
How acts individual browsers in that MS technology. Seamless integration in IE is the fact, detail setting of IE can be found here. FireFox supports SSO, but it is recommend to set the name of intranet server into browser configuration. Type in about:config into address line, 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. Chrome browser does not requires any specific setting to run SSO.
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 login 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.
Problems can cause policy which is set to automatic time expiration of the password. When the PC is running in continual operation 24x7 and the prompt to change the password is ignored, then SSO stops working silently.