Fine-grained authorization for web applications

8
votes

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:

  1. Implement my own authorization mechanism and sql tables for my .net application
  2. 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?

3
authorizationxacmlabac
Can the access permissions be expressed as policies (a general rule which covers many situations) or are the sharing decisions made by users between each other and basically arbitrary? – kgilpin
@kgilpin: Access permissions can be both general and specific. General as in "only group A can read invoices" and specific as in "user X has read access to account Alpha". – kaptan
I think there is some confusion these days about what role-based access control (RBAC) actually is. In its formal envisioning, RBAC is very much capable of doing what you desire. You have described two roles: "invoice readers" and "readers of account Alpha". You've got two answers below which are from vendors of attribute-based access control, but the rules you describe above don't sound attribute-based to me. There is a perception that "RBAC can't do this", because people confuse the formality of RBAC with some rather weak implementations of RBAC. – kgilpin
@kgilpin: In the RBAC implementations I have seen, you can say "[group A / user X] has read access to Account entities" but you cannot say "[group A / user X] has read access to specific Account entity Alpha". This might be due to incomplete implementation but I didn't have the chance to work with an implementation that supports a Role like "can read Account Alpha". Do you know any? – kaptan

3 Answers

8
votes

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

3
votes

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.

1
votes

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 Sandcastle (https://learn.sandcastle.cloud/) that will be optimized for low latency. It's built upon the Zanzibar paper.

Disclaimer: I am employed at Auth0.