I want to guard OData service with custom authentication associated to a user table in database. I have been obssessed with this problem and searched solutions for a long time in vain. I mean, yes, there are quite a lot articles on the web but they are just quite trivial, for example implementing IPrincipal or IHttpContext with basic authentication on. Notably, many of them can data back to 2010 where OData is not as mature as today. So I'm wondering if there is any rapid solution to database-based custom authentication.
Any guidance would be greatly appreciated!
OData and authentication (and even authorization for that matter) are unrelated for the most part by design. That doesn't mean that OData stacks can't provide good support for authentication and authorization, just that the OData protocol itself doesn't comment on it. Protocol aside, both Web API and WCF Data Services are working on getting better support here. Speaking as a member of the .NET community (and not as a Microsoft employee), I think it's reasonable to expect that as those stacks implement authorization APIs they will probably be looking to claims-based authorization. Again, I want to state explicitly that I'm not trying to hide or divulge any plans here - I'm merely speculating about where authentication and authorization are going.
In a nutshell, if I were in your shoes I'd find the easiest intersection I could between OAuth2 and claims-based authentication and make that work for now. Working out your claims and authentication now means that you only would need to consider integrating the actual authorization code later.
Related
I’m working on an existing single-page application consuming data from WebAPI.
Authentication is largely handled with WebSecurity and SimpleMembership via forms authentication as the application was originally built on MVC.
I know that this is bad (CSRF), and I want to fix it either by
implementing some kind of CSRF protection (preferred)
or by reimplementing Authentication and Authorization to use tokens instead of cookies.
Would implementing header validation be an adequate solution? The API is being consumed by both web and mobile clients, in case it matters.
I’m not too skilled around security and want to make sure we’re not setting ourselves up for vulnerability by using cookies here.
Well, you would have to leave cookies anyway because otherwise you wouldn't be able to authenticate returning users (they would have to authenticate every time they open the app page). (Of course there are other exotic options like using client local storage or "Flash cookies" but this is pretty much the same approach.)
To answer your question, yes, you will need to implement CSRF protection. It doesn't matter which implementation you choose: it can be the implementation that uses custom HTTP headers or additional WebAPI request params, it can be implemented using built-in anti-forgery API (described in the article you mentioned) or you can make your own implementation.
I would probably implement custom CSRF protection mechanism because this way you can make it more suitable for your SPA (for example you can send it through WebAPI response as a result of authentication operation instead of rendering it to the HTML or JS as it was suggested in the article).
I have WCF services in need of claims-aware authorization (as in can-create-resource-X, can-edit-resource-Y, etc).
Authorization should be Username/Password based, no Windows identities.
I need to keep authorization logic and data local to server, where WCF services are hosted.
Authorization data should be stored in PostgreSQL and not SQL Server.
At first I was going to implement Claims-Based Security according to "Learning WCF. A Hands-on Guide", employing pgProvider as a PostgreSQL-based replacement for ASP.NET Membership Provider. But I stumbled over ClaimsPrincipal being redefined (along with Claims) in .Net 4.5 that I'm using now.
Then I came across WIF being recommended now as a primary device for authorization purposes. As of now I'm trying to wrap my head around WIF and I cannot find any mentions of a valid STS to be used locally. The only mention I came across is Local Development STS, but as far as I understand it is to be used for development and testing purposes only, not in production.
I considered creating custom STS, but according to google it isn't to be my first choice. And it does indeed seem an overly complicated approach for a seemingly simple purpose of having local username/password authorization.
So how do I go about creating claim-based authorization for my WCF services? Is there a local STS I haven't come across? Am I supposed to forget WIF and write my own authorization logic? Anything else?
VS 2010 and VS 2012 had tools to generate a local STS but yes, not for Production.
The basic problem is that very few people used WCF (the WS-Fed active profile) compared to browser access (the WS-Fed passive profile).
So I don't know of any STS that you can use.
You may consider Give your WCF Security Architecture a Makeover with IdentityServer3?
My mistake.
ClaimsPrincipal mentioned in "Learning WCF. A Hands-on Guide" is not a framework class I thought it to be - it's a custom programmer-created class. I was misguided by a class of the same name in newer .NET framework versions.
I would like to use oAuth as a system to allow developers access to my API but not require them to pass through the login information.
There does not seem to be any good how-to's or blogs on this topic. Everything I have found is based on consuming an oAuth system such as Facebook or twitter. Wondering if anyone has any links to good instructions or libraries that could get me started. If there are no examples out there perhaps someone could consider writing one, the community really needs it.
Using OAuth to login is actually a side-effect, not the main goal of the protocol. The best place to start with providing an OAuth-protected API is the protocol specification and since this is a new service, you should take a look at OAuth 2.0 1. It is pretty much done and ready for deployment.
To implement OAuth 2.0 you will need to make a few important decisions about which features you are going to support and your scaling needs. There are also a lot of security considerations to go through. I would suggest you start with supporting the authorization code and implicit grant types.
I would look into DotNetOpenAuth. It should work for your needs, but I've only used it for the OpenID stuff.
I am struggling trying to pick apart the OAuth Service Provider example which is included in DotNetOpenAuth. I searched SO and found a few similar/related posts, but nothing really useful. Is there any open-source project or really simple/primitive example of an ASP.NET MVC 2 OAuth Service Provider? All I want to use OAuth for is authentication of the service. I was going to roll my own api with a key/secret, but thought a tried and tested protocol like OAuth would probably be a better solution.
I ended up doing some extensive research to find that I didn't need the traditional 3-legged OAuth and only needed 2-legged. The problem is 2-legged OAuth information is pretty hard to find. I finally found an Google spec for implementing 2-legged OAuth:
http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/2/spec.html
I also found an implementation of it, as Justin.tv is using it for their services:
http://apiwiki.justin.tv/mediawiki/index.php/OAuth_Ruby_Tutorial
I also stumbled across an excellent OAuth testing tool which helped me greatly in implementing the service:
http://term.ie/oauth/example/client.php
2-legged OAuth is pretty simple once you understand what you are looking for and how to implement it. If you're searching for OAuth, most likely you are finding articles talking about the traditional 3-legged OAuth which involves 3-parties as the name implies: consumers, service providers, AND users. Two-legged strictly involves consumers and service providers. If you're service does not deal with users specifically, 2-legged OAuth is just what you're looking for.
As for a framework, I am using ASP.NET MVC so I ended up settling on a github repository located here:
https://github.com/buildmaster/oauth-mvc.net
Its got some really nice, clean code, and uses dependency injection (Ninject). It didn't take much for me to be able to modify it for 2-legged OAuth.
It should be possible to use SAML to authenticate users for any type of application (according to the spec), but the examples I have seen are cookie-based ASP.NET web-sites.
Does anyone know of an example authenticating users for, say, a Win Forms app (not using cookies)?
Not quite sure what it is you are looking for. If you are looking for SAML based authentication, you can use some combination of Windows Identity Framework and WCF and AD FS. SAML is just the "language" of authentication, but unless you already have an identity provider, you need to start there first.
You can use this article to give you an idea of what the basic infrastructure looks like, and I frequently use the site leastprivilege.com for a deeper reference.
But, if the scope of your application is purely within the desktop (ie, never communicates with any services) you really don't need anything like SAML to achieve your goal. Usage of tokens like SAML are for communicating with web services where the endpoints trust the identity provider.
SAML is a wee complicated beastie. I'm not sure I'd try to roll my own SAML SSO solution.
When we implemented SAML SSO, we used PingFederate from. It's expensive, but good. There's also some open source SAML SSO stuff about, but I can't really speak to it.
PingFederate is pretty dead simple to configure and use, although if you don't speak SAML, the learning curve will be steep until you understand the concepts, the flow and the lingo used.