The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Single sign-on vs. passwords in-the-app

Our app, which uses VB6 ("soon" to be .NET) against a SQL Server database, has its own security system.

We keep getting RFPs that say they want O/S or network level authentication, not in-the-app like we do.  I'm wondering what kinds of experience you have about this issue.

What I see:

- For a user who has exclusive use of a workstation, this would be great.  User logs onto the domain when starting his/her computer and then starts the app.  The app somehow recognizes the user's right to use it and starts up accordingly without the user having to log in.

- For users who share an app on a shared workstation, I don't see how this would be a good model.  Wouldn't user A have to log off the network, which involves shutting down the app in order for user B to log onto the app?  This seems horribly cumbersome and slow.

- Is it possible to attach an application's security model into the network or O/S security model, or does the app have to read a user's permissions on the network and set its security accordingly?

Any guidance?  What other issues am I missing?
Karl Perry Send private email
Friday, May 05, 2006
If users are often using your app on a shared workstation (and I see this pretty rarely myself, but I know it happens a lot in some settings like hospitals), there is still a huge benefit to using integrated authentication WITHOUT single sign-on.  That is, you make each user log in to your app, but you authenticate, for example, against Active Directory.  This means that users only need to learn one password, and when they change their network password, their application password changes also.

You might want to use a configuration flag per machine; if it's a single-user machine, the app tries to do single sign-on, but if it's a shared machine, it makes you log in but used integrated authentication.

To answer your question about adding an app's security model into the network authentication, it depends on what kind of network there is, and how much control you have over the domain servers.  For example, Active Directory functions as an LDAP server. You can add new items to the LDAP schema if you want to (to add your security model to AD's).  But why would you?  Why not just authenticate against AD/LDAP?
Jacob Send private email
Friday, May 05, 2006
We're doing something similar to this.

Check out IPrinciple in msdn.
Clients will set up users & permissions in active directory.
They'll end up having to create user groups for the permissions your app uses, then they'll use the OS interface to add and remove users from those group permissions.
Friday, May 05, 2006
There are actually 3 models:

1) Active directory authentication. Logon to windows are you are authenticated on the network.

2) SQL Server authentication. Your app provides a logon dialog and uses that data to create its connection which allows the database roles to be applied.

3) Application authentication. The app connects with a master account to the database and manages what the user can and cannot do.
Friday, May 05, 2006
"That is, you make each user log in to your app, but you authenticate, for example, against Active Directory."

This is generally the most common and - from what I have seen - a reasonable balance of security vs ease of use.

You don't have to remember 15 passwords just to do your job BUT it's more difficult for someone to  come along behind you and muck things up.
KC Send private email
Friday, May 05, 2006
KC, that makes sense to me now.

It wouldn't matter who was logged on to the computer, because as soon as a user logged onto the application THEIR logon would be authenticated against AD.  Right?
Karl Perry Send private email
Friday, May 05, 2006
In .NET its very easy to get a .NET client app to automatically pass the credentials (of the currently logged on user) to a .NET app server.  You have to host the app server in IIS.  It's only about 10 lines of code in total.
John Rusk
Saturday, May 06, 2006
Another consideration is that with Impersonation the user can also be managed as to what resources they have available.

One application that I currently work on requires the user to logon, authenticates against the AD, and then uses Impersonation for database access so that user security within the database (insert/update/delete) can be set. My recommendation would be to put the users into groups based on what role they have if you want integrated security at the database.

Email me if you are interested in a C# dll to do Active Directory management. I even NDOC'ed it!
Jeremy Send private email
Wednesday, May 31, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz