In a Single Sign-On (SSO) network user authentication is achieved in a login dialog where the User supplies unique credentials, usually by entering their user name and password. SSO networks establish a web-of-trust between users and domain services. System administrators like SSO domains, because they provide a single interface to control access of Domain Users to servers and services.
Making SavaPage part of an SSO domain is the most sophisticated setup possible. In this way access to the SavaPage queues can be controlled on a domain defined user and group level, and by doing so we can create authenticated queues.
In Windows Domains authenticated SavaPage Print Queues can solely be
enforced by installing local printers connected to SavaPage by the JetDirect/RAW protocol.
These RAW IP printers are typically installed on a Windows Print Server. To
exclusively grant access to the SavaPage printer by the print server, enter
the server IP address (as CIDR) as the allowed client IP address in the
/ Queue definition. See Figure 4.53, “Admin Web App: Queue - Edit”.
Trust is indeed essential to match the print job with the user's SafePages as previewed in their authenticated browser session. But, as we shall see in the next section, even in trust relations there are some loopholes to consider, and in networks where access is not fully guarded by SSO, unauthenticated users also need our special attention.
Although fully closed SSO domains provide unambiguous trust, there are common authentication loopholes that needs to be addressed. These loopholes are generic in nature and not related to SavaPage.
A loophole is
introduced when multiple users use the same account (user name) to
authenticate to the network. Because the login is based on the
person's role we can not retrieve the
unique user identity. If for example, both
John and Mary logged in with the generic
account, there is no way to find out if a SavaPage print job
from this session was issued by John or Mary. By default the print
jobs of John or Mary will end up in the SafePages of the one and
student. In situations where
printing content is private this might pose a problem. In
SavaPage this loophole can be solved by marking the generic
user account as abstract. See Section 15.1.13, “IP Based Authentication”.
A similar loophole is introduced when different users (sequentially) use the same machine, which was started in auto-login mode. Because the login is based on the machine identity we can not retrieve the unique user identity. In SavaPage this loophole is solved by the marking the auto-login user account as abstract . See Section 15.1.13, “IP Based Authentication”.
In networks where access is not fully guarded by SSO, SavaPage queues introduce a security issue when they are used by unauthenticated non-domain users. For example, consider a guest user who connects a personal laptop to the network, and installs and prints to a SavaPage printer. In SavaPage this loophole can be solved by marking the queue as untrusted, i.e. by creating a Public SavaPage Queue. See Section 15.1.13, “IP Based Authentication”. In addition the Internal Users feature can be used to offer out of domain Web App authentication for guest users.
 Of course methods like a smartcard and biometric (fingerprint) authentication should be mentioned as alternative.
 NIS (Network Information Service) protocol, also known as Sun Yellow
Pages (YP) allows the information contained in the files
/etc/shadow to be hosted on a central server.
Administrators can enter, edit and delete the information on the NIS server
so that it is automatically available on all Unix nodes. Authentication
services are usually delegated to a Kerberos
server, which thanks to tickets and authenticators eliminates the need to
move passwords over an open and insecure network. NIS operates on "flat"
domains and is therefore unsuitable for large organizations which due to
their nature may be organized hierarchically. In such cases, the use of the
LDAP (Lightweight Directory Access Protocol) is the way to go.