Table of Contents
- 17.1. User Authentication
- 17.2. Access over Internet
- 17.3. Web Sessions
- 17.4. SSL Passwords
- 17.5. Secured JMX Connection
- 17.6. Encrypted Secrets
- 17.7. Document Signature
- 17.8. User Client
- 17.9. Server Commands
- 17.10. Web Services
- 17.11. Log Files
- 17.12. Network Card Reader
- 17.13. Internal Services
- 17.14. External Services
- 17.15. Vouchers
This chapter discusses how SavaPage secures sensitive user and application data, and how it communicates with external Information Providers.
This section discusses how user credentials are protected.
This section is about the passwords and PIN codes entered in the Web App Login Dialog.
Tip
Users can use the HTTPS protocol for connecting to the Web App, so data is encrypted to and from the server.
SavaPage does not store or cache user domain login passwords. These passwords are always checked real-time at the source.
Passwords of Internal Users are stored as SHA1 hash in the database.
The SHA1 hashed password of the internal administrator
admin is stored in a text file located at
/opt/savapage/server/admin.properties. Access
to this file is restricted to the savapage
user.
SavaPage installs with admin as initial password for
user admin.
Tip
If you forgot the internal admin password, you can reset it by editing
the admin.password property in the
/opt/savapage/server/admin.properties text
file. Ignore the existing HASH value. SavaPage will hash your
password upon first use.
User PIN codes are stored in the database as encrypted secret.
When Authentication Persistence is enabled for Browser Local Storage, authentication tokens are stored in the “Local Storage” of the browser. See Section 4.11.3, “User Authentication”.
Separate authentication tokens are held for the User, Admin, POS and Job Tickets Web App context and the same token is used for different sessions (on different devices) of a single user. A explicit logout in the Web App destroys the token. Authentication tokens are managed in memory on the SavaPage server. So, when the server restarts all local tokens are implicitly invalidated.
A Trusted Third Party (TTP) can acquire a one-time token for Web App user authentication by calling an XML-RPC method. The expiration time of the token should be as short as possible to minimize the risk that an accidentally exposed token can be misused. See Section C.2.1.1, “onetime-auth.createToken” for details.