I have a C# .net application which servers both company's internal users and external customers. I need to do fine-grained authorization like who accesses what resource. So I need something like resource-based or attribute-based rather than a role-based authorization.
What comes to my mind is to either:
Implement my own authorization mechanism and sql tables for my .net application
Use/implement a standard mechanism, like a software that has implemented XACML (for instance Axiomatics)
The problem with the first method is that it is not centralized nor standard so other systems cannot use it for authorization.
The problem with the second approach is that it is potentially slower (due to extra calls needed for each resource). Also I am not sure how widely a standard authorization like XACML is supported by applications in the market to make future integrations easier.
So, in general what are the good practices for fine-grained authorization for web applications that are supposed to serve both internal users and external customers?
I would definitely go for externalized authorization. It doesn't mean it will be slower. It means you have cleanly separated access control from the business logic.
Overview
XACML is a good way to go. The TC is very active and companies such as Boeing, EMC, the Veterans Administration, Oracle, and Axiomatics are all active members.
The XACML architecture guarantees you can get the performance you want. Since the enforcement (PEP) and the decision engine (PDP) are loosely coupled you can choose how they communicate, what protocol they use, whether to use multiple decisions, etc... This means you have the choice to go for the integration which fits your performance needs.
There is also a standard PDP interface defined in the SAML profile for XACML. That guarantees you 'future-proof' access control where you are not locked into any particular vendor solution.
Access control for webapps
You can simply drop in a PEP for .Net webapps by using HTTP Filters in ISAPI and ASP.NET. Axiomatics has got one off-the-shelf for that.
Current implementations
If you check Axiomatics's customers page, you'll see they have Paypal, Bell Helicopter, and more. So XACML is indeed a reality and it can tackle very large deployments (hundreds of millions of users).
Also, Datev eG, a leading financial services provider is using Axiomatics's .Net PDP implementation for its services / apps. Since the .Net PDP is embedded in that case, performance is optimal.
Otherwise, you can always choose from off-the-shelf PEPs for .Net that integration with any PDP - for instance a SOAP-based XACML authorization service.
High levels of performance with XACML
Last July at the Gartner "Catalyst" conference, Axiomatics announced the release of their latest product, the Axiomatics Reverse Query which helps you tackle the 'billion record challenge'. It targets access control for data sources as well as RIA. It uses a pure XACML solution so that it remains interoperable with other solutions.
As a matter of fact, Kuppinger Cole will host a webinar on the topic very soon: http://www.kuppingercole.com/events/n10058
Check out the Axiomatics ARQ press release too here: http://www.axiomatics.com/latest-news/216-axiomatics-releases-new-reverse-query-authorization-product-a-breakthrough-innovation-for-authorization-services.html
Definitely look for a drop-in authorization module for your ASP.NET application. I'm not just saying that because I implement drop-in auth systems at BiTKOO, but because I have had to work with home-grown auth implementations in the past. Building your own authorization system for a single application really is not a good use of your time or resources unless you intend to make a career out of implementing security systems.
Externalizing the authorization decision from your app is a good idea from an architectural standpoint. Externalizing the authz decision gives you an enormous amount of flexibility to change your access criteria on the fly without having to shut down your web service or reconfigure the web server itself. Decoupling the web front-end from the authz engine allows you to scale each independently according to the load and traffic patterns of your application, and allows you to share the authz engine across multiple apps.
Yes, adding a network call to your web app will add some overhead to your web response compared to having no authorization at all or using a local database on the web server. That shouldn't be a reason not to consider external authorization. Any serious authorization product you consider will provide some sort of caching capability to minimize the number of network calls required per web request or even per user session across multiple web requests.
In BiTKOO's Keystone system, for example, the user attributes can be cached on the web server per user-session, so there's really only one back-end network request involved on the first page request as part of establishing a user login. Subsequent page requests (within the lifetime of the cached credentials, usually 5 minutes or so) can be handled by the web server without needing to hit the authz service again. This scales well in cloud web farms, and is built on XACML standards.
I need to do fine-grained authorization like who accesses what resource. So I need something like resource-based or attribute-based rather than a role-based authorization.
Check out this: https://zanzibar.academy/. Zanzibar is a project made at Google to solve fine-grained authorization at scale.
Use/implement a standard mechanism, like a software that has implemented XACML (for instance Axiomatics). The problem with the second approach is that it is potentially slower (due to extra calls needed for each resource).
Auth0 is working on a solution called FGA (https://fga.dev) that will be optimized for low latency. It's built upon the Zanzibar paper.
Disclaimer: I am employed at Auth0.
Related
What would be a good way to provide a non-trivial backend for mobile apps, regarding both the protocol used for communication, and the actual hosting?
Most backend platforms (such as parse.com) provides some basic API for performing trivial CRUD data operations, but if the server logic needs to be more complex than that, what would be a good strategy (preferably .NET/C#, secondarily JAVA, but not javascript or any custom scripting approached)? SOAP web services (for example WCF)?
Regarding hosting, I have looked at Azure and AppHarbor, but can't decide between the two. AppHarbor seems like the only place to co-locate the web server and a MongoDB instance in Northern Europe, as Azure (apparently) only provides MongoDB in a US region. Any suggestions?
Is there a single sign-on solution with completely RESTful API installable on my server? I have looked at OpenAM, which have some of the API available through HTTP/JSON, but not all (and seems too heavy, but if it had all the API, I'd not care).
Do you know of solution for authorization, authentication and identity management that can be used for single sign-on and has all (maybe without setting admin password and such critical issues) its API available though HTTP(S)/JSON?
I have no need for Java API etc., HTTP(S)+CLI for setup is only thing I look for. That is, I doin;t realkly care what the solution is implemented in (no need for Java EE etc.) as far as it does its job and it is secure.
Have you seen Mozilla's new Persona solution built on BrowserID? It does a lot, but it's hard to know if it's sufficient for you without more details about how integrated you need the authorization to be.
You might want to look at Stormpath. They're the largest identify management service (for developers) -- and they are all REST + JSON API backed.
I have been challenged with the task of coming up with an authentication/authorization strategy for a pretty big WCF API. My task is to implement security on this API from clients who might be a website, a mobile app, or an internal/network admin user (which is pretty much the goal of any solid API).
I have looked into Windows Identity Foundation and federated security, but it relies on WS-* and my clients might be using REST or a non-SOAP protocol. So, my question:
Is there a security strategy (per method call, preferably using attributes) for WCF that does not rely on SOAP or involve reams of configuration files?
I realize there's probably no catch-all solution. I'm really looking for ideas or suggestions. This turns out to be a really tricky challenge.
Basic Authentication and HTTPS is a straightforward and "secure enough" solution for most API authentication requirements.
When you say "per method call", I'm getting the impression that are talking about authorization. For that you are probably going to have to roll something yourself. The upcoming Microsoft Web Api framework has some good extension points that will make this type of functionality much easier to implement. It shouldn't be too long before someone implements a reusable module for this framework that you can just plug in.
I'm in the process of setting up a WCF Data Services web service and I'm trying to sort out the security configuration. Although there's quite a lot of documentation out there for configuring WCF security, a lot of it seems to be outmoded or does not apply to my scenario.
Ultimately, I am planning on managing authorization of operations via change interceptors. Thus, all I really need is the simplest way to permit a client to pass credentials along with a request and to be able to authenticate those credentials against either AD or an ASP.NET membership provider (I'd much prefer the latter unless it makes things much more complicated).
I'm intending to manage encryption at the transport level (i.e. HTTPS).
I'm hoping that the eventual solution does not involve a huge web.config. Likewise, I'd much prefer to avoid writing custom code for the purpose of authentication.
In the following links you have a series of OData authentication options. If you don't know exactly what you want then that is a really good place to start and see what options you have.
Part1
Part2...
An exploratory question, here. After some reading, I'm getting a sinking feeling that WCF's authentication options aren't "friendly" to non-Microsoft clients, or require a great deal of effort to implement. I'm building a REST WCF service for which I wanted some kind of simple digest authentication; e.g. I store a username and password in Web.config and share that with the team that will use the service. The team that will consume this service is a legacy shop not versed in Microsoft tooling or helpers; e.g. ANSI C/C++, PHP, etc.
Anyway, MSDN tells me that digest authentication requires that the server be in a domain. I don't want or need this service to be in a domain. That seems like an odd requirement. So I dismissed that option.
So I read about NTLM and Windows authentication, but I worry that I'd be imposing a burden on the other team by only supporting Microsoft-flavored, proprietary authentication methods; won't they have to put forth a lot more effort to code against such a service? These methods seem intrinsically tied to concepts like Windows domains and user accounts, etc.
If you just look for "friendliness" then you can go for basic authentication which is pretty much supported everywhere.
However, unless that is coupled with some kind of transport level encryption then passwords will be transferred in clear text - a pretty bad situation security-wise.
NTLM and kerberos authentication is supported by several non-WCF technologies does but a burden/requirement on the environment in which the are used.
You could look into some kind of message level authentication meaning that the credentials will be part of the message instead of handled by the transport. WCF supports the WS-* specifications that relate to message level security. Those specifications are again not tied to WCF or Windows.
I sounds like the simplest way in your setup would be to use basic authentication and use HTTPS for the transport.
Windows Authentication is intended for use in intranet services where there is a domain controller you can use to manage your credentials and authorization.
You need to check the Forms Authentication, that will probably meet your needs.