Single Sign-on with Windows Authentication

Our office uses primarily Windows based desktops and Active Directory. Each person must “authenticate” when they sign into their desktop. With the plethora of web apps and other services…people would have to Authenticate a hundred times a day. Regardless about what you think of the security model… our people want to sign-on and be granted access to all the web-apps and services without having to authenticate each time. My office is good with that, except that some of our applications need to record who is making the requests. The Windows domain and username fields are “available” somehow to the browser (not all browsers, notably IE and Chrome). We have some .NET apps that access this information…if it’s not available…the Browser automatically requests authentication. Ive seen this happen in Safari from my Mac. I try to open a .NET WebApp and Safari says HEY! I need your domain/username/password info…then it’s able to pass this info to the requesting WebApp (Which stores the user name in session state). Can XOJO access these “properties” so that any Web App session launched from a compatible browser can get the user info?

You can get the user name, but I doubt there is any way to get the password.

Seems from links at http://social.msdn.microsoft.com/Search/en-US?query=user%20authentification&emptyWatermark=true&ac=5
this kind of centralized authentification requires an authority.

This is more likely a function of how IE and .Net apps interact and seems to also require IIS
Hence why it doesn’t’ work with Safari & Chrome but does with IE

I wouldn’t expect I could get the password…and I don’t need it. I built a perl script on my Linux host that can call Active Directory with credentials and Parse the result. I don’t actually need a password at all in fact…just their SAML. The SAML would allow me to go grab everything I need to know about that AD user…the password just allows me to confirm that the person is who they say they are. I just didn’t want to prompt the user for their SAML (and take a chance they could make a typo) if I could “fetch” it from their Windows sign-on credentials. (Both IE and Chrome support this) - Safari and Firefox do not. Assuming all my users are accessing the Web Application with IE or Chrome…I wondered if I can get their username (SAML) so I know who the heck they are. These are internal tools…so it’s not like I’m concerned with people purposefully trying to obfuscate their credentials. If I know their system DNS name that would be sufficient as well. An IP address…is not helpful since we use DHCP. I hadn’t really considered that IIS was so involved… but I suppose that’s a real possibility. Maybe I could write a stub app on IIS that performs the sign-on logic and then passes the SAML as either a Hashtag or part of the URL to the Linux hosted XOJO WebApp. I’ll look at Michael’s MSDN link. If I can in fact grab the username…that’s enough for me.

What’s the goal? Make the Xojo app auto-identify a user using IE? Or make a Xojo app auto-identify someone using any browser?

The latter is not possible technically. IE understands how to respond to NTLM challenge requests. Firefox can be configured to do so but its not automatic. It becomes a per-browser challenge.

A Xojo web app could probably handle the NTLM challenge/response part for IE users. It would be easier just to build a ASP.NET app that does nothing but identify users and pass a token or something to the Xojo web app.

You could also get creative by setting a cookie after a user does sign in so they don’t have to continue signing in. Then you can query the LDAP server to verify they do in fact exist.

http://msdn.microsoft.com/en-us/library/azure/dn195589.aspx

The XOJO application facilitates moving data between two servers. It presents “source and destination” panes. For “cleanup” purposes I want to place a small file at the destination location with the creator’s info. The date, username, email address, etc.
I don’t want to require users to sign on all the time…perhaps a cookie is a reasonable solution. I thought that if XOJO could somehow capture the user information from the browser, that would be great. I know how to use our Active Directory authentication…I just don’t want the user to have to enter it again and again. This isn’t an application that requires a high level of security. The goal is to know who created these destination files so that when we run an automated cleanup pre-check we could send an email to the creator and say “Hey! Your stuff is gonna be deleted off the server if you don’t do something with it”. It just so happens that all of my users are using IE. Perhaps a Cookie is the best plan. I can ask them “once” who they are… fetch their info from Active directory and store the username and email in a cookie. They would only be re-prompted if/when they delete the cookie. This would extend support to ALL browsers.

[quote=130483:@Robert Bednar]The XOJO application facilitates moving data between two servers. It presents “source and destination” panes. For “cleanup” purposes I want to place a small file at the destination location with the creator’s info. The date, username, email address, etc.
I don’t want to require users to sign on all the time…perhaps a cookie is a reasonable solution. I thought that if XOJO could somehow capture the user information from the browser, that would be great. I know how to use our Active Directory authentication…I just don’t want the user to have to enter it again and again. This isn’t an application that requires a high level of security. The goal is to know who created these destination files so that when we run an automated cleanup pre-check we could send an email to the creator and say “Hey! Your stuff is gonna be deleted off the server if you don’t do something with it”. It just so happens that all of my users are using IE. Perhaps a Cookie is the best plan. I can ask them “once” who they are… fetch their info from Active directory and store the username and email in a cookie. They would only be re-prompted if/when they delete the cookie. This would extend support to ALL browsers.[/quote]

If all you need is a reference to the current user, maybe you could use shell %username%

Shell runs on the server, not on the client, so you’d be g toting the wrong user.

I’m curious how the Perl script does this though. Maybe you could figure out what your app needs to do from that. For instance, it’s possible that you’d be able to access this info from an Environment variable when the Session first starts up.

[quote=130620:@Greg O’Lone]Shell runs on the server, not on the client, so you’d be g toting the wrong user.

I’m curious how the Perl script does this though. Maybe you could figure out what your app needs to do from that. For instance, it’s possible that you’d be able to access this info from an Environment variable when the Session first starts up.[/quote]

Maybe he could get the Perl script to tell his app through specialurl ?

Still the same problem. It’s the browser that would need to access the Perl script to send the right credentials. If you called it from the web app, you’d get the Fred’s for the server.

Thanks for your thoughts on this. I really appreciate the brainstorming. Everything here is spot-on my problem. The shell username would indeed either come back as “apache” or "whatever user started the web app (if stand alone) – on the server. Therein lies my problem…using the web app…there’s no way for the server to know who is making the request…unless I prompt them for credentials…and that means asking them every time they fire up a new session…unless I store some info in a Cookie. My users are growing weary of typing in their credentials a hundred times a day… so they have been pushing for “single sign-on”. We are starting to get there with our .NET apps hosted by IIS. There are good cases for hosting some apps on Linux servers. I tried .NET under Mono with some success. A XOJO solution was another possibility which I ultimately employed to success. The Perl script on the server does exactly the same thing I could do in XOJO code really… somehow…though…you have pass it credentials from somewhere. Each of our workstations has a “computer name”. From other LInux connections (telnet) I compiled “whoamip” which I’ve found will return the system name like “bobsworkstation@mycompany.com”. I know that WebServers have access to a few browser parameters like “Browser Version” and “Guest OS”. I wasn’t sure if “username” wasn’t tucked away somewhere. It sounds like an WebApp hosted by IIS can “request” your domain credentials. I wondered if that same request can be made programmatically by XOJO. Many people shy away from “Cookies” because the users can reject them. We have severals apps that require them…so they have to be enabled. Again I’m not really too concerned about “security” – its just a matter of trying to help provide details of “who owns what”.

The cookie approach seems like a winner. Credentials are never very long, so you could store an encrypted user name.

You must not do a session cookie which would be destroyed too often. Just make sure to set it up so it does not survive forever, so users still have to log in at least once a day.

Did you find a solution to make SSO?

It is years ago since I did this and at this stage all I remember is the concept…

In short, there was a way to have the server add a custom variable to the request containing the authenticated user details. This could then be read by the web application.

I’ve chalked this problem up to “great unresolved issues of my universe”. I do appreciate all the suggestions. I’m wondering now if I could just investigate the connection to a stand alone web application. It must know where the connection came from. IP or DNS system name. I’ll find out what the session sees during launch.