GUIDs, snks, reflection and ILMerge

[JT]

Hi,

I am having trouble finding information about GUIDs and strong-names
and don't really know what I need. If that's too ambiguous, please
tell me where to look for info on these.

Here's what I am trying to accomplish: I need to know what assembly is
calling methods in a web service. I also use ILMerge.exe to merge my
assemblies into a single executable. One of the dlls in the executable
calls the web service. I need to enforce that only this dll makes
calls to the web service. After ILMerge, I can't use reflection to
obtain the name of the dll that calls the web service and besides
that's not quite a unique ID. The dll that calls the web service will
be distributed for use in other applications, but I need to know that
the dll I'm distributing is making the calls to the web service and not
any other assemblies.

I believe a GUID would be sufficient to identify the calling dll, but I
can't find any information that tells me how to get the GUID of this
calling assembly. After reading some help files and some posted
discussions, I now think that a strong-name will not necessarily change
when the assemblies are recompiled, but I don't know enough to know how
difficult it is to create a snk file. I also don't know if merging my
assemblies will keep me from being able to obtain either a GUID or
strong-name key of the assembly.

I'm sure there are high-level discussions out there. Can anyone point
me to an example of programmatically retrieving an assembly's GUID
and/or creating snks and programmatically retrieving the public key of
an assembly? Is there a better way for me to identify a calling
assembly after it's been merged?

Thanks,

JT

 

[Guest]

JT,
I am not "100%" on this, but my experience with ILMerge tells me that after
a merge, you are really only dealing with *one* assembly - the result of the
merge.
So, you will likely need to look at something more along the lines of CAS
(Code Access Secrurity) to ensure that only certain classes can have access
to the WebService proxy class in your merged assy.
Peter

 

[Dave Sexton]

Hi,

You're trying to verify, on the service end, whether a particular assembly
calls into your "public" web service methods, correct?

You'd have to send more than just a GUID or public key to the server in
order to secure the app, but even any encryption scheme that you may decide
to use can be easily spoofed from the machine that's hosting the valid
assembly itself. It would just be security through obscurity on the local
machine.

You might be better off just ensuring that any calls into the web service
are validated by a key that only the client can have, regardless of the
assembly in which it is called from. This can be done using encryption and
authentication. Also, try to design your web service so that it doesn't
expose any private implementation details, wherever possible (e.g., don't
accept password parameters, disable WSDL generation)

You may also want to look into encryption using WSE to protect the web
service from external attacks.

"Encrypting SOAP Messages Using Web Services Enhancements"
http://msdn2.microsoft.com/en-us/library/ms996945.aspx

Unencrypted SOAP messages are just clear-xml, so any eavesdropping app could
easily read the messages and send them to the Web Service on behalf of your
valid assembly. Not good

You could use SSL for transport-level security, for example.

To authenticate the client you can use basic or digest security in IIS or a
digital certificate, for example.

Here's a really good article on Web Service security (Written for 1.1 but it
certainly applies to 2.0 as well from what I've read):

"Chapter 12 - Building Secure Web Services"
http://msdn2.microsoft.com/en-us/library/aa302428.aspx

 

[JT]

Thanks for the replies, guys. I think you've given me some really good
advice and things to look into. I'll be digging into all this
tomorrow. I'm hoping WCF will make all this easier, but that's
something else I haven't looked into enough.

Thanks,

JT