Axional Server can be configured with diferent login methods, depending on the service and the desired level of security. At least, there are three services and each one can have it's own authentication model

  • HTTP context for regular web pages
  • SOAP context for SOAP services
  • REST context for RESTful services

1 Security

The server can be setup up managing these three contexts, each one with its own login service.

Service Context Authentication
Web apps - web applications interface / BASIC, FORM, CERT
Rest - a RESTful service implementation /rest BASIC, DIGEST, CERT
SOAP - a SOAP service implementation /soap BASIC, DIGEST, CERT

FORM and BASIC authentications are unsecure over non SSL protocol cause the password is transfered using plain text or base64 encoded text.

You can setup the server to deal with two types of transport guarantee:

  • NONE - no security using plain http
  • CONFIDENTIAL - required https

2 Authenticators

Server can be configured to use any of the following Authentication mechanims.

  • FORM
  • CERT

Not all login configurations can be accepted as they depend on the password validation mechanims. The following table shows the compatibility. For example, the password must be received using plain text when it needs to be checked againts LDAP. Let's see the following table:

Auth Password validation Sessions Secure
Type Salt wic_conf LDAP External Clustering HTTP HTTPS
BASIC No            
DIGEST No            
FORM Yes            
DIGEST (rfc 2617) No            

We can now check some cases according the above table

  • Let us consider a SOAP client service that we want to connect to Axional Studio using DIGEST auth. We can do it with standard authentication (wic_conf:wic_user) as we store a digested HA1 copy of password. But we can not do a LDAP challenge to valdiate the password received from DIGEST auth cause remote LDAP will not accept the digested token as a valid password.

2.1 Authentication vs Services


This section is incomplete and will be concluded as soon as possible.
WEB  (?)    

2.2 Authentication vs Validation origin


This section is incomplete and will be concluded as soon as possible.
INTERNAL (wic_conf)     (*)  


Depends on how the password is stored inside the wic_conf. See the table Authentication vs Stored password

2.3 Authentication vs Stored password


This section is incomplete and will be concluded as soon as possible.

2.4 BASIC Authenticator


This section is incomplete and will be concluded as soon as possible.

When a Studio node is configured to use BASIC authentication, each user credentials will be checked for each request, using the standard HTTP header:

Authorization: Basic xdXN1s1cjp122Vy1TIf

2.5 SSO Authenticator


This section is incomplete and will be concluded as soon as possible.

The SSO mode allows configuring a Studio server behind a proxy in such a way that user credentials validation is delegated to that proxy server. So, no login page is presented to users on the Studio server. It is the proxy which is responsible of asking and validating user credentials. If access to Studio for a particular user should be grant then the proxy will redirect the user requests by adding valid Authorization headers.

When a Studio node is configured to use SSO (Single Sign On) authentication the same rules as for BASIC authenticator applies, except that user credentials are not validated against the configuration database (wic_conf). Instead of that, the credentials supplied must match the password specified in the server configuration file.

<?xml version="1.0" encoding="UTF-8"?>
<server name="studio">
    <application xmlns:xsi="" xsi:type="studioConfig">
        <singleSignOnSecret>CRYPT-AES256:11PrCw41ssguFI2gfms6fXnnhexYxKrzwdKxo2zYFmx2DMYWiut77Ib3dz7TB4xzVoq4YuPxShYp</singleSignOnSecret> <!--mySh4r3dPass-->

For example, if the previous configuration is used, each request providing user credentials with an auth header corresponding to the password "mySh4r3dPass" (for each user!) will be accepted. So, the "SSO secret string" configured should be kept handled with care, sharing it only with the external application which is managing the user authentications.

2.6 DIGEST Authenticator


This section is incomplete and will be concluded as soon as possible.

User passwords are stored in the database table named 'wic_user' as HA1 part of digest algorithm.

A group of servers sharing the same configuration database must have the same realm. If a server has adiferent realm, it will not be able to validate users, cause it's hash will not match.

Changing realm

Changing the realm makes all user passwords thar are stored in the wic_conf.wic_user to become not valid, for the server within the new realm.

2.7 FORM Authenticator


This section is incomplete and will be concluded as soon as possible.

2.8 CERT Authenticator

CERT authenticator can be enabled by setting a server trustKeyStore. Then, only clients with valid certificates signed by that server, are allowed to sign in.


Main stepss to configure the CERT authenticator should be:

  • Create self-signed Root CA that will be used as server certificate.
    openssl genrsa -des3 -out Root_CA.key 4096
    openssl req -new -x509 -days 1000 -key Root_CA.key -out Root_CA.crt
  • import the CA public certificate Root_CA.crt into the truststore.jks
  • Create the end user's certificate using the previously created CA certificate and its private key.
    1. Create the end user's private key
      openssl genrsa -des3 -out end_user_testuser_private.key_encrypted 4096
    2. Create end user's certificate signing request using the private key
      openssl req -new -key end_user_testuser_private.key_encrypted -out end_user_testuser_cerfiticate_request.csr
    3. Create the end user's certificate using the CSR
      openssl x509 -req -days 1000 -in end_user_testuser_cerfiticate_request.csr -CA Root_CA.crt -CAkey Root_CA.key -set_serial 00001 -out end_user_testuser_cerfiticate.crt
    4. Create the PKCS#12 package from the private key and from the certificate.
      openssl pkcs12 -export -out end_user_certificate_and_private_key.pfx -inkey end_user_testuser_private.key_encrypted -in end_user_testuser_cerfiticate.crt
  • In the browser, import the CA public Certificate Root_CA.crt into CA Entities and grant all rights
  • In the browser, import user certificate end_user_certificate_and_private_key.pfx into the Personal certificates area

2.9 External token

The external token auth allows a user accessing the application without explicitly entering their credentials. Access to the application will be possible by providing a URL address containing a valid token. The user should be registered in the "wic_user" master table on the configuration DB (as any other user)

The following different information fragments will be involved in the token generation:

  • The target user credentials, including both user code and password.
  • A timestamp acting as the expiration time for the token.
  • The "secret" password agreed by our application and the external agent which is generating the token.

The "secret" agreed by the two part should be configured in the Axional Server instance where the external authentication should be available. A tag "externalAuth" should be included in the "config.xml" file with the AES-crypted value of the password.

For example, to generate a token string from an Axional Studio instance we should run the following XSQL-Script:

        <arg><expression>CURRENT + 1 UNITS MONTH</expression></arg>
        <arg name='p_user'      type='string'       />
        <arg name='p_pass'      type='string'       />
        <arg name='p_expiry'    type='timestamp'    />
        <arg name='p_secret'    type='string'       />
		<set name='m_plain' type='string'>
				<p_user />
				<p_pass />
				<date.getTime><p_expiry /></date.getTime>

		<set name='m_crypted' type='string'>
			<crypt.aes.encrypt.password password='${p_secret}' keyLength='128'>
				<m_plain />

				<m_crypted />

The parameters used correspond to:

  • The target user code
  • The target user password
  • The timestamp value for token expiration
  • The agreed password, not crypted

The authentication into the application will be performed by the endpoint "/account/login/external". For example, if the calculated token is:

CRYPT-AES128:EO32+S8vhuli1CFaCsS3gsKMfj7ZV7dEt2ruiNfqfwSpBLyWLVex/ufFVSS4AILXb/1sK6BiOZWd ZQVQHsSwHDSvdx+qJvxU5Q==

and the target location is "/desired/location/address"

then the URL which can be used by the user is (note that token value was encoded):


3 Authentication

The user authentication process is done in three steps: authentication method handshake, credential validation and identity validation.


3.1 Authenticator

The Authenticator is responsible to get the user identity and credentials, and transport them to the server. Each server can be configured to use one authentication method that can be BASIC, DIGEST, FORM or CERT.

3.2 Credential validation

The credential validation can be configured to be performed in different ways.

  • Standard authentication - Against the password stored in the central configuration wic_conf.wic_user table, using the digest $$HA1=md5(username:realm:password)$$
  • LDAP authentication - This consists of sending to the LDAP server the fully qualified DN of the client (user) and the client's clear-text password. To avoid exposing the password in this way, we use the simple authentication mechanism within an encrypted channel (such as SSL), provided that this is supported by the LDAP server.
  • External auhentication valve - This consists of a custom application that may call a centralized authorization service. It's coded using XSQL scripting.
  • Token auhentication - a login token is a unique identifier generated by the system that allows it's owner, to login with it. Once the tokens is validated, the user associeted with the token is determined. The token contains several properties to allow to auto expiry it, like login counts and a validity period. Tokens are stored in the wic_conf:wic_user_token_login table.

3.3 Identity validation

Every user in Axional Studio must have a record entry, representing its definition, inside the wic_user configuration table. The Authentication process may use a password stored in this table or an external mechanism like LDAP. But in any case, a user is only known to the system if it has a record entry in the wic_user.

3.3.1 wic_user

The standard authenticacion mechanism validates the password against the stored password in wic_user. Passwords by default are stored obfuscated OBF. There are, however other options supported to store the password:

  • Plain - Plain text password. This option is highly unsecure and not recommended
  • MD5-HA1 - The password is stored following protocol RFC 2617 MD5(username:realm:password)


This section is incomplete and will be concluded as soon as possible.

3.3.2 LDAP


This section is incomplete and will be concluded as soon as possible.

3.3.3 Custom valve


This section is incomplete and will be concluded as soon as possible.

3.3.4 Token auth

Authentication tokens are a mechanism to allow login to a system without using username. The token, if valid, specifies the username and the restrictions to apply. Tokens are stored in two tables in the wic_conf database.

  • wic_user_token_login: login as user identified by the token

  • wic_user_token_process: execute a process using the code and the user specified by the token

In both cases the token is unique and it is assigned to one user only. The user has roles, authorizations and restrictions configured in the database wic_conf. The user can use the token at the connection URL which offers access to the remote site. The token is valid for a time period, while after the token expires it can not be reused.

Login tokens

Allow users to access to the application without using their username and password (without login previously). The user can use the token at the connection URL which offers access to the remote site. The token is valid for a time period, after the token expires it can not be reused.

Column Type Size Not null Label Description
user_code User User code
token_group Group Group of Access Control
token_protocol Protocol Protocol

  • Default: 0
  • Values:
    • 0: ALL.
    • 1: HTTP.
    • 2: SOAP.
token_soap_uri SOAP URI Available URI for SOAP access
token_hash Hash token The token value that you define in this field must be included in the URL adding the attribute token, for example:

token_locked Token locked Token locked

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
token_expires Expiry of hash Date and time of hash expiration
token_created Date created Registration date

  • Default: CURRENT
token_last_login Last login Date amnd time of the last login
token_login_count Login counter Login counter

  • Default: 0
token_expired_count Unauthorized accesses Number of times that this token was used to try access after that the validity had expired

  • Default: 0

This token can be generated by two methods:

  • Directly adding a new entry to the table wic_user_token_login in the wic_conf database.
  • Using the XSQL-Script tag webapp.token.login.getNewURL.

Process tokens

These allow the users to execute a XSQL-Script resource of the application, without using their username and password (without do login previously). This token mode only grants the user to execute this resource. After the process is finish the user is automatically logged out.

Column Type Size Not null Label Description
user_code User User code
token_group Group Group
token_hash Token hash Token hash
token_created Date create Date create

  • Default: CURRENT
token_expires Expiry of hash Expiry of hash
token_dbms Database name Database name
token_xsql_code XSQL Code XSQL Code
token_xsql_args XSQL Arguments XSQL Arguments
token_locked Token Locked Lock Tocken

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
token_last_process Last login Last login
token_process_count Login Counter Login Counter

  • Default: 0
token_expired_count Unauthorized accesses Unauthorized accesses

  • Default: 0
token_xsql_type Arguments Type Arguments Type
token_process_status Status Status
token_process_time Process Time Process Time
token_process_return Process return Process return

This token can be generated by two methods: