Comment on page
Security Settings
Project Security Setting Options
Certificate Manager
WEM allows you to manage several kinds of Security Certificates in your project. These are certificates you typically use to either authenticate your portal to an external service, or to define whose certificates you trust and allow to access your portal.
- Client Certificates: These are certificates you use to authenticate your portal to an external service. This certificate must be provided (uploaded or by using the self-signed option) including the private key, because that is the part that makes sure that the external party (who only gets the public part) can be sure that you are who you say you are.
- Server Certificates: These are certificates again including the private key, which are used on a server level to indicate that the server providing the Portal can be trusted. This is also typically used when you use a Client Certificate that is provided or signed by a different server or authentication provider that may not be a global trusted Certificate Authority - in that case, providing that specific certificate including the private key, makes sure that when you use the Client Certificate - the external party can trust that Certificate because the server certificate is also provided with private key - indicating that you are you you say you are.
- Trusted Clients: These are the certificates that contain only the public part of external clients, that you choose to trust, for example when they access your custom endpoints or webservices that you can make secured using Client Certificates. The external clients that you want to trust and give access, should provide the public parts of their certificates to you so you can add them to your Project. When these clients then access the endpoint of your portal that is secured with certificates, they need to use their certificate (wiprivate key) to sign the request.
- Trusted Servers: These Trusted Server certificates hold the public parts of certificates that may be part of the Certificate Chain of a Trusted Client Certificate - and they also need to be trusted if they are "custom" (not on global trust lists). These are typically certificates that are used as Certificate Authority or Intermediate. In the case when a Trusted Client Certificate uses Custom Certificates in its Chain, it can only be fully trusted if all certificates in the chain are added to the Trusted Servers.
Some examples of certificates
WEM offers a way to allow or deny access to your project based on the IP-address of the client trying to gain access. This is also known as Whitelisting (allow specific IP addresses) or Blacklisting (block specific IP addresses).
Manage IP restrictions
Each rule is checked in the order as displayed. If the order needs to be changed, select a row by clicking the left-most edge of the row and see it highlighted or indicated, then use the Move Up or Move Down buttons in the toolbar.
Each rule has the following properties:
- Action: either allow or deny;
- Name: the name you give the rule to identify it;
- Start IP address: the starting IP-address of a possible range;
- End IP address: the ending IP-address of a possible range;
- if both Start and End IP are the same, that indicates that one specific IP address;
- Ranges should have the same first segments and only differ in the last segment to make a correct range;
- Portal: you can define for which specific portal this rule must be checked, or apply it to all portals;
- Runtimes: you can define for which Runtime environments this rule must be checked: preview/staging/live, or apply it to all runtimes;
- Endpoint: you can define for which Endpoint this rule must be checked: OData service endpoints, Webservice endpoints, or WEM (normal portal usage via browser).
If you want to have rules applied properly, and only the rules that you have defined, you need to add a final rule to close:
- Use the Allow all remaining connections if you are using a Blacklist approach - all other rules before this one are Deny-rules.
- Use the Deny all remaining connections if you are using a Whitelist approach - all other rules before this one are Allow-rules;
When these rules are set up or changed, you need to Publish the project to the targeted Runtimes for the rules to come in effect. These rules will then be applied just before the portal is actually reached.
There is also another option to specifically check the IP-address of the user trying to access your portal. In case you want to do something even more finegrained: use the function
IpAddress() in an expression. The value will be something like "123.12.12.125" in text form, so you can use any available text-based comparison function to decide what to do.
WEM provides integration according to the OData Protocol. This way, any data that you have in staging or live runtime environment, can be made available to external applications that are able to retrieve data using OData, like Excel or BI tools. The WEM OData Logins security settings allow you to specifically define which data can be accessed with certain logins and what they can do.
Managing OData logins
You start by creating a username and password.
NOTE: the password is encrypted and not retrievable, so make sure you store it somewhere safe!
Next, you specify on which portal the access should be granted (any specific portal, or all portals).
Finally you define to which resources this login has access and which actions are allowed:
OData Restricted Access options
Last modified 1yr ago