15.2. Single Sign-On Domains

15.2. Single Sign-On Domains
Prev	Chapter 15. Authenticated Printing	Next

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^[33]. 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.

Authenticated SavaPage IPP Print Queues can exclusively be achieved in a macOS or GNU/Linux SSO domain using LDAP or NIS (Network Information Service) as authentication services^[34].

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 Default / Queue definition. See Figure 4.53, “Admin Web App: Queue - Edit”.

Figure 15.1. SavaPage in a Single Sign-On Domain

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.

15.2.1. Authentication Loopholes

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 student 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 only unknown 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”.

Figure 15.2. IP Based Authentication for Abstract User

15.2.2. Unauthenticated Users

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.

Figure 15.3. IP Based Authentication for Unauthenticated User

^[33] Of course methods like a smartcard and biometric (fingerprint) authentication should be mentioned as alternative.

^[34] NIS (Network Information Service) protocol, also known as Sun Yellow Pages (YP) allows the information contained in the files /etc/passwd, /etc/group and /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.