Restricting access to web services for portal users
Glossary Item Box
Introduction
The portal is a Creatio platform component whose main purpose is to implement self-service processes for your customers and partners. You can also use the portal to organize the work of internal users if you need to restrict access permissions to functionality of the primary application.
Using portal enables many external users (who are not employees of your organization) to access some of the Creatio data. For this, you need to manage which users (portal or company employees) have access to the application web services.
ATTENTION
This article is valid for applicaation version 7.13.2 and up.
NOTE
More information about creating a custom configuration web service is available in the “Configuration service development” article.
Route prefixes for web services configuration
Route prefixes in Creatio enable managing access to the application web services. You can set the needed route prefix using specific ServiceRoute attributes of the service class (table 1).
Table 1. Route prefixes for configuration web services
Access level | Attribute | Route prefix | Example of code |
---|---|---|---|
For self-service portal users only | SspServiceRoute | /ssp |
[ServiceContract] [SspServiceRoute] public class SspOnlyService : BaseService { } Example of call ~/ssp/rest/SspOnlyService ~/ssp/soap/SspOnlyService |
For internal users only |
DefaultServiceRoute or no ServiceRoute attribute is specified |
none |
[ServiceContract] public class InternalService : BaseService { } or [ServiceContract] [DefaultServiceRoute] public class InternalService : BaseService { } Example of call ~/rest/InternalService ~/soap/InternalService |
For both: the internal and portal users |
Both the DefaultServiceRoute and SspServiceRoute |
/ssp or none |
[ServiceContract] [DefaultServiceRoute] [SspServiceRoute] public class CommonService : BaseService { } Example of call ~/rest/CommonService ~/soap/CommonService ~/ssp/rest/CommonService ~/ssp/soap/CommonService |
The ServiceRoute attribute with the specified prefix (e.g., "custom”) [ServiceRoute("custom")] |
Arbitrary route prefix of the service |
[ServiceContract] [ServiceRoute("custom")] public class CustomPrefixService : BaseService { } Example of call ~/custom/rest/CustomPrefixService ~/custom/soap/CustomPrefixService |
NOTE
You can use several attributes at the same time: ServiceRoute, SspServiceRoute and DefaultServiceRoute. As a result, the routes for services with all prefix variants will be created.
Restricting access to the internal API for portal users
If a portal user (SspUserConnection) addresses a service with a route that does not contain the “/ssp” prefix, the service will return error 403 (Forbidden).
Restricting access to the portal API for internal users
If an internal user (UserConnection) addresses the service with the route that contains the “/ssp” prefix, the service will return a page with code 403 (Forbidden).
Changing access to the base service
The application has a set of base services and only internal users have access to them.
To change access to the base service:
- In the custom package, create a service with the access settings for portal users.
- In the service, add the base service methods that must be available for portal users.
- Change the custom or extend the base client schemas by changing the call of base service to the call of the created service (see step 1).
- Compile the configuration.
Example of the service source code that extends access to the ActivityUtilService base service:
namespace Terrasoft.Configuration { using System; using System.IO; using System.Runtime.Serialization; using System.ServiceModel; using System.ServiceModel.Activation; using System.ServiceModel.Web; using Terrasoft.Configuration.FileUpload; using Terrasoft.Core.Factories; using Terrasoft.Web.Common; using Terrasoft.Web.Common.ServiceRouting; [ServiceContract] // The service is available for both: the internal and portal users [DefaultServiceRoute] [SspServiceRoute] [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)] public class PartnerActivityUtilService: BaseService { // Base service, access needs to be extended private static readonly ActivityUtilService _baseService = new ActivityUtilService(); [OperationContract] [WebInvoke(Method = "POST", BodyStyle = WebMessageBodyStyle.Wrapped, RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json)] public Guid CreateActivityFileEntity(JsonActivityFile jsonActivityFile) { return _baseService.CreateActivityFileEntity(jsonActivityFile); } [OperationContract] [WebInvoke(Method = "POST", BodyStyle = WebMessageBodyStyle.Wrapped, RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json)] public Guid CreateFileEntity(JsonEntityFile jsonEntityFile) { return _baseService.CreateFileEntity(jsonEntityFile); } } }
The ServiceStack core services
The ServiceStack core services (DataService, ManagerService, etc.) are available by default to the internal users only.
To make any of these methods available on the portal, tag such method with the SspServiceAccess attribute – in this case, the method will have an additional route with the ~/DataService/ssp/… prefix.
If you need to have a different logic for the portal, create a new service by specifying the SspServiceAccess attribute for it and pass the name of the original method to its constructor. Example:
[SspServiceAccess(nameof(SelectQuery))] public class SspSelectQuery : SelectQuery { }
This service creates a contract whose method will be registered at the following path:
~/DataService/ssp/SelectQuery
Access to the ServiceStack methods with the “ssp” prefix is denied to the internal users. Access to the ServiceStack methods without the “ssp” prefix is denied to the portal users.