Create a Custom Rule Expression

A custom access rule expression is a regular .NET component that implements the IMessageEvaluator interface (ref. Nevatech.Vbs.Repository.dll). This inteface contains three methods:

• Evaluate – Where to put the access rule logic.
• ImportConfiguration – Read the (and apply) the component’s configuration.
• ExportConfiguration – Save the component its configuration.

In this example I’m going to define a component for evaluating an APIKey sent in a custom header (for SOAP services) or as a part of the service URL (for REST services).

As shown in the figure below, the implementation is pretty straightforward.

• the getSecurityContext method evaluates the System.ServiceModel.Channels.Message object to read the APIKey
• the isValidKey method evaluate the key.
• the properties ServiceName and isRest are set with the values specified in the componet configuration.

Here the simple implementation for reading the component configuration.

In this example the API Key is validated against an SQL table. A stored procedure with two parameters evaluates whether the key has access to the specific service.

Register

First step is to copy the dll(s) to the Sentinet node(s). In this case, notice that it’s not mandatory to sign the assembly and register to the GAC. I simply create a bin folder in my Sentinet node and I copied the dlls.

The custom component can be registered and graphically configured using the Sentinet Administrative Console.Click on the AccessRule node, Add new Access Rule, then at the bottom of the rule designer press Add..

Five parameters need to be specified:

• Name. The fiendly name of the custom rule expression (APIKey)
• Assembly. The fully qualified assembly name that contains the custom rule expression (Codit.Demo.Sentinet.AccessControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null)
• Type. The .NET class that implement the IMessageEvaluator interface (Codit.Demo.Sentinet.AccessControl.APIKeyValidator)
• IsReusable. Set it to true if your component is thread-safe. The Sentinet Authorization Engine will
  create and use a single instance of this component.
• Default Configuration. The default configuration. In this example I let it blank and I will specify the parameters when I use expression in a specific Access Rule

Test

First I created a SOAP and a REST virtual service that virtualize the Offer backend service (SOAP). Then I defined a couple of access rules using the new APIKey Custom Access Rule Expression and I applied those rules to the Virtual Service using the Access Control tab.

In this example the service name is passed to the Expression through a configuration parameter but a better solution would be to extract it from the Message class. 

For this example I defined few API keys in the SQL table.

The SOAP scenario has been tested with soapUI. Depending on the value returned by the Evaluate method the virtual service returns different objects:

• True => Access granted, the response message is returned.
• False => Generic Access denied via Soap Fault.
• Exception => Custom Exception via Soap Fault.

The REST scenario has been tested with Fiddler. Depending on the value returned by the Evaluate method, the virtual service returns different HTTP codes:

• True => HTTP 200
• False => HTTP 403
• Exception => HTTP 500

Finally, below, you can see how the test results are presented in the Sentinet Monitoring tab.

Conclusion

The Sentinet extensibility model is intended to support custom scenarios by enabling you to modify the platform behavior at different levels.In this post I have discussed how to extend the Access Rule engine with an additional authorization component.

Cheers,

Massimo