.. /* * This file is part of the SavaPage project . * Copyright (c) 2026 Datraverse B.V. * Author: Rijk Ravestein. * * SPDX-FileCopyrightText: (c) 2020 Datraverse B.V. * SPDX-License-Identifier: CC-BY-SA-4.0 * * For more information, please contact Datraverse B.V. at this * address: info@datraverse.com */ .. _ch-auth-print-sso: Single Sign-On Domains ---------------------- .. contents:: |RST_TABLE_OF_CONTENTS| :depth: 2 :local: .. _ch-auth-print-sso-intro: Introduction ~~~~~~~~~~~~ In a *Single Sign-On* (SSO) network user authentication is achieved in a login dialog where the :ref:`User ` supplies unique credentials, usually by entering their user name and password [1]_. 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 :ref:`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* :ref:`Print Queues ` can exclusively be achieved in a macOS or GNU/Linux SSO domain using LDAP or NIS (Network Information Service) as authentication services [2]_. Windows Domains have their own rules regarding IPP :ref:`Print Queues `. An alternative is to install 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 :ref:`CIDR `) as the allowed client IP address in the Default ``/`` Queue definition. See :ref:`Admin Web App: Queue - Edit `. .. _fig-infra-sso-domain: .. figure:: ../images/manual/sp-infra-sso-domain.png :alt: SavaPage in a Single Sign-On Domain :width: 600 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. .. [1] Of course methods like a smartcard and biometric (fingerprint) authentication should be mentioned as alternative. .. [2] 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. 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 |PRODUCT_NAME|. .. _ch-auth-print-sso-loophole-generic-account: 1. 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 :ref:`Standard IP Based Authentication `. 2. 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 :ref:`Standard IP Based Authentication `. .. _fig-infra-sso-domain-abstract-user: .. figure:: ../images/manual/sp-infra-sso-domain-abstract-user.png :alt: IP Based Authentication for Abstract User :width: 600 IP Based Authentication for Abstract User Unauthenticated Users ~~~~~~~~~~~~~~~~~~~~~ In networks where access is not fully guarded by SSO, |PRODUCT_NAME| 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 :ref:`Public SavaPage Queue `. See :ref:`Standard IP Based Authentication ` and :ref:`Basic Authentication `. In addition the :ref:`Internal Users ` feature can be used to offer out of domain Web App authentication for guest users. .. _fig-sso-unauthenticated-user: .. figure:: ../images/manual/sp-infra-sso-domain-unauthenticated-user.png :alt: Authentication for Unauthenticated User :width: 600 Authentication for Unauthenticated User