WCF REST - how best to architect for multiple users but also limit access

I'm new to WCF and REST so please excuse any obvious questions.

I'm trying to create a RESTful API that will be used by clients.开发者_运维问答 The API needs to be available only to authenticated users so I believe the best way to do this (from what I've read over the last couple of days) is using Basic Auth over SSL which is fine.

I have a basic WCF REST Service Application in VS2010 targeting .NET 3.5. - the bare bones of this have been directly taken from http://www.codeproject.com/KB/WCF/BasicAuthWCFRest.aspx

What I'm struggling to understand and to differentiate on is how to authenticate suers while also restricting the calls that clients can make based on who they are.

So the call that the clients will need to make will pass some basic information from their system to ours, each client will be able to make the same call however I don't want client A being able to post info into client B's area on our side and vice versa.

I was planning on having both clients POSTing something like the following url:-

api.mydomain.com/sale/

however, I wonder if it would make more sense to make it clearer to do this:-

api.mydomain.com/clientA/sale/ api.mydomain.com/clientB/sale/

...as you can see, I'm quite lost!

Also, the example code I have is using a custom MembershipProvider - I understand the basics of Membership but again, don't know if I should be using this in some way to restrict the clients posting data to eachothers areas?

Sorry for the waffling - sooo many questions :(

Regarding authorization (granting an authenticated use access to specific resources) there's a couple of ways.

You can restrict access to certain areas (directories / URL paths) via the <location> element in the web.config, and then using the <authorization> element only allow certain users or roles (groups) to access those locations. This is OK if the number of locations / users / roles is manageable and doesn't change too much. For example:

<location path="ProtectedPlaces/Foo">
    <system.web>
        <authorization>
            <allow roles="FooGroup"/>
            <deny users="*"/>
        </authorization> 
    </system.web>
</location>

Alternatively, under the covers you can use an API based approach that essentially does the same thing. There are a number of libraries out there that can help, including AzMan; an authorization library that's in the same 'family' as the role membership provider; there is also one in the Enterprise Libraries.

This article might be of some help (see: "Step 2: Limiting Functionality Based On the Currently Logged In User’s Roles").

Here is how I did this. I used a standard membership provider (but you can also do the same with a custom membership provider) to authenticate the user, but I do not let IIS do this. I authenticate the user myself (as part of the REST API) and generate a token for that user, which I store in the membership database and send back to the client.

For each request the client makes it needs to send a valid token as well. As the token is stored together with a user id, I can then determine if the token is valid and what user is making the request. Because of this I can then determine if the request is allowed based on my own security rules.

If a user is only allowed to do a certain request on it's own data, then you don't need to send any identifying information except for the token.

HTH.