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.

Access control.

We have a server and clients speak to it using a custom protocol..  First thing they need to is login, and the server then knows what they can and can-not do.

The actual business logic is in classes that are called by the protocol layer.  This has easily allowed to us to bolt on a web (services) interface - so we did something right.

Currently to check if a user has the rights to do something, we do the check in our protocol hander before making the API call.  This means that the actual business logic has very little knowledge of who's calling what - for better or for worse.  But so far with only one interface into the business logic it hasn't been a problem.

Now that we are adding a web interface, we now need to do the access checks in our custom protocol layer, as well as the web interface layer.

Design wise, would it make sense to move the access control checks into the actual business layer?  This would mean passing a user object into the business layer which is not an issue.

The one advantage I see is that when/if we add yet another interface into the server, we don't have to rewrite access control checks again.

Anyone dealt with this before and have a preferred approach?

Thanks.
Ace Nimrod Send private email
Wednesday, September 19, 2007
 
 
Your suggested design makes sense to me. The last thing you want is to have access control logic duplicated in multiple places.
clcr
Wednesday, September 19, 2007
 
 
I'd vote to keep the access control and business logic separate, on the basis that they are different concerns and mingling the code will just increase the chance of introducing bugs into one when modifying the other.

I'd have three software layers:

  public protocol API (bolt new protocols on here)

  access control logic (routes calls to business logic
      only if the requesting user has sufficient access)

  business logic (handles the actual work, doesn't need
      to know or worry about protocols or user access)

While this looks like more work (there will be some duplication of function/method names between the access control and business logic layers) it isn't really that bad: matching functions/methods in the access control and business logic layers contain completely different code doing completely different jobs. It also might appear to be slower than doing access control and business logic in the same place, but that would be an example of premature (and probably wrongheaded) optimization: you'll probably be doing more than enough work in both access control and business logic to absorb the overhead of an extra method call.
Jeffrey Dutky Send private email
Wednesday, September 19, 2007
 
 
That happens to be an approach I experimented with this afternoon.

I took some of the access control checks out of the protocol and into their own methods that can be used by any protocol layer.

Each protocol interface layer will have to call these methods, but it makes a little easier.

A little closer to what you suggest might be proxy methods to the business logic which determine access which is something I'll play with as well.
Ace Nimrod Send private email
Wednesday, September 19, 2007
 
 
"A little closer to what you suggest might be proxy methods to the business logic which determine access which is something I'll play with as well."

Yes, while my original suggesting would have looked something like this:

  doSomething(user u, ...) /* access control layer */
  {
      ... /* determine if user has access */
      if(allowed)
        BL_doSomething(...; /* business logic call */
      else
        ... /* raise an exception or return error */
      return GOOD_STATUS;
  }

  BL_doSomething(...) /* business logic layer */
  {
      ... /* do the business logic here */
  }

I had considered suggesting a design with a third component which called both the access control logic and the business logic. It would look something like this:

  doSomething(user u, ...) /* proxy component */
  {
      if(AC_doSomething(u))
        BL_doSomething(...);
      else
        ... /* raise exception or return error */
      return GOOD_STATUS;
  }

  AC_doSomething(user u) /* access control layer */
  {
      ... /* determine if user may "doSomething" */
      return allowed;
  }

  BL_doSomething(...) /* business logic layer */
  {
      ... /* do business logic here */
  }

Here you have the design advantage of completely separating the mapping between protocol-side APIs, business logic and access control. You can even write proxy methods that have no single corresponding business logic or access control, which, instead, may be composed of several different calls to other business logic and access control methods. It's a very flexible design, good if you expect to have to make many changes to your code base down the road.

There is also a temptation to try to move both the access control logic and the business logic into a database (or a configuration file), I was even tempted, momentarily, to suggest this, but you should avoid this unless it is required by a client. The assumption is that moving this logic into a database or configuration file (making it "data driven") will eliminate the need for programmers to add new logic to the system: nothing could be farther from the truth.

Even though you won't be writing the business logic in a compiled language at that point, there will still be the need to convert (vague and contradictory) customer specs and requirements to a coded form (the database or config file entries) and to test and debug the new logic once it has been written. Given that, and given that you don't have a hard spec from a paying customer, it is better to leave this logic in a normal programming language, for which skilled practitioners can be readilly obtained on the open labor market.
Jeffrey Dutky Send private email
Wednesday, September 19, 2007
 
 
take a look on Microsoft's offering of Software Licensing and Protection Services - more information about this new product will come out in couple of weeks - http://www.softwarepotential.com/license-enforcement.html
Ashish Jaiman Send private email
Tuesday, September 25, 2007
 
 
Add an access control layer in front of the business logic, behind the custom protocol & web layers.

1 place to maintain it.  Separated from the business logic and the interfaces.  Think of it like a firewall.
Lally Singh Send private email
Saturday, September 29, 2007
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz