[Ethereum] Writing secure Smart Contracts in Solidity

I am trying to create a smart contract that holds static data (resembling a paper contract) that is able to be sent around different users (a trade).

The contract itself cannot be sent to any particular user. It exists within the block chain and is accessible (its methods can be called) to any peer that synchronizes with that block chain.

The tricky part is that I would like different permissions for different account types such as requiring multiple people to authenticate the transaction (buyer, seller and middle-men).

All data in an account is publicly available. You won't be able to achieve any proper authentication using only the block chain (you need an secure side channel through which peers convey a shared secret).

What you could do on the other hand is employ secret sharing.

I am struggling to understand a few basic concepts and overall structure of the smart contracts in solidity.

You may have done this already but if not have a look at this demo and a few examples.

Do I create a "factory" contract that controls the system and assigns different users a 'role' and based on the role the contract will need to be verified by all the required users of each 'role' before being sent?

You can't really do that since contracts are public. What you can do, is filter users out by their address (check the msg.sender attribute at the beginning of each contract method).

I forgot to mention that as a contract is swapped between users, I am not really interested in any monetary representation to be exchanged.

Once deployed, the contract is mined and included in the block chain (it is a transaction after all). Afterwards, everyone accessing the block chain "has" the contract.

Just to elaborate on Dennis' answer and explain why this hindrance exists.

Deep down, the decentralized nature of the consensus means that no one's clock is any better than anyone else'. Blocks disambiguate transaction order which is critical for reaching consensus about world state. They do this without reference to a reliable time source. Since no one can check the timeStamp without reference to a non-deterministic time source, the accuracy of the time stamp is dubious.

There's an interesting discussion on the accuracy of the timeStamp, the latitude the miners have and incentives to keep the timeStamp within reason, here: How do Ethereum mining nodes maintain a time consistent with the network?

This is quite a departure from networks synced with atomic clocks as we've come to take for granted, I think. A good understanding can keep us away from hidden assumptions and problems.

We can say ...

"The event will unfold at block _____" which is probably going to occur at approximately date/time given a predictable average block time.

"The event will unfold when a block is mined with a timeStamp >= deadline" which should be roughly at said deadline but isn't guaranteed to be precise.

"The event will unfold when the Oracle injects a transaction to declare that the event has occured without regard to either the block number or the block time stamp" in which case a trusted time source will decide.

Above are some examples of plain english we might use to describe the way a future time is codified in a Smart Contract so things unfold "as advertised."

Hope it helps.