Single Sign On

[GonzoRock]

I seem to be completely confused over how to achieve a Single Sign On for Coldfusion apps that previously used the classic username password form to get started. This is a company Intranet Application. Let me explain.

The assumption is that some user has logged in to his company network on any random Windows computer and then opens the Intranet App in a browser of his choice. The Coldfusion App checks to see wether the users USERNAME exists in the Active Directory Structure ... and then using the USERNAME will open the App with the proper security restrictions that the App database has associated with that USERNAME.

This is my problem... at the moment: How does the client side let the App know what the UserName is? cgi.Remote_User is always empty... as is cgi.Auth_User.

Clearly I'm missing something in my assumption about Single Sign On. Anything you all might be able to offer is readily consumed and greatly appreciated. I've googled my fingers raw for days reading everything I can find... so it must be my mind that's failing me #Sad

[Dave Watts]

For this to work, you need two things. First, all computers involved must be within the same authentication mechanism. Typically, this is a Windows domain. Second, the web server has to be configured to require the user's Windows credentials, and the user has to be using a browser that is configured to automatically send those credentials. None of this really has to do with CF, actually.

In IIS, you'd need to enable Windows authentication for the files in question. This can either use NTLM or Kerberos authentication, and can actually be configured to use both (Kerberos as a primary, and NTLM as a fallback). You'll also need to disable anonymous authentication, which is enabled by default. On the user's machine, the browser he or she uses must be configured to automatically send NTLM or Kerberos authentication credentials. IE does this automatically. I think Chrome does too, actually. Firefox must be configured to do this. I can provide information on that if you want it.

Once this is configured, the web server will send back a challenge, and the browser will send a response containing the username and a hash of the password in the case of NTLM, or a Kerberos ticket in the case of Kerberos. There's actually a lot more going on with Kerberos that I'll omit here, as this is all we really need to know for now. In either case, the web server will forward the information to your Active Directory server, which will validate it. If it's validated, you'll get a value for CGI.AUTH_USER and/or CGI.REMOTE_USER, I forget which. You won't receive the password, because the password is never actually sent from one machine to another.

Dave Watts, CTO, Fig Leaf Software

[GonzoRock]

Yes indeed Dave. My failure was not understanding Domains and Active Directory. Our entire development lab is set up as a bunch of servers and computers all on the same network... but running as a WorkGroup... not a Domain. We've survived years developing doing that.  Diving deep into domains and how all that works now. Thank you for jumping in... again 😉

[Animesh_Dutta]

It is an interesting topic. Most of the cases, if we want to do Single Sign On among different applications, we can even use cookie scope values for that.

Thanks,

Animesh Dutta