You might want to investigate using certificates in your tiers. Also MSMQ.
After you define the processes and actions, you can create a discrete Win32
account for each one (eg,. a business-access-layer user, a data-reader user,
a data-writer user, etc). Each one has specific permissions and user
rights. Allow roaming profiles.
Next, logon as each given user so it has a profile, load a PKCS#12
certificate into their respective Personal store so they have a public and
private key, and load the X509 public keys of all the others users as well.
Of course you must include CAPICOM (the CryptoAPI COM wrapper for Win32,
there is no .NET equivalent yet so you have to do Interop) in your
distributions.
Create a queue for each type of information that needs to be transmitted.
For each communication, envelope the data with the public key of the
intended recipient and dump it into the respective queue. Attach a queue
trigger to each input queue, which will launch a .exe (passing the trigger
label as an ID) under a recipient user account. This .exe can then use its
private key to de-envelope the data and do something with it.
Now you're using MSMQ for your "remoting channel", but you get the
advantages of disconnected and asynchronous and fault-tolerant delivery.
Set up MSMQ to use TCP, and you can do things like put an ISA server (or
equivalent Cisco hardware) in front of the MSMQ receivers to take care of
load balancing and etc. You also get additional security "for free" because
the certificates you create can be as huge as you want (16384-bit?) since
you control both ends of the handshake.
In order to put the "security on the data itself", do just that; take the
intended work that has to be done, Base64-encode it, stuff it into a CDATA
section of an XML document, and then create additional XML elements that
describe what is to be done with the data. No matter where you put the
data, "everything" that needs to be done is in the same atomic packet.
I have a project in progress for doing some secure transmission, and I am
doing something along these lines. My message-sender takes some data and
encodes it and then signs it with the sender private key, and puts both in
CDATA sections. Then it envelopes the whole thing with the receiver public
key, and drops that into a CDATA section in an XML document with some extra
handler info That gets compressed and stuffed into a message body, the
label has my app-specific info in it. Then it goes into a remote queue.
The queue trigger (MSMQ2.0 on Win2K) starts up on the receiver, decompresses
the message, uses the receiver private key to de-envelope and the sender
public key to verify the signature and then back down to the original
content. It is working pretty well.
* This will be much easier if you model the application along the lines of a
"software fortress", for starters make all participating hosts into domain
controllers so they can share a SAM.
--orig--
From: Yosi Taguri
hi there
I've been given a job to handle the security aspects of big banking
application.
[snip]
The requirements demand that the security (or better said: the
authorization) will be on the values of the data itself.
[snip]
The problem is "merely" MATCHING the permission to the data has
submitted.
[snip]
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
