Building Web Services with RapidConnect Part 3: Building an Authorization Engine Example


In Part I of our “Building Web Services with RapidConnect” series, I described how to create a simple Web Service using RapidConnect.  To summarize, any RapidConnect action set results in having a new Web Service API method. The primary benefit is that users are limited only by imagination and available data to build powerful Web Services to use.

I then discussed in Part II of this series how you could use RapidConnect as a sort of Virtual Directory middleware.  This example provided an application with a single data view when data elements exist across numerous systems.

In this blog, I’ll look at a very interesting use case for RapidConnect.  We will turn RapidConnect into an Authorization Engine!  Any application will be able to externalize its authorization decisions to RapidConnect, which in turn, allows for authorization to be determined by Attributes, Roles, and/or Entitlements in the identity management system!


We have several home-grown applications.  These applications currently manage authorization on their own.  What we want is for our applications to take full advantage of the identity management system to enhance authorization and support adaptive authorization. Specifically, we want to take advantage of Role and Entitlement assignments and Attributes assigned to Identities.  So, we want to support a web services method similar to this:

We want to support a web services method similar to this

This method, as with most RESTful web services, will return a JSON object containing the answer as to if the request is authorized, as well as provide the rule that was used to enforce this decision:

Returned JSON object

The request parameter is a JSON object containing the details required by the authorization engine.  At a minimum, we want to pass in the system/resource requesting authorization, the username of the perpetrator, and the action the perpetrator is attempting:

The request parameter is a JSON object containing the details required by the authorization engine

Using the Postman RESTful API Client, I have submitted a request to our FnIsAuthorized method.  Here is what that looks like:

Submitted request to our FnIsAuthorized method

Although it is a little cryptic due to encoding, you can see we did get our response back (within the value attribute) that shows result = true and rule = 3.  This means access was authorized because it matched the 3rd rule in our ruleset.  In this example, the user imontoya was attempting a READ operation in the crm system.

Now that we see how it works from the client side, let’s look a little deeper into the magic made possible by the FnIsAuthorized method (aka action set).

First of all, let’s talk about our rule set.  We want to have rules that permit or deny access based on criteria available.  Here is the model for an individual role:

The model for an individual role

The permit property states whether this rule match will permit (true) or deny (false) authorization.

The resource is an array of all resources/systems to which this rule applies. For example, the property could be "resource":["crm","hrms"] which means a request with either crm or hrms as the resource would match.

The perpetrator property is where we build criteria for matching on the user.  The request is passing in a username.  We could just add a list of usernames to the username property, but the better approach would be to use Attributes, Roles, or Entitlements.  The attributes property allows for a filter.  So, if you wanted everyone in the HR department, but only at the HQ location, your attributes property might look like this:

Attributes property

Or, we can simply add a list of Roles by name in the roles property (as an array) or add a list of Entitlements by ID in the entitlements property (as an array).

So, let’s define a rule set made up of a few rules:

Defining a rule set

Let’s take a look at these rules and what they mean.

Rule 1:  Anyone in the Employee Role using either Internet Explorer or using a Linux machine will NOT be permitted to perform any CRUD operation on the CRM system.

Rule 2:  User imontoya will explicitly be allowed all operations on the CRM system from any browser or device.

Rule 3:  Users with attribute division equal to "k12" and employeeType equal to "Employee" will be allowed any operation on the SMS system.

Your rule sets would have to get much larger than this to be of any real use.  You would probably want to store these rules in a database and provide an interface to manage them. Keep in mind, this is only an example of the power of using RapidConnect’s RESTful API.

Hopefully, that provides the concept, and you have a good understanding for what we did here.  To close out this blog entry, I’ll include my raw action set that makes up the FnIsAuthorized method.

FnIsAuthorized method raw action set - Part 1FnIsAuthorized method raw action set - Part 2FnIsAuthorized method raw action set - Part 3




Request a Live Demo


Subscribe Here!