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

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

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

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

• BASIC
• DIGEST
• 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:

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.

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

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="http://www.w3.org/2001/XMLSchema-instance" xsi:type="studioConfig">
        ...
        <singleSignOnSecret>CRYPT-AES256:11PrCw41ssguFI2gfms6fXnnhexYxKrzwdKxo2zYFmx2DMYWiut77Ib3dz7TB4xzVoq4YuPxShYp</singleSignOnSecret> <!--mySh4r3dPass-->
        ...
    </application>
</server>

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.

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.

sslContextFactory.setTrustStorePath(TRUSTSTORE_FILE);
sslContextFactory.setTrustStorePassword(TRUSTSTORE_PASS);
sslContextFactory.setWantClientAuth(true);

Main stepss to configure the CERT authenticator should be:

• Create self-signed Root CA that will be used as server certificate.
  Copy

  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
     Copy

     openssl genrsa -des3 -out end_user_testuser_private.key_encrypted 4096

  2. Create end user's certificate signing request using the private key
     Copy

     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
     Copy

     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.
     Copy

     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

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:

<call>
    <args>
        <arg>usercode</arg>
        <arg>user123</arg>
        <arg><expression>CURRENT + 1 UNITS MONTH</expression></arg>
        <arg>MySuperSecretString</arg>
    </args>
<![CDATA[
<xsql-script>
    <args>
        <arg name='p_user'      type='string'       />
        <arg name='p_pass'      type='string'       />
        <arg name='p_expiry'    type='timestamp'    />
        <arg name='p_secret'    type='string'       />
    </args>
	<body>
		<set name='m_plain' type='string'>
			<add>
				<p_user />
				<string>:</string>
				<p_pass />
				<string>:</string>
				<date.getTime><p_expiry /></date.getTime>
			</add>
		</set>

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

		<return>
			<add>
				<string>CRYPT-AES128</string>
				<string>:</string>
				<m_crypted />
			</add>
		</return>
	</body>
</xsql-script>
]]>
</call>

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):

https://localhost:8080/account/login/external?auth=CRYPT-AES128%3AEO32%2BS8vhuli1CFaCsS3gsKMfj7ZV7dEt2ruiNfqfwSpBLyWLVex%2FufFVSS4AILXb%2F1sK6BiOZWd%20ZQVQHsSwHDSvdx%2BqJvxU5Q%3D%3D&target=/desired/location/address

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

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.

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.

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.

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)

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.

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.

<table>
   <tr>
       <th colspan='6'>wic_user_token_login</th>
   </tr>
   <tr>
       <th>Column</th>
       <th>Type</th>
       <th>Size</th>
       <th>Not null</th>
       <th>Label</th>
       <th>Description</th>
   </tr>
   <tr>
       <td>user_code</td>
       <td>User</td>
       <td>User code</td>
   </tr>
   <tr>
       <td>token_group</td>
       <td>Group</td>
       <td>Group of  Access Control</td>
   </tr>
   <tr>
       <td>token_protocol</td>
       <td>Protocol</td>
       <td>        <br/><br/>
    <ul>      <li>Default: 0</li>      <li>Values:        <ul style='margin: 0; padding-left: 20px;'>
        <li>
0: ALL. </li>
        <li>
1: HTTP. </li>
        <li>
2: SOAP. </li>
         </ul>
       </li>     </ul></td>
   </tr>
   <tr>
       <td>token_soap_uri</td>
       <td>SOAP URI</td>
       <td>Available URI for SOAP access</td>
   </tr>
   <tr>
       <td>token_hash</td>
       <td>Hash token</td>
       <td>The token value that you define in this field must be included in the URL 
adding the attribute <b>token</b>, for example:
<br/><br/>
<![CDATA[http://web1/servlet/jrep?code=cdiarios&user=direct-user&dbms=demo_sports&cond=1%3D1&meta=&sort=codigo&ltoken=TEST-TOKEN-DIRECT-USER]]></td>
   </tr>
   <tr>
       <td>token_locked</td>
       <td>Token locked</td>
       <td>        <br/><br/>
    <ul>      <li>Default: 0</li>      <li>Values:        <ul style='margin: 0; padding-left: 20px;'>
        <li>
1: Yes. </li>
        <li>
0: No. </li>
         </ul>
       </li>     </ul></td>
   </tr>
   <tr>
       <td>token_expires</td>
       <td>Expiry of hash</td>
       <td>Date and time of hash expiration</td>
   </tr>
   <tr>
       <td>token_created</td>
       <td>Date created</td>
       <td>Registration  date        <br/><br/>
    <ul>      <li>Default: CURRENT</li>     </ul></td>
   </tr>
   <tr>
       <td>token_last_login</td>
       <td>Last login</td>
       <td>Date amnd time of the last login</td>
   </tr>
   <tr>
       <td>token_login_count</td>
       <td>Login counter</td>
       <td>        <br/><br/>
    <ul>      <li>Default: 0</li>     </ul></td>
   </tr>
   <tr>
       <td>token_expired_count</td>
       <td>Unauthorized accesses</td>
       <td>Number of times that this token was used to try access after that the validity had expired        <br/><br/>
    <ul>      <li>Default: 0</li>     </ul></td>
   </tr>
</table>

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.

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.

<table>
   <tr>
       <th colspan='6'>wic_user_token_process</th>
   </tr>
   <tr>
       <th>Column</th>
       <th>Type</th>
       <th>Size</th>
       <th>Not null</th>
       <th>Label</th>
       <th>Description</th>
   </tr>
   <tr>
       <td>user_code</td>
       <td>User</td>
       <td>User code</td>
   </tr>
   <tr>
       <td>token_group</td>
       <td>Group</td>
       <td></td>
   </tr>
   <tr>
       <td>token_hash</td>
       <td>Token hash</td>
       <td></td>
   </tr>
   <tr>
       <td>token_created</td>
       <td>Date create</td>
       <td>        <br/><br/>
    <ul>      <li>Default: CURRENT</li>     </ul></td>
   </tr>
   <tr>
       <td>token_expires</td>
       <td>Expiry of hash</td>
       <td></td>
   </tr>
   <tr>
       <td>token_dbms</td>
       <td>Database name</td>
       <td></td>
   </tr>
   <tr>
       <td>token_xsql_code</td>
       <td>XSQL Code</td>
       <td></td>
   </tr>
   <tr>
       <td>token_xsql_args</td>
       <td>XSQL Arguments</td>
       <td></td>
   </tr>
   <tr>
       <td>token_locked</td>
       <td>Token Locked</td>
       <td>Lock Tocken        <br/><br/>
    <ul>      <li>Default: 0</li>      <li>Values:        <ul style='margin: 0; padding-left: 20px;'>
        <li>
1: Yes. </li>
        <li>
0: No. </li>
         </ul>
       </li>     </ul></td>
   </tr>
   <tr>
       <td>token_last_process</td>
       <td>Last login</td>
       <td></td>
   </tr>
   <tr>
       <td>token_process_count</td>
       <td>Login Counter</td>
       <td>        <br/><br/>
    <ul>      <li>Default: 0</li>     </ul></td>
   </tr>
   <tr>
       <td>token_expired_count</td>
       <td>Unauthorized accesses</td>
       <td>        <br/><br/>
    <ul>      <li>Default: 0</li>     </ul></td>
   </tr>
   <tr>
       <td>token_xsql_type</td>
       <td>Arguments Type</td>
       <td></td>
   </tr>
   <tr>
       <td>token_process_status</td>
       <td>Status</td>
       <td></td>
   </tr>
   <tr>
       <td>token_process_time</td>
       <td>Process Time</td>
       <td></td>
   </tr>
   <tr>
       <td>token_process_return</td>
       <td>Process return</td>
       <td></td>
   </tr>
</table>

This token can be generated by two methods:

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