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.

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

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

TO DO

This section is incomplete and will be concluded as soon as possible.
BASIC DIGEST FORM
WEB  (?)    
SOAP      
REST      

2.2 Authentication vs Validation origin

TO DO

This section is incomplete and will be concluded as soon as possible.
BASIC DIGEST FORM
INTERNAL (wic_conf)     (*)  
EXTERNAL (LDAP, XSQL)      

(*)

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

2.3 Authentication vs Stored password

TO DO

This section is incomplete and will be concluded as soon as possible.
BASIC DIGEST FORM
PLAIN      
MD5-HASH      
MD5-HA1      
OBF      

2.4 BASIC Authenticator

TO DO

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:

Copy
Authorization: Basic xdXN1s1cjp122Vy1TIf

2.5 SSO Authenticator

TO DO

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.

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

2.6 DIGEST Authenticator

TO DO

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

TO DO

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.

Copy
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

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:

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

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

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

3 Authentication

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

                                    
Loading...

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)

TO DO

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

3.3.2 LDAP

TO DO

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

3.3.3 Custom valve

TO DO

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.

Screen
Table
wic_user_token_login
Column Type Size Not null Label Description
user_code Usuario Código del usuario
token_group Grupo Grupo de control de acceso
token_protocol Protocolo Protocolo

  • Default: 0
  • Values:
    • 0: ALL.
    • 1: HTTP.
    • 2: SOAP.
token_soap_uri SOAP URI URI para acceso mediante SOAP
token_hash Hash El valor del token que se defina en este campo deberá incluirse en la URL de acceso añadiendo el atributo token, por ejemplo :

token_locked Token bloqueado Token bloqueado

  • Default: 0
  • Values:
    • 1: Sí.
    • 0: No.
token_expires Caducidad Fecha y momento de expiración de la validez del token
token_created Fecha de creación Fecha de creación

  • Default: CURRENT
token_last_login Último accesso Fecha del último acceso mediante el token
token_login_count Accessos Contador del número de accesos mediante el token

  • Default: 0
token_expired_count Accessos no permitidos Número de veces que se ha utilizado este token para intentar hacer acceder una vez ha expirado su vigencia.

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

Screen
Table
wic_user_token_process
Column Type Size Not null Label Description
user_code Usuario Usuario
token_group Grupo Grupo
token_hash Hash token Hash token
token_created Fecha creación Fecha creación

  • Default: CURRENT
token_expires Expiración del hash Expiración del hash
token_dbms Nombre Base de Datos Nombre de la Base de datos
token_xsql_code Código XSQL Código XSQL
token_xsql_args Argumentos pasados al XSQL Argumentos pasados al XSQL
token_locked Bloquear Bloquear

  • Default: 0
  • Values:
    • 1: Sí.
    • 0: No.
token_last_process Último acceso Último acceso
token_process_count Accesos realizados Accesos realizados

  • Default: 0
token_expired_count Accesos no permitidos Accesos no permitidos

  • Default: 0
token_xsql_type Tipo argumentos Tipo Argumentos
token_process_status Estado Estado
token_process_time Tiempo del proceso Tiempo del proceso
token_process_return Return del proceso Return del proceso

This token can be generated by two methods: