What is new in Sentinet version 6.3
Sentinet configuration was extended to support “one-click” virtualization feature through a new concept of Virtualization Profiles. A Virtualization Profile’s configuration combines information of selected Sentinet Node, its selected base address, selected security policy and selected Access Rule. Users can create any number of pre-configured Virtualization Profiles for REST APIs and SOAP services, and use them to quickly virtualize physical services with “one-click”.
Figure. Example of virtualization profiles created for REST APIs and SOAP services. To quickly virtualize any physical service version, user can click VIRTUALIZE toolbar button (or right-click and select Virtualize pop-up menu option) and confirm creation of a fully functional virtual service with just one click on OK button.
Figure. Confirming virtualization of a physical REST API through default REST – HTTPS virtualization profile. Virtual services’ design was extended with inbound and outbound endpoint’s identities for OAuth credentials. Previously these identities (OAuth secrets) where configured inline and in clear text in the Policies’ XML. This is still possible and available, but explicit assignment of OAuth identities to the outbound endpoint(s) allows to hide OAuth secrets from being exposed in the UI, and decouples XML Policy configuration from the OAuth secrets usage.
Figure. Add Identity dialog box extended with OAuth Client Credentials for outbound endpoint Sentinet Repository was extended with new entity type, Identities. Identities are stored in Repository folders just like any other Repository entities, and they represent shared identities which can be configured with virtual or physical service endpoints. For example, a Username/Password identity can be registered with Sentinet Repository as a shared identity and configured with more than one outbound endpoint of many virtual services.
Figure. Example of registered shared identities and different identity types which can be registered Shared identities provide more secure way for their usage, controlled visibility and modification. Any changes to Identities are audited just like any other Repository entities. Identities’ dependencies allow to track which services use them.
Figure. Example of Identity Dependencies diagram. Sentinet Repository was extended with new entity type, Access Rule Group. An Access Rule Group represents an ordered list of other Access Rules and/or other Access Rule Groups. Access Role Groups simplify management of complex access rule scenarios where common set of access rules must be applied along with specific Access Rules. Access Rule Groups can be applied to virtual services Access Control, and they can be a filter for Service Agreements.
Figure. Example of an Access Rule Group that consists of two Access Rules and one Access Rule Group. Sentinet Pipeline Designer was extended with the new Custom Code component. Custom Code component is very similar to a generic Custom pipeline component, except that its code is entered inline in component’s configuration, and does not require any up-front compilation and deployment of a custom assembly. Custom Code component is best suited for custom extensibility that requires reasonably little of custom C# code that can fit in a single C# method.
Figure. Example of a Custom Code component that creates custom HTTP Header with custom Date/Time formatting, such as XDate: Tue, 30 Mar 2021 17:44:43 GMT Context Property pipeline component was extended with JSON Path extractor that can extract JSON content based on JSONPath syntax.
Note
Existing JSON Pointer extractor’s representation in XML source was renamed from <EXTRACT-JSON> element to <EXTRACT-JSON-POINTER> element. This renaming does not cause backwards compatibility issue unless customers want to use pipeline‘s XML source created with older naming convention with Sentinet 6.3 or higher version.
Figure. JSON Path extractor for pipeline’s Context Property. Sentinet Monitoring Masking Filter was extended with <JSON-PATH-REPLACE> element. In addition to existing content replacement elements, <JSON-PATH-REPLACE> allows to replace content based on JSONPath syntax.
Figure. Example of <JSON-PATH-REPLACE> element in the Masking Filter. Note
Existing <JSON-REPLACE> element used for JSON Pointer syntax by the previous Sentinet versions was renamed to <JSON-POINTER-REPLACE> element. Sentinet upgrade to newer version(s) will automatically rename elements appropriately causing no backwards compatibility issue for existing upgraded configurations.
Extended Sentinet Monitoring Filters with <CUSTOM-FILTER> element to support custom filtering of the recorded messages. Sample Visual Studio .NET project, CustomMonitoringFilter was added to demonstrate two simple custom Monitoring Filters.
Figure. Example of two Custom Filters injected before and after Masking Filter. Extended processing of internal errors generated by Sentinet Nodes with the capability to add custom error handler. New sample project, CustomErrorHandler was added to distributed samples.
Figure. Example of a custom error handler configured to process errors generated by Sentinet Nodes. Extended Access Rules Designer and runtime Authorization Engine with validation based on JSON Path expression.
Figure. JSON Path expression Added new permissions to custom User Roles to view or modify Virtualization Profiles and shared Identities.
Figure. New permissions added Extended runtime to pass-through HTTP Response headers, which are explicitly defined in RESTful API responses.
Extended selection of shared Policies for the endpoints by filtering policies by their fitness to service shape (REST or SOAP) and transport protocol. Provided different icons for REST and SOAP policies.
Figure. Different icons for REST and SOAP policies and pre-filtered policies that match service shape and endpoint transport. Changed default behavior for outbound Basic Authentication policy to send Basic Authentication HTTP headers without waiting for the challenge from a physical service.
Extended Repository Search with searches for new entity types, shared Identities and Access Rule Groups.
Provided special marking icon for service operations that have their own individual Messages Pipeline configured at operation level.
Figure. Operation marked to have its own individual Messages Pipeline. OAuth tracing, Access Rules tracing and Pipeline tracing settings were moved from PROCESSING -> SETTINGS tab to MONITORING -> CONTROL -> TRACING tab.
Figure. New location of the Tracing settings. User Preferences were extended with First day of week is Monday checkbox. The checkbox allows to control first day of a week (Sunday or Monday) for Sentinet Administrative Console drop down calendars and Dashboard Reports that use This week as the selected time period.
Figure. First day of week is Monday checkbox. Node Instances Synchronization feature was extended with optional syncFileName configuration attribute to support optional custom file name for the synchronization file. For example:
<configuration> … <nevatech.vsb.runtime> … <instanceSynchronization enabled="true" maxLockWaitTime="300" waitTimeBeforeUpdate="60" waitTimeAfterUpdate="60" syncFilePath="c:\SyncFolder" syncFileName=”Sentinet.sync”/> … </nevatech.vsb.runtime> </configuration>Provided separate Power Shell script to execute minimal and optional installation prerequisites.
Extended Sentinet Developer Portal to support Single Sign-On during Developer Portal Sign Up and Log In through an external OpenID Connect or WS-Federation authentication provider such as Azure Active Directory (AAD), Active Directory Federation Services (ADFS), Okta, Google, etc. More than one external provider can be configured with the Sentinet Developer Portal, and integration with them can be customized.
Figure. Example of the Sentinet Developer Portal Log In page with configured authentication via Azure Active Directory, Okta, Google and Microsoft ADFS provider.