Implement geo XACML using Authzforce and host it on heroku - heroku

Question

I'm completely new to both the topics. Can someone help me with step by step tutorials to implement them?
An alternative to both of them can also be suggested.

Answer 1

First a word of warning: GeoXACML spec was written as an extension to XACML 2.0, since it was the last version of XACML at the time (last GeoXACML version dates back to 2011). Now, AuthzForce only supports XACML 3.0. Yet, this is no big deal, the XACML 2.0 terms and model elements used in GeoXACML can be adapted to XACML 3.0 easily (few changes to XACML schema in particular). If you have issues with that process, let us know. I strongly recommend to migrate to XACML 3.0 anyway, if you are still using XACML 2.0.
Back to the original question, assuming you agree to use GeoXACML with XACML 3.0, you can implement it in AuthzForce with just two kinds of AuthzForce extensions:
XACML Data-Types: as the name suggests, this is the kind of extension you have to implement in AuthzForce to support the new Data Types defined in section 6.3.1 of the GeoXACML spec v1.0.1. See the wiki page on AuthzForce's github repo to learn how to develop such extension.
XACML Functions: as the name suggests, this is the kind of extension you have to implement in AuthzForce to support the new Functions defined in section 6.3.2 of the GeoXACML spec v1.0.1. See the wiki page on AuthzForce's github repo to learn how to develop such extension.
With that, I think you're covered.
If you have AuthzForce-specific issues with the development of the extensions, please use one of the support channels mentioned on the github (or github issues).

Answer 2

I've reviewed your question and your comments throughout this thread. I understand you are new to XACML altogether. With that in mind, I will seek to elevate your understanding of XACML and how to integrate GeoXACML or generally implement geographical constraints in your policy in my answer.
Understanding XACML
The XACML policy language is as expressive as a natural language. For example, consider the following sentence:
Jane Doe wants to view a confidential document at work during regular
business hours.
A sentence like this includes four grammatical building blocks:
– a subject
– an action
– a resource
– the environment in which the request is made
Each of these “building blocks” can be described using attributes.
To create the authorization policies for an organization, you will want to collect the requirements from the individuals responsible for defining information security policies.
Next you would take the policies provided by the personnel responsible for authorization policies and identify the attributes.
We typically look at defining:
Short name: the user-friendly name of an attribute e.g. role or
citizenship. It is the name usually displayed in editors and
reporting tools.
Namespace: the context to which the attribute belongs. Namespace
follows the reverse domain name notation naming convention, like we
use in Java. So, if we have com.organization.user, we can append a
short name like role to create the fully qualified XACML attribute
identifier com.organization.role.
Category: a concept that comes straight from XACML that states an
attribute always belongs to a category. There are 4 commonly used
categories: subject, action, resource, and environment; they are
defined in step 2 of our tutorial.
Data type: a classification of the data. Attribute values can be of
different types in XACML. The most commonly used are string, integer,
and Boolean. There over a dozen data types available to choose from.
Value range: an optional field to specify a pattern or range of
provided values. Attribute values may be completely random (e.g. a
user’s first name). Others belong to a fixed list of values e.g.
state names or a pattern e.g. zip codes.
For more information on implementing ABAC in an organization, please check out the blog post I wrote on my employer's website here: https://www.axiomatics.com/blog/intro-to-attribute-based-access-control-abac/
I also have an article on my personal blog based on a StackOverflow question, "How to authorize specific resources based on users who created those in REST, using annotations?". The answer provides another good overview of XACML and ABAC in general.
Regarding GeoXACML and geographical constraints in general
I'm not sure of your exact use case, but I want to mention that ipAddress is a data type in XACML, in case it is suitable for your use case (i.e. your systems encounter ip addresses that are not routed through VPNs or other ip obfuscating methods, etc.). The list of data types can be found here: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html.
I'm not aware of any software that offers GeoXACML out of the box with an enterprise grade XACML implementation. What we can offer here at Axiomatics - my employer - is to extend our software, Axiomatics Policy Server, for you to include GeoXACML or even other geographical features to your taste. (Note: When my colleague David Brossard was suggesting in an above comment that you "try Axiomatics PS," it stood for Axiomatics Policy Server.)
The "X" in XACML stands for extensible. And, indeed, the model is extensible enough to offer the flexibility that is required to perform such actions.
The XACML Core Specification version 3.0 actually has a section named XACML extension points, which list all the points where the XACML model and schema can be extended with new semantic. The extension points are:
Category
AttributeId
DataType
FunctionId
MatchId
ObligationId
AdviceId
PolicyCombiningAlgId
RuleCombiningAlgId
StatusCode
SubjectCategory
You can follow up with any questions here on StackOverflow or through the contact pages on the provided websites.
Best,
Michael