Using owin’s interceptor for tokens presented to an odata webapi


image

The resource server is that which hosts the odata endpoints – nominally containing entity records that are “owned by” the resource owner. For example, if the resource is the users profile, then the user is the resource owner of the record about him/her – and one may be required to authenticate to the endpoint using a ticket that was issued in response to a challenge for that user’s name/password.

The delivery and the securing is accomplished by invoking the magic of OWIN’s useOAuthBearerAuthentication method.

image

Into the message listener stack this inserts a token locator module and also a validator of the located token. Post location/validation,  the a user identity – just a ClaimsIdentity value similar to that stored in the ASP.NET Page.User property – is made available to the controller  class for the entity in question. If the class or particular method exposed by the class has authorization behaviours – rules limiting access to certain parties based on their identities have, say, a role claim such as billtype=R –they will be enforced, as the action is executed.

 

Of course, its more likely that the behaviours would be implemented in a claimsauthorizationmodule injected into the pipeline, rather than hard coding enforcements rules into the code.

image

see http://pfelix.wordpress.com/2011/10/08/wcf-web-apibuilding-an-authorize-attribute/

Advertisements

About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in odata. Bookmark the permalink.