5

I'm trying to implement some security access control in a software I'm building. I came across Stormpath for user management and they have somewhat an approach for RBAC yet what I was considering is to rely on XACML for ABAC and more specifically BALANA from WSO2 in the sense that I may set the attributes for users and store the profiles in stormpath while I rely on XACML for the policies.

I'm a bit new in this so I was just wondering whether this is advisable or there is another approach would prove useful in my case in order to reuse things for security rather than building things from scratch.

David Brossard
  • 1,360
  • 7
  • 16
user53158
  • 51
  • 1

2 Answers2

1

It depends on your architecture. In principle you can use XACML with any user management tool or authentication management. The main questions are:

  • where do you insert your PEP?
  • How will it grab the user identity?
  • How will it pass it to the PDP?
  • Will the PDP need to call an underlying PIP? Will it need to call Stormpath to retrieve user attributes?

For more information on the XACML architecture and language you can check out the Axiomatics developer blog:

David Brossard
  • 1,360
  • 7
  • 16
1

One of the things people do often with Stormpath is assign authorization policies (like XACML or plain string 'permissions', or proprietary data, whatever) to Accounts or Groups by storing them in customData.

The primary resources in Stormpath (Account, Group, Directory, Application, Tenant) allow you to store ad-hoc schemaless data in the resource's customData for anything you need, like custom fields or of course, authorization policy information.

With Accounts for example, it would be easy to first authenticate the Account, and upon a successful authentication, obtain that account's customData and obtain its authorization policy (e.g. XACML) and then check it however you wish.

This becomes more powerful when you do the same thing with Group resources too.

For example, a common scheme to find an Account's effective (aggregate) policy is to aggregate all policies across all Groups that the Account is a member of. In this scheme, the account is authorized to do anything that is represented in its direct customData or any of its groups' customData.

I don't know what programming language you use, but, as an example of how this might be achieved, Stormpath users that use Apache Shiro do this exact technique with Shiro permissions, Shiro's built-in string-based authorization policy concept.

Regardless of the programming language or authorization policy format (e.g. XACML instead of permission strings), you can leverage Stormpath resources and their custom data for similar or custom authorization schemes. I hope that helps!

Les Hazlewood
  • 153
  • 1
  • 6