I'm wondering how I can restrict some methods from unauthorized user access. Let's assume I have a WCF service with the following contract:
int Login(string username, string password);
Invoice[] GetCustomersInvoices(int customerId);
A user should act in the following way:
Login to verify against the service and get his custumerId
fetch his invoices by invoking the corresponding method with his customerId
Well, that's maybe a stupid question, but what if customerA's id is 23, but somehow customerA knows customerB's id, which is 42. Now customerA could read customerB's secret invoice data...
What could I best do to avoid this?
You shouldn't use a single id for identifying someone. There are many ways of enabling authn/authz in WCF, I like the article at http://msdn.microsoft.com/en-us/magazine/cc948343.aspx for a good introduction on some ways of doing it.
Your current approach of calling methods will only work if you are able to implement secure(persistent) channel between client and server using SSL or any other such mode (typical scenario would be Baking Payments Getaways)
So IMO you need to implement your user authentication inside the method (no separate calls). i.e. you have to pass userid and password along with invoiceid to GetCustomersInvoices() method and inside it you need to authenticate the user and retrieve the data.
Following would be solution for such scenario,
Implement your own User Name Password Validations (custom usernameathentication), which will first authenticate the user and than it will call the method given. Since this will happen in one request so it will solve your problem.
Typical service method call would be like,
Service.UserName = "abc"
Service.Password = "***"
Service.GetInvoiceDetails(1233)
You can get the use of Message Headers and Body to pass your custom values, Webservices support such scenario where you can pass encrypted data in SOAP headers.
Alternatively you can use Certificates also, but these are not free.
In general you can go through following links to get more info in various kinds of security WCF supports,
http://msdn.microsoft.com/en-us/library/ms731925.aspx
Related
I am trying to implement OAuth in a web service such as:
http://www.codeproject.com/Tips/372422/Secure-WCF-RESTful-service-using-OAUTH
Each time, when the Authenticate method is fire, WebOperationContext.Current.IncomingRequest exists, but UriTemplateMatch is null. This is even the case when using the WCF Test Client, so my client app isn't the problem. Ultimately, I need to access the QueryParameters under UriTemplateMatch.
In the Authenticate method, this is where the code breaks:
NameValueCollection pa = context.UriTemplateMatch.QueryParameters;
Looking for a different solution than this so everything is processed in one request:
https://stackoverflow.com/questions/7344478/using-the-wcf-http-web-api-uritemplatematch-is-always-null
Also, just as much as a solution, I am looking for a reason why the UriTemplateMatch would be null only in the case of a WCF Service. There are hundreds of articles on the presence of this problem, but I haven't found a good solution and/or explanation. I think I may be missing something in my web.config.
It seems that this solution is expecting incoming calls like :
http://localhost:49262/TestProject/Service.svc/user/123?oauth_consumer_key=key&oauth_nonce=10a33ed37b549301644b23b93fc1f1c5&oauth_signature=cUobFDxVB5wjPe9X2XICJ6awmnE%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1289976718&oauth_version=1.0
There are two ways to attach oauth parameters, one is through headers, another is through query string, both are valid, so I choose to attach oauth parameters in query string. There is not any problem to retrieve them from IncomingWebRequestContext.Headers if those oauth parameters are in headers
This solution is not from me. Check this link.
I have a WCF service that supposed to provide service to several clients.
The WCF will have a Data-Access-Layer that will communicate with the database.
This is part of my design idea : My Design
As you can see - each client will connect to the 1st WCF service for pulling information (get product, update product), and also to the 2nd WCF service in a pub\sub manner, so it would be able to receive notifications about different things it wants.
I have a table in the database for 'Users' with all the users in the system.
(there is an administrator, a normal user and a technician).
My question is - how do I do the 'logging' in from the client to the database ?
My current idea - have a function in the services called 'Connect ( username, password )' and when a client connects - it will pass the username and password to be authenticated in the database, and only if authenticated - the client will start sending commands.
Problem with this is - anyone can write his own client that connects to my service and runs other functions without authenticating. I can solve this by saving in the service whether or not the client has authenticated.
But is there a better solution that just having a 'Connect' function in the service ?
Hope there is something simple yet effective.
You should create a custom user name and password validator that derives from the UserNamePasswordValidator abstract class and implements the Validate() method. Then you can validate the provided user name and password however you want. To learn more about setting this up, read this article.
Architecture of project
my wcf expose 11 endpoints,one of the endpoint ment for authentication and autherization. which returns the accountid of the user.this accountid is sent by client in every method for recozination.
need
i dont want to send the account id to every method ,all i want a way that can give me the accoint id automatically if the client is loggedin
Limitation...
1> i cant use membership.
2>i can,t use persession mode of wcf becose it creates new session for every endpoint
3> cant use outgoinfheaders on client side ..
is there any custom way to solve this problem
That looks like scenario for federated security but it would conflict with some of your requirements.
You don't need membership.
You don't need per session services
You need somehow pass the token - if you cannot use custom outgoing SOAP header and configure it in some central place, you will have to pass the token inside the message body and you will have to configure it as a parameter for each service call.
I especially need to get client's certificate used to call service's method. This is to react differently for different clients.
In your operation code, you can examine things like:
OperationContext.Current
or
ServiceSecurityContext.Current
but I'm not sure if you can access the actual client certificate from those.
The ServiceSecurityContext.Current.PrimaryIdentity will contain an IIdentity for the current caller - if it's NULL, then you're dealing with an anonymous call. Otherwise, the PrimaryIdentity will be one of several possible identity types, depending on how the calling user was authenticated - it could be a Windows identity, or something else - depending on your scenario.
See this blog post for a few more tidbits of information on X.509 and WCF.
I'm creating a smart client application using .NET 3.5. A Winforms client connecting through WCF services to retrieve data from SQL Server 2008. I need to pass a username/password (encrypted and over HTTPS) and return information such as:
Is this user (e-mail address) under a current subscription
What server should we go to next for all subsequent calls (poor man's load balancing)
What server/database should be used in the connection string (credentials not required), as people could be using different databases depending on their subscription, etc.
So my first call when signing on sends the credentials which a lookup is performed. A serializable class will be used to create a token object (I assume this is the way to handle this) which will return the expiration, server info, database info.
The question is on all subsequent calls do I pass this token as a parameter to every service contract (web method) or can I leave all my current contracts as is and pass the token in a header or some other more universal method?
How do you suggest implementing a token system such as I describe?
Thank you
For one, I would only return a TokenID - some unique ID to clearly identify the user and his subscription in question - from your first "authentication" call. No need to send back and forth the whole set of information all the time - only the service on the server side needs those details, so you can leave that info on the server and only consult it in your server code when needed.
So that first call - the authentication call - would most likely check the credentials being sent against a database table, against a subscription table, and then put that information (who's calling in, based on what subscription) and possibly some kind of an expiration date/time into a "Valid Callers" table and generate an ID from that (a GUID or something). You might want limit the "lifespan" of a TokenID - e.g. it's valid for 30 minutes or so - so that it can't be hijacked and used perpetually after a first successful call. That generated GUID is then returned as the TokenID from the Authentication call and can be used as an identifier in each subsequent call.
Things like what database server to use have really no place in messages going back and forth - they're strictly important to the server-side service code - just leave it there!
It is definitely preferred practice to put such "meta information" that isn't the real value information for your calls into headers and go search for it there. WCF supports this quite nicely and easily - with either message inspectors (sample for that here and here) on client and service side, or by using the OperationContextScope (sample blog post here and here) - both work just fine.