views:

194

answers:

2

I inherited a system that gets data from a webmethod in the form of a dataset. The data is potentially sensitive. The one thing that struck me about this was that some methods had no way of knowing, or checking who the caller was, and others that required an integer number to identify the caller. This integer starts at0 and is sequential and associated with a different company/data set. Obviously not good enough. (it was easy for me to see data I shouldn't have had access to by guessing numbers

My question is, is there a best practise way of authenticating callers, improving this system

A: 

If you have control of the web service code, you can modify it to require authentication or perhaps create a proxy it.

Please read this article.

ichiban
+3  A: 

What type of service is it? These days, I'd write it as WCF, and use any of the the regular identity models to authenticate (I generally use TransportWithMessageCredential - i.e. SSL with a username/password in the body). Then you can just check the identity via the Principal (Thread.CurrentPrincipal.Identity.Name).

For SOAP services, you can use SOAP headers for authentication, or you can include identity information as method arguments - either a username/password pair, or a separate identity token that you can parse to get the identity. In any case, you should only pass identity information "as is" over a secure transport like SSL. There are other techniques that don't require passing the password, but they are more complex (especially if multiple domains etc are involved); kerberos or federated security are options. Personally, I keep it simple, as not all clients can use federation etc - but most clients can pass a username/password pair over SSL.

Marc Gravell
If you use WCF, you also get many options on encrypting the sensitive data.
John Saunders
@MarcI don't have access. It's a seperate company who work with our data on there systems. So soap it is...I was thinking the simplest solution might have been a guid known to both parties?So we need to specify SSL also. Thanks Marc
Stuart
If the Guid alone is enough to say "I am Fred, trust me...", then yes: you should be using SSL (or field-level encryption); otherwise it simply isn't secure... somebody with "wireshark" (or a corrupt switch/router) could get that without any trouble. But yes, I *guess* a Guid would suffice as a "separate identity token"; pretty unguessable, at least. You'd want some process to update the Guid, but that might be as high-tech as a 'phone call... (depending on the system).
Marc Gravell