Complex AD scenario RRS feed

  • Question


    Hello everyone,


    I am in a huge health project, we could have thousands concurrent users. A person can be a Doctor in one center and an administrative in another, so roles change with location. The app will be implemented with and framework 3.5.


    Nowadays AD tree represents the physical hierarchy of medical centers, so we could expand it this way:


    Medical Center 1

    Role 1


    Role 2


    Medical Center 2

    Role 1


    Role 2



    We could add AD users to those groups.


    Well, that is the theory, but we have lots of doubts:

    • Is possible to represent this with AD? Roles MUST be the same for each location, we are in a SOA scenario, so services will be shared between different applications and we need a shared set of roles.
    • It would have a good performance?
    • I need just the Medical Center´s roles where the person is, how we could do this with Any example of how to select just the groups of one arm in AD?
    • Perhaps we should go for a custom DDBB solution?


    Thanks in advance

    Thursday, February 14, 2008 9:26 AM


  • I'm not hugely knowledgeable of the ins and outs of AD, but I can give you some feedback generally on the question.


    I would say that it may be acceptible to do what you're saying, however, if you have so many questions, you would have to be careful that the whole system isn't based around a technology such as AD.  If AD isn't a fit for some feature in the future, then you're stuck, whereas if you can decouple everything you're more likely to be able to adapt the solution.


    It seems to me that you're trying to adapt a technology to use it for the purposes of role and group membership?  Have you looked at AzMan?  It does the same thing, but offers a level of isolation between the two tasks?  It has operations that a role can perform, and users are members of roles, in a nutshell at least.


    Personally I would straight away steer clear of putting all your eggs in one basket, unless there's a way to move those eggs to another basket.  I'm not saying that it won't work, just that software requirements evolve over time, and it's good to be able to have an architecture that supports that growth rather than stopping it?


    I'm sorry that I can't answer your question directly, but I thought I'd pose some questions for you to consider in terms of alternatives?


    Good luck,


    Martin Platt.

    Thursday, February 14, 2008 10:54 PM