The big nerd. Like you have no idea.
engineering, coding, government, design, construction, development and some RTV gaskets (google it)

Web services, big networks, policies and you

May 5, 2008 22:56 by Jesse

Right now I'm working on deploying a project that I never would imagine would be this difficult.  The idea was to swoop in, drop the code, show off (ooooooo ahhhhhhhh) and done.  Does anything ever go according to plan?  Of course not.  Well, this one had a rude surprise waiting on us.

The client I speak of has a huge, global network.  Active directory (which is good!) and somewhere around 10+ forests and god knows how many domains.  It's massive, utterly massive.  I would GUESS they have at least 5000 users on this one domain and probably 50-100k user accounts globally, ignoring groups.  So why is this a problem? :Sarcastic laugh:  A couple few reasons.

  1. Not all (logical) networks are setup "best practice".  Best practice is a cookie cutter template, it doesn't always fit and should be used as a guide so immediately you cannot assume "all domains trust each other" or "all accounts have rights".  Transitive trusts, one way trusts, mutual trusts all mean very different things -- they could screw you in different ways too.
  2. Not all authentication can be trusted to work across domains.  This includes SQL accounts.
  3. Not all network devices allow traffic.  This means your www traffic, ftp, etc might not work across the world.  Chances are, http traffic is your best bet, but its not a sure shot.
  4. Network policies (more specifically, group policy) can be your best friend and your worst enemy.  You may not know which nor have a straight answer.

 

So translate : it means your codes magic won't always work thanks to network conditions -- it also means it might work on one domain (ohio domain lets say), it might on one network (wired works whereas a wireless may not), or it might work across one domain and not another (ohio might work with texas, but not necessarily in reverse or from colorado to texas), it may not run at full speed (ohio's domain has flood control turned on).

This makes my head hurt.  I have to think of ALL the network stuff I haven't used in a while plus the admin stuff and toss some happy code to get a wonderful steaming pile of confusion and pain.  After thinking about this for a minute (ok, half hour) I've decided that after this, I'm going to insist web services, anonymously.  Now before you have me skinned alive, hear me out and here's my thinking behind it.

Anonymous webservices can still be secured protected via https, certificates and credentials.  Sure, you can make a request without any network creds, but the service won't talk back because you don't meet the needs.  "But this'll increase the overhead on the server, it'll slow everything down!" and you would need to be fired -- speed should never trump a security decision.  "But what if an account isn't disabled and cleaned up?!" good point, not your problem, a well administered network will not have this concern. 

Now that those problems are addressed, why anonymous?  More likely than not, a network, and I'm speaking of the whole network, will allow web traffic from point A to point X without too much drama.  Furthermore, once the request gets to that service, I'd bet money that server is sitting in a screened subnet/protected area (I've yet to see one NOT setup like this in a really long time) -- perfect place to make all your sql calls (via ipsec I'm sure).

Will this make code more complicated?  Yes.  Will it tax the server/client more?  No doubt.  Will it drive up costs?  Yes -- BUT, and thats a full, wholesome but, it's meant for enterprise, treat it as such and bring the big guns.


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:
Categories: Coding | Design | Architecture
Actions: E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Related posts

Add comment


(Will show your Gravatar icon)  

  Country flag





Live preview

July 6. 2008 00:14