Reputation: 12215
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
Upvotes: 3
Views: 582
Reputation: 1062550
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.
Upvotes: 3