As a small in-house dev department, we only have experience with developing applications for our intranet. We use the existing Active Directory for user account management. It contains the accounts of all company employees and many (but not all) of the business partners we have a cooperation with.

Now, the top management wants a technology exchange application, and I am the lead dev on the new project. Basically, it is a database containing our know-how, with a web frontend. Our employees, our cooperating business partners, and people who wish to become our cooperating business partners should have access to it and see what technologies we have, so they can trade for them with the department which owns them. The technologies are not patented, but very valuable to competitors, so the department bosses are paranoid about somebody unauthorized gaining access to their technology description. This constraint necessitates a nightmarishly complicated multi-dimensional RBAC-hybrid model.

As the Active Directory doesn't even contain all the information needed to infer the roles I use, I will have to manage roles plus per-technology per-user granted access exceptions within my system. The current plan is to use Active Directory for authentication. This will result in a multi-hour registration process for our business partners where the database owner has to manually create logins in our Active Directory and send them credentials.

If I manage the logins in my own system, we could improve the usability a lot, for example by letting people have an active (but unprivileged) account as soon as they register. It seems to me that, after I am having a users table in the DB anyway (and managing ugly details like storing historical user IDs so that recycled user IDs within the Active Directory don't unexpectedly get rights to view someone's technologies), the additional complexity from implementing authentication functionality will be minimal. Therefore, I am starting to lean towards doing my own user login management and forgetting the AD altogether.

On the other hand, I see some reasons to stay with Active Directory. First, the conventional wisdom I have heard from experienced programmers is to not do your own user management if you can avoid it. Second, we have code I can reuse for connection to the active directory, while I would have to code the authentication if done in-system (and my boss has clearly stated that getting the project delivered on time has much higher priority than delivering a system with high usability). Third, I am not a very experienced developer (this is my first lead position) and have never done user management before, so I am afraid that I am overlooking some important reasons to use the AD, or that I am underestimating the amount of work left to do my own authentication.

I would like to know if there are more reasons to go with the AD authentication mechanism. Specifically, if I want to do my own authentication, what would I have to implement besides a secure connection for the login screen (which I would need anyway even if I am only transporting the pw to the AD), lookup of a password hash and a mechanism for password recovery (which will probably include manual identity verification, so no need for complex mTAN-like solutions)? And, if you have experience with such security-critical systems, which one would you use and why?

Update When I wrote the question, I had been told by my boss that I will get read-only access to the Active Directory, and that all users of my system would have follow internal procedures for managing accounts (such as showing a picture ID to our secretary to reset a forgotten password). I wouldn't have had the possibility to create my own groups. But after explaining the situation to my boss and to the AD administrator, I got permission to save my users' accounts in a separate OU and manage them as I see fit. So now I can use Active Directory and still offer an acceptable user experience. Still, if you have an answer which addresses my question under the old constraints, please write it down, I would be interested to hear more about it even if my interest is only academic now.

  • 1
    Active Directory is quite flexible, I expect you can add all needed information. "As the Active Directory doesn't even contain all the information needed to infer the roles I use" So that point should be fixable not very difficult. – Luc Franken Dec 14 '12 at 12:37
  • AD Groups are easy to create and take care of Roles. This is a no-brainer, use AD. – Walter Dec 14 '12 at 12:51

I would recommend you use an AD based approach, and enhance your existing AD environment to provide the groups / roles that you need to support your application.

One element you haven't discussed in your question is Auditing. How are you going to verify that you have all the correct roles and rules and blah blah blah that your paranoid process owner is demanding? (n.b. paranoia isn't always a bad thing)

AD has a large set of tools already built around it in order to simplify the registration process, handling auditing, and quick account deactivation. Can your development team provide all of that functionality? Is there any real value in your team building that functionality? That's why AD is the more attractive option of the two.

User management is a big realm, and it's not core to your business. Those are excellent reasons to use a 3rd party tool (AD in this case) to simplify your development tasks. Scheduling and delivery concerns simply add more weight to this argument.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.