✎ Security | Documentation

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
By default, care is already taken to ensure that server access is only possible with authentication. If this is not sufficient, additional security measures can be activated in JVx:

==ServletServer==

The ''ServletServer'' is required for communication between a desktop client and the backend. You can completely disable the ''ServletServer'' if you do not use a desktop client or if you don't use ''HttpConnection'' directly.

To restrict the available functions, you can use the following in the config.xml of the Server Zone:

<file xml>
<security>
  <serializedaccess>
    <rules>
      <allow>Session!.*</allow>

      <deny>Session!.createSubSession(*)</deny>
    </rules>
  </serializedaccess>
</security>
</file>

With the above rules, you define that logging in to the server is possible, but creating a sub-connection is not. It is not possible to perform further calls successfully. The deny rules are applied before the allow rules!

===Rule Definition===

A rule is defined by: **ObjectName.MethodName(//[param1[, param2]]//)**

  * The square brackets define optional fields
  * With wildcard notation, you can fine-tune access control

===More Control===

If you need more control, e.g., because you require state-dependent access control, you can achieve this by implementing ''ISerializedCommunicationAccessChecker'':

<file java>
public class CustomAccessChecker implements ISerializedCommunicationAccessChecker
{
    public void init(IServer pServer) 
    {
    }

    public boolean isAccessAllowed(IRequest pRequest, ISession pSession, String pObjectName, String pMethod,
                                   Object[] pParams, ChangedHashtable<String, Object> pProperties, boolean pIsCallBack) 
    {
        if (IConnection.OBJ_SESSION.equals(pObjectName))
        {
            return true;
        }

        if (pSession != null)
        {
            if ("myapplication".equals(pSession.getApplicationName())
            {
                if ("users".equals(pObjectName))
                {
                    return true;
                }
            }
        }

        return false;
    }
}
</file>

You then define the class in the ''config.xml'' of the [[jvx:common:setup:zones|Server Zone]]:

<file xml>
<security>
  <serializedaccess>
    <checker>j.v.x.CustomAccessChecker</checker>
  </serializedaccess>
</security>
</file>

You can define any number of ''checkers''.

Another option is to load your checker using the standard Java Service Loader.

==REST Services==

If you use [[jvx:common:util:rest|REST Services]] to enable access to application data via standard HTTP, such as:

<file xml>
<servlet>  
  <servlet-name>RestletServlet</servlet-name>  
  <servlet-class>com.sibvisions.rad.server.http.rest.RESTServlet</servlet-class>

  <init-param>
    <param-name>org.restlet.application</param-name>
    <param-value>com.sibvisions.rad.server.http.rest.RESTAdapter</param-value>
  </init-param>
</servlet>  

<servlet-mapping>  
  <servlet-name>RestletServlet</servlet-name>  
  <url-pattern>/services/rest/*</url-pattern>  
</servlet-mapping> 
</file>  

then you can disable individual services.

===Admin Services===

Disable admin services in general:

<file xml>
<init-param>
    <param-name>adminservices.available</param-name>
    <param-value>false</param-value>
</init-param>
</file>

Admin services are enabled by default.

To disable individual services:

<file xml>
<init-param>
    <param-name>adminservice.NAME.enabled</param-name>
    <param-value>false</param-value>
</init-param>
</file>

Predefined Admin Services:

  * checkDB
  * changePassword
  * testAuthentication
  * memoryStatus

To disable all admin services:

<file xml>
<init-param>
    <param-name>adminservices.enabled</param-name>
    <param-value>false</param-value>
</init-param>
</file>

===Custom Admin Services===

In JVx, it is possible to extend admin services. These are then called custom admin services. To disable them:

<file xml>
<init-param>
    <param-name>adminservice.NAME.enabled</param-name>
    <param-value>false</param-value>
</init-param>
</file>

==Life-cycle Objects==

Business logic is defined in [[jvx:server:lco:lifecycle|Life-cycle]] objects. Default security ensures that all public methods are callable. If you change a method to ''protected'' or ''private'', it is no longer callable, e.g.:

<code java>
protected IDBAccess getDataSource() throws Exception
{
    ...
}
</code>

However, if a method must be ''public'', you can protect it from external calls using an annotation:

<code java>
@NotAccessible
public IDBAccess getDataSource() throws Exception
{
    ...
}
</code>

Details on ''@Accessible'' and ''@NotAccessible'' can be found [[jvx:server:lco:accessible_notaccessible|here]].

==Object-specific Calls==

If you want to control specific accesses in your application, you can achieve this by implementing [[jvx:server:security:object_method_access|IObjectAccessController]]. This interface is checked every time a [[jvx:server:lco:lifecycle|Life-cycle Object]] is called. This allows fine-grained control at the instance level.

Access control for REST only works for REST calls, and access control for ''ServletServer'' only works when an ''HttpConnection'' is used. Using the [[jvx:server:security:object_method_access|IObjectAccessController]] works independently of this.

==Environment-dependent Access==

If you work with Accessible and NotAccessible, you can also control access per environment, as described [[jvx:server:lco:accessible_notaccessible|here]].

==Checklist==

  * Disable ''ServletServer'' or restrict calls
  * Completely disable [[jvx:common:util:rest|REST Services]] or only enable individual services
  * Check [[jvx:server:lco:lifecycle|Life-cycle Objects]] (public, protected, private) and verify the use of ''@NotAccessible''
  * Environment-dependent use of ''@Accessible'' and ''@NotAccessible''