~~Title: Security~~

By default, care is already taken to ensure that object 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:actions_in_objects|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''