Single Sign On

[benjeeqds]

Hey All,

I’ve written a VB.NET client & server application where the client application calls a function on the server and gets results back.

The application runs in an intranet.

How can the server tell who (as in the NT domain user?) the client is before executing a request WITHOUT prompting the user for their password?

(The users hate entering passwords, and I don’t blame them)

Obviously I can’t allow the client to ‘spoof’ their name (i.e., it can not just say “I am domain\bob”, it has to prove it.)

I have a nasty solution which works (shown below), but surely there is an API or something for this?

I can’t use IIS Windows Authentication, as this is a VB .NET client app talking to a VB .NET server app.

Hopefully somebody can shed some light?

Cheers,
Ben


PS: I have a nasty approach, which follows:


Step 1: Client application creates login request (“hello I want to log in as domain\ben”) and saves into \\server\sso$\request\ben.xml.

Step 2: Server application detects new file (ben.xml) in \\server\request\sso$ directory

Step 3: Server application creates a file called \\server\sso$\response\ben.xml and sets NTFS security permissions on so only "domain\ben" can read the file

Step 4: Server checks permissions on the file are set correctly – if not then it kills itself and refuses accept any connections (This handles cases where the system is running on FAT32 file systems with no permissions).

Step 5: Server saves a magic word (eg ‘abracadabra’) into the file \\server\sso$\response\ben.xml

Step 6: Client application reads the file \\server\sso$\response\ben.xml and gets the magic word ‘abracadabra’ (remember, only ‘domain\ben’ can read this file due to NTFS security set in step 3)

Step 7: Client sends work request via normal TCP connection, and includes work request, user name and the magic word (client says “Attention! Do function xyz with paramaters abc, I am domain\ben, my magic word is ‘abracadabra’)

Step 8: Server does the work and returns results to ‘domain\ben’ via TCP, then kills the connection and banishes the magic word. Next round of communications go back to step 1.

(Obviously my ‘magic word’ is a 256bit long random string, not a silly word)



----------- the solution I crafted above makes me cringe and shudder ------------

 

[cyclone21]

I have been thinking about doing something similar. I have a windows forms front end that accesses a web service for data etc and right now the windows forms app prompts the user for their username and password then encrypts that and sends it to the web service to be authenticated against ldap. Working in an IT department though i know how often users forget their passwords and/or lock themselves out so what i would like is to, on the client side, read an account token from windows, then pass that back to the web service to authenticate the user.

Not sure how to read the account token on the client side but it occurs to me that i could just encrypt the user name and pass that back to the web service.

 

[Herman]

If this is defense, they should have no problem budget-wise setting a up a Terminal Services RemoteApp server for your application. Don't distribute the application, force users to authenticate to a remote server that hosts the application. They will never even have the chance to copy the app anywhere nor will they ever have access to the database or other resources the app needs. If the user is already authenticated to the network and has permissions to log on to the server it won't even ask for a password.