Communication Paths

YSoft SafeQ, on very abstract level, is comprised of several network communication paths described in this article. A general overview of the communication is as follows:

There are eight major paths available in YSoft SafeQ:

1. Communication from client workstation to SafeQ server – for printing.

2. Communication from terminal/reader to SafeQ server – for MFP level authentication

3. Communication from server to network printer / MFP, covering the following:

   1. printing

   2. AAA services - authentication, authorization and accounting

4. Integration with identity management database or identity / authentication provider or Certification authority.

5. Connection from SafeQ server to SMTP mail server or shared network folder for data delivery.

6. Integration with 3^rd party applications or systems

7. Inter-server communication in Distributed SafeQ Server system.

8. Administrator access to SafeQ web interface

Data security options

There are several data transfers realized over the described communication paths. Those data can be secured by following means. Authentication and encryption details will be described further. See Data Encryption Options for additional options.

 Items marked with this symbol are currently not available in SafeQ 5.

TLS Based Data encryption

Authentication

• By default, SafeQ supports unauthenticated TLS communication for data paths 1,2,3,4,5,7,8.

• 3^rd Party communication model is based on individual applications and/or protocols.

• Server Authentication is supported by default for data paths:

  • 4 (SafeQ server verifies LDAP certificate & domain name)

  • 8 (Administrator web browser verifies SafeQ server certificate & server hostname).

• Server Authentication is supported (using extended key management) for data paths:

  • 1 (Client computer verifies SafeQ server certificate & server hostname. YSoft SafeQ Client and printer drivers must be installed at the workstation, printer sharing from central server is not possible)

  • 2 (SafeQ terminal verifies SafeQ certificate & server IP address)

  • 3a (SafeQ server verifies printer certificate & printer hostname)

  • 3b (MFP verifies server certificate - this depends on MFP capabilities and requires trusted CA)

  • 5 (SafeQ server verifies mail server certificate)

  • 7 (ORS server verifies CML server certificate)

• Client authentication is supported for:

  • 2 (SafeQ server verifies SafeQ Terminal; this is valid for terminal professional only)

Key management (trusted CA):

• Administrator uploads trusted issuer (CA) certificate to SafeQ.

• SafeQ Server Certificate(s) - for Terminals, Workstation Clients and administrator workstation(s).

  • Administrator creates certificates for all servers using Trusted CA.

  • Server certificates (private keys) are stored in password protected key store on the SafeQ server disk. Password is hard-coded to the application. 

  • Client can verify the server identity using certificate trust and server host name / ip address.  

• MFP Certificates

  • MFPs are verified using trusted certificate and hostname.

• LDAP Certificate

  • LDAP server is verified using trusted certificate and hostname.

Key management (without trusted CA):

• SafeQ Server Certificate(s) - for Terminals, Workstation Clients and administrator workstation(s).

  • Administrator creates self-signed certificates for all servers. 

  • Server certificates (private keys) are stored in password protected key store on the SafeQ server disk. Password is hard-coded to the application. 

  • SafeQ Client displays "accept certificate" dialogue upon first print and stores the certificate to Workstation store.

• MFP Certificates

  • SafeQ retrieves X509 certificate on first connection to the MFP.

• LDAP Certificate

  • SafeQ retrieves X509 certificate on first connection to the MFP. 

User PKI Based Data encryption

SafeQ can provide end-to-end encryption using smart card based PKI. SafeQ Workstation client would encrypt the data using authenticated user's public key on before communication to the SafeQ server (1).
The data would be decrypted by SafeQ Terminal Professional using communication path (2). Decryption is managed by user's private key stored on his/her smart card inserted to the terminal. Unencrypted data
Note: this feature is currently not available in SafeQ and would have to be developed on request.

Terminal Authentication

SafeQ 5 support user authentication to the terminal in various modes (see Terminal Authentication Matrix). Terminal always communicates authentication data (PIN codes, Card Numbers or User Credentials) via secured TCP/IP communication to SafeQ server.

Authentication data are verified by following means:

• For ORS - data are ALWAYS verified with Local Data Cache and (only if not found locally) with CML.

• For CML - PIN codes and Card Numbers are verified by sub-string match in SafeQ SQL database. (see Identity management). PIN codes are typically stored in form of one-way hash. Data are replicated to ORS data caches in scheduled intervals or on demand (by Administrator or 1st User Access).

• User Credentials (Login/Password) on CML are verified either by sub-string match in SafeQ SQL database (if manually assigned to the user), with Kerberos 5 (see next chapter) or with LDAP  - using LDAP/S authentication mechanism. Locally stored passwords (hashes; if available) are replicated to ORS data cache. If the password is found in ORS data cache, CML server (and further LDAP server is not used)  

Kerberos v5 based user authentication

SafeQ 5 supports user authentication using Kerberos v5 for following communication paths:

• Administrator authentication from web browser(8)

  • To access the Web Administration, users are authenticated with a name and password. The internal SafeQ database and Active Directory / LDAP or Kerberos v5 (SafeQ 5) serve as the authentication and authorization data storage. Users are authorized by verifying their names and passwords for the internal database only [Passwords are stored only hashed using secure hash function], and, in case of an unsuccessful verification, for the Active Directory/Kerberos as well. Each user with a valid name and password has access to the system with credentials level defined by master administrator (internal user: admin, password can be changed).

  • Single sign on (SSO) to the web interface is supported if a user is logged in a domain and uses a browser that supports Integrated Windows Authentication (IWA). SafeQ uses Windows Authentication Framework (WAFFLE) to ensure the Access.

• Login to SafeQ Terminal Professional via Smart Card that contains user private key and certificate.

  • Kerberos query is made by SafeQ server (4)

  • Encrypted data path (2) is used by SafeQ server to access the smart card (inserted to terminal) and sign/decrypt communication to/from Kerberos v5.

• Login to SafeQ Terminal Professional via username and password.

  • Kerberos query is made by SafeQ server (4)

  • Encrypted data path (2) is used by SafeQ server to acquire username and password from terminal (where entered by user)

Authorization model

YSoft SafeQ is managed via a centralized web interface.

It uses Role-based access control (RBAC) with Capability model for certain system operations. The administrator can create multiple roles and delegate selected administrative and managerial permissions and operations to these roles. It is also possible to define personal user accounts with full administrative privileges, and disable the default, anonymous administrative account.

SafeQ supports replication of roles from external sources (e.g., Active Directory/LDAPS or CSV file) with additional administration within SafeQ.

With Active Directory and eDirectory, the SafeQ system takes advantage of advanced Active Directory specific replication information to optimize the replication process.

Impact to system response speed

This chapter is only related to data paths (1, 2 and 3a). For other communication paths the delay doesn't have any measurable impact to end user experience.

Data delivery throughput for PKI-based encryption via Terminal Professional is about 512 kbps.

Data delivery throughput for TLS based encryption (SSL over IPP) depends on the speed of the target printer.

Internal System Audit log

SafeQ logs all CRUD operations to log file(s) on the file system using standard Log4j logging library. Manual administrative operations are tracked by the system in dedicated audit logs, which are accessible to delegated users in the web interface.

Passwords and authentication data are not logged. Access to the log files is not controlled and must be managed on operating system level.

Data Storage Methods and Access to the System

All data within the operation of the system is stored in the following ways:

• Internal SQL database. In case of embedded PGSQL/MSSQL Express, the database is accessible only via the local host interface. In case of an external DB, the security model is the responsibility of the database administrator. The database is accessible only with the name and password stored in the configuration file.

• Internal Configuration Files. Are stored in the SafeQ operation directory in a text format. The data is secured on the same level of access as relevant directories and OS.

• External Data sources. Configuration dependent. For LDAP integration security, please see LDAP Integration Security document.

• All passwords and user codes are stored in the configuration files and database in an encoded form (one-way encryption is used). Access data to external systems (including access to the SQL DB SafeQ itself) is stored in encoded form, encrypted using DES algorithm with hard-coded key or AES-128 with key generated.

• Print job data is stored temporarily on the file system in the plain unencrypted form as received from the source workstation, or optionally encrypted as specified in previous chapters. Using system configuration, this data can be automatically deleted (not wiped) after print or administrator defined expiration time.

Used technologies

The whole solution is proprietary. Oracle Java 7 is used for System Core, MS .NET 4.5 Framework for MFP integration and Apache Tomcat, MS SQL or PostgreSQL Database Engines are among standard 3rd party components used in the solution.

Data proxy support

All communication paths defined in first chapter of this document can be routed via SOCKS 4 proxy. HTTP proxy or authenticated SOCKS5 proxy is not supported.

Additional notes

Some print drivers support print job data encryption for particular printer. This feature can only be used for direct print to the specified device.

Authentication data are not stored in any caches.

All session timeouts in the system (administrative console or terminal access) are administrator definable using centralized web interface.

There are not practical limitations regarding character sets and length for usernames and passwords. Certain MFPs may impose additional limitations on their own.