Table of Contents
Authentication in a printing environment is the act of confirming the digital identity of the person who issued a print job. Knowledge of this identity is crucial for SavaPage to securely offer its services to the right user. The next sections discuss authenticated printing in:
But first, let us introduce the key authentication concepts where our discussion is based upon.
This section lists the main authentication concepts headed with a short term. Each term is defined with a concise description, optionally followed with more details and a list of invariants.
A User who represents a real human being, as opposed to an abstract human role, software service or hardware device.
Only Persons can login to SavaPage.
Any User can print to a SavaPage Printer. However, SavaPage assigns a print job to a Person.
A User defined in a SSO domain.
A SavaPage User synchronized from a User Source.
A Synchronized User that is a Person.
A Person who is internally defined in SavaPage (opposed to a Synchronized Person).
A User authenticated on a SSO domain by a workstation login.
An Abstract User authenticated on a SSO domain by a workstation login.
Before Authenticated Abstract Users can print to a SavaPage Printer they need to login to the SavaPage Web App on the same device from which they use the printer.
A Synchronized Person authenticated on a SSO domain by a workstation login.
Authenticated Persons can print to SavaPage without being logged in to the Web App.
A SavaPage Print Queue whose print jobs are trusted to originate from Authenticated Users.
Each SavaPage Print Queue is trusted by default. However, administrators can mark SavaPage Print Queues as untrusted.
Every job of a Trusted SavaPage Queue is checked for the originating User. When this user is an Abstract User, SavaPage uses IP Based Authentication to deduce the associated Person. When the Person cannot be deduced the job is ignored.
Note that the “trust” qualification is SavaPage internal use only, and not related to network domain trust in any way.
SavaPage Print Queues are IPP based and, from a network point of view, are publicly accessible by nature.
In the Microsoft Active Directory world IPP Printers cannot be encapsulated as native domain resource and subjected to native domain access control like JetDirect compatible devices. This is why SavaPage does not bet on native domain trust alone, and accepts public network access as a given fact. But even in this case, SavaPage Print Queues can still be internally trusted if access is limited to authorized users on a network level. Stated the other way round: administrators need to prevent that users who connect to the network unauthenticated, e.g. with their personal laptop, use Trusted SavaPage Queues. SavaPage adds a helping hand here with an option to restrict print queue usage to a specific range of IP addresses. This makes it possible for instance to deny trusted queue access for wireless users who get their IP addresses from a distinct DHCP server issuing leases from a distinct IP range.
When non-domain users are allowed to print to Trusted SavaPage Printers an accidental match with a Synchronized Person may lead to undesirable results.
A SavaPage Print Queue where print jobs are not trusted to originate from Authenticated Users.
Since each SavaPage Printer is trusted by default, this queue must be explicitly marked as untrusted in the SavaPage Admin Web App.
SavaPage handles every job from a Public SavaPage Printer as originating from an Abstract User.
Deduction of the printing Person by matching the IP address of the originating host of the print job with the authenticated SavaPage Web App Session on the same host.
This type of authentication is applied for jobs coming from a Public SavaPage Printer, or from a Trusted SavaPage Queue where the originating User is Abstract.
When no authenticated Web App session is found the job is ignored.
Deduction of the printing Person using the email address of the sender.
This type of authentication is applied for print jobs coming in from Mail Print.
When no unique matching Person is found, or when the Person is disabled, authentication fails. Consult Section 4.4.4, “Edit User” on how to mark a User as (enabled) Person.
A User defined on a local device.
An Abstract User defined on a local device.
A Person defined on a local device.
An alternative name for a User.
A single User can have several aliases.
An alias is applied at the following levels:
User login to the User and Admin Web App via the Login dialog, or the XML Web Services API.
Print jobs arriving in the SavaPage queues under the alias name.
For more information see Section 15.4, “User Name Aliases”.