Attribute Based Routing

Client applications and/or users accessing APIs secured by Forum Sentry may need to be routed to different back-end severs, while otherwise utilizing the same processing and policies in the gateway.  For these cases, it is possible to setup a single Content Policy for all clients and have Sentry route to the desired back-end based on some client ID.

 

Use Case 

Suppose the following:

1. There are many partners connecting for a similar purpose but need to be routed to different back-end servers.
2. These clients are required to supply their Client ID as ClientID in their request.
3. Client IDs and their corresponding back-end servers are as listed below:

      i. Back-end server A clients are:

Aaaa
Abbb
Accc
Accc

     ii. Back-end server B clients are:

Baaa
Bbbb
Bccc
Bddd

    iii. Back-end server C clients are:

Caaa
Cbbb
Cccc
Cddd

 

Notes:  With the client IDs above there is a common pattern for each group.  Client IDs in each individual group start with the same character.  In fact, the only character in this example that matter is the first.  So, the Client ID could be A***, B***, etc... with varying lengths. This is to further simplify the process and limit the number of Task Lists to be used.

 

Setup Steps

1. Remote Policies

Create a remote policy and check Dynamic EndPOint Routing, setting the user attribute as show below:

    2. Listener Policy

Create the listener policy for this use case.

    3. Content Policy

Create the content policy that uses the above listener and remote policies.

     4. Pattern Match Policy

Create a pattern match policy that will use a RegEx to group all related ClientIDs in individual groups. For example, in our scenario all groups to route to a specific back-end start with the same character.

      5. Task List

Create a Task List that will contain 3 processing tasks:

             a. Map ClientID to a User Attribute

Using the Map from XML Task the client ID value is mapped into a User Attribute of the same name. 

Notes: In this example, the client ID is supplied in the body of the request, which requires that a sample request be used as the sample document.  If the client ID happens to be supplied as a Request Header then the Map Attributes and Headers Task is the choice where the source will be the Request Header in question and target is User Attribute ClientID. The values can come from query parameters as well, or the user attributes may already be defined from an authentication call, db query, or ldap query task.

          b. Pattern Match to Create Individual Groups

Use the Pattern Match Task to run User Attribute ClientID against the Pattern Match Policy to create individual groups:

             c. Map ClientID to Back-end IP:PORT

Use the Mapping Table Task to map each group to the appropriate remote URL:

        6. Attach the Task List to the Content Policy

 

The attached Sentry v8.7 sample FSG (password=password) contains a the above setup.  It can be modified or built upon to address other use cases.

 

For more information on content based routing use cases, see: How To: Content Based Routing - Route Requests Based on Specific Criteria