So if your scenarios is one of the above or some slight variation we recommend that you use OAuth 2.0 to protect your service, it provides the utmost flexibility and power.<\/p>\n
To explore this scenario we are going to walkthrough a real-world scenario, from end to end.<\/b><\/p>\n
<\/b><\/p>\nThe Scenario <\/b><\/h2>\n
We’re going to create an OData service based on this Entity Framework model for managing a user’s Favorite Uris:<\/p>\n
As you can see this is a pretty simple model with just Users and Favorites. <\/p>\n Our service should not require its own username and password, which is a sure way to annoy users today. Instead it will rely on well-known third parties like Google and Yahoo, to provide the users identity. We’ll use AppFabric Access Control Services (aka ACS) because it provides an easy way to bridge these third parties claims and rewrite them as a signed OAuth 2.0 Simple Web Token or SWT. <\/p>\n The idea is that we will trust email-address claims issued by our ACS service via a SWT in the Authorization header of the request. We’ll then use a HttpModule to convert that SWT into a WIF ClaimsPrincipal.<\/p>\n Then our service’s job will be to map the EmailAddress in the incoming claim to a User entity in the database via the User’s EmailAddress property, and use that to enforce Business Rules.<\/p>\n <\/b><\/p>\n We need our Data Service to:<\/p>\n <\/b><\/p>\n First we add a DataService that exposes our Entity Framework model like this: <\/p>\n public class Favorites : DataService<FavoritesModelContainer> You can use https:\/\/portal.appfabriclabs.com\/<\/a> to create an AppFabric project, which will allow you to trial Access Control Services (or ACS) for free. The steps involved are: <\/p>\n Then you will see this: <\/p>\n NOTE: As you can see there is already a ‘Relying Party Application’ called AccessControlManagement. That is the application we are currently using that manages our ACS instance. It trusts our ACS to make claims about the current user’s identity. <\/p>\n As you can see this management application thinks I am an administrator (top right corner). This is because I logged on to AppFabric using LiveId as odatademo@hotmail.com<\/a> who is the owner of this Service Namespace. <\/p>\n Now we can create a relying party – i.e. something to represent our OData favorites service – which will ‘rely’ on ACS to make claims about who is making the request, to do this: <\/li>\n Name: <\/b>Choose a name that represents your Application You should see these rules get generated automatically: <\/p>\n This set of rules will take claims from Google, Yahoo and Windows Live Id, and pass them through untouched by sign then with the Token Signing Key we generated earlier. <\/p>\n Notice that LiveId claims don’t include an ‘emailaddress’ or ‘name’, so if we want to support LiveId our OAuth module on the server will need to figure out a way to convert a ‘nameidentifier’ claim into a ‘name’ and ‘emailaddress’ which is beyond the scope of this blog post.<\/p>\n At this point we’ve finished configuring ACS, and we can configure our OData Service to trust it.<\/p>\n We will rely on a sample<\/a> the WIF team recently released that includes a lot of useful OAuth 2.0 helper code. This code builds on WIF adding some very useful extensions.<\/p>\n The most useful code for our purposes is a class called OAuthProtectionModule. This is a HttpModule that converts claims made via a Simple Web Token (SWT) in the incoming request’s Authorization header into a ClaimsPrincipal which it then assigns to HttpContext.Current.User.<\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/odatateam\/wp-content\/uploads\/sites\/23\/2011\/01\/5518.image_thumb_44AE2E89.png\" "\\"image\\"")
<\/a><\/p>\nBusiness Rules<\/b><\/h2>\n
\n
Implementation<\/b><\/h2>\n
Prerequisites<\/b><\/h2>\n
\n
Creating our Data Service<\/b><\/h2>\n
<\/span>{
<\/span> \/\/ This method is called only once to initialize service-wide policies.
<\/span> public static void InitializeService(DataServiceConfiguration config)
<\/span> {
<\/span> config.SetEntitySetAccessRule(“*”, EntitySetRights.All);
<\/span> config.SetEntitySetPageSize(“*”, 100);
<\/span> config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
<\/span> }
}<\/span> <\/p>\nAuthentication<\/b><\/h2>\n
Configuring ACS<\/b><\/h3>\n
\n
<\/a> <\/li>\n<\/a> <\/li>\n<\/a> <\/li>\n<\/a> <\/p>\n<\/a> <\/li>\n<\/a> <\/li>\n<\/a> <\/li>\n<\/a> <\/p>\n<\/a> <\/a> <\/li>\n
Realm:<\/b> Choose the ‘domain’ that you intend to host your application at. This will work even if you are testing on localhost first so long as web.config settings that control your OAuth security module match.
Return URL:<\/b> Choose some url relative to your domain, like in the above sample. Note this is not need by the server, this is only needed when we write a client – which we will do in the next blog post. You *will* need to change this value as you move from testing to live deployment, because your clients will actually follow this link.
Error URL: <\/b>Leave this blank
Token format:<\/b> Choose SWT (i.e. a Simple Web Token which can be embedded in request headers).
Token lifetime (secs):<\/b> Leave at the default.
Identity providers:<\/b> Leave the default.
Rule groups:<\/b> Leave the default.
Token signing key:<\/b> Click ‘Generate’ to produce a key or paste an existing key in.
Effective date:<\/b> Leave the default.
Expiration date:<\/b> Leave the default.
<\/b><\/li>\n<\/a> <\/li>\n<\/a> <\/li>\n<\/ol>\nServer Building Blocks<\/b><\/h3>\n