Skip to content

Choose your language

  • No results

Choose your login

  • No results
Support

How can we help?

PaperCut's AI-generated content is continually improving, but it may still contain errors. Please verify as needed.

Lightbulb icon
Lightbulb icon

Here’s your answer

Sources:

* PaperCut is constantly working to improve the accuracy and quality of our AI-generated content. However, there may still be errors or inaccuracies, we appreciate your understanding and encourage verification when needed.

Lightbulb icon

Oops!

We currently don’t have an answer for this and our teams are working on resolving the issue. If you still need help,
User reading a resource

Popular resources

Help center

FAQs
Conversation bubbles

Contact us

Configure Web SSO

This page applies to:

Last updated October 24, 2025

Web Browser Single Sign-on (SSO) allows users to access PaperCut NG/MF web applications—such as the User Web Interface, Mobile Client, and Admin web interface—without having to provide separate login credentials if they are already authenticated on your network.

Preparing for Web SSO

There are a number of considerations and preparation steps you must take prior to implementing SSO in PaperCut NG/MF.

  • Weigh Security Trade-offs: SSO trades off the convenience of direct access with removing one layer of security. For example, with SSO a user can click a hyperlink in an email or instant message and be taken directly into PaperCut. Before implementing SSO, you must weigh up the risks and benefits for your organization.
  • Define Scope: PaperCut offers granularity of control over which parts of PaperCut will use SSO. For example, you might decide to use SSO for just the user web pages and mobile client, not the Admin web interface.
  • Choose Login Behavior: Decide whether you want PaperCut NG/MF SSO to directly log in users, or to first present a confirmation page. The confirmation page displays the user name and can also offer a Switch User link to allow users to use an alternate login. With direct login, one less click is required, but there is no opportunity to confirm the correct login or switch to an alternate user.
  • Set Logout Redirect: Decide if you want to redirect the user to your intranet portal after logout. A logout URL is required when direct access is configured.
  • User source: Your PaperCut users must be sourced from a central directory server, such as Windows directory. Internal users (users managed by PaperCut NG/MF) , and the built-in admin are internal to PaperCut so do not work with SSO. If you have internal users, enable the confirmation page with the Switch User link to make the PaperCut login page accessible.
  • Assign admin access: If using SSO to access the PaperCut Admin web interface, set up the necessary permissions (see Assign administrator level access ) for all administrative users before enabling SSO. The same applies to other PaperCut interfaces, such as Release Station, Web Cashier, and Central Reports.
  • Choose wisely: Select which web SSO technology is right for you, Integrated Windows Authentication or WebAuth. While many PaperCut NG/MF sites choose Integrated Windows Authentication, it does have strict prerequisites. For example, if you have a significant number of non-Windows users, Windows based SSO might not be the best choice for you. More information about each SSO technology is provided below.

Types of Web SSO

  • Integrated Windows Authentication : For Windows domain environments where both the PaperCut NG/MF Application Server and the user computers share the same Windows domain and intranet zone. With Integrated Windows Authentication, PaperCut NG/MF uses existing Windows technologies to securely identify Windows domain users as PaperCut NG/MF users.
  • WebAuth : A web authentication system developed and freely licensed by Stanford University. It is implemented as an Apache module and works by intercepting requests to the PaperCut NG/MF Application Server. WebAuth is operating system neutral, but requires specialist expertise to set up.
    PaperCut NG/MF’s WebAuth integration is actually quite generic and is also used for Shibboleth SSO integration at several customer sites.

Integrated Windows Authentication considerations

Integrated Windows Authentication (IWA) is designed for Microsoft Windows environments where both the PaperCut Application Server and client PCs reside on the same Windows domain and intranet zone. In summary the requirements are:

  1. The PaperCut Application Server must run on the Windows operating system.
  2. PaperCut web users are using PCs running Windows
  3. All computers are on the same domain
  4. Your site uses Active Directory for managing users, including PaperCut users. Windows Authentication works only with users who are managed by Windows.
  5. The Application Server URL is on the same intranet zone as users’ PCs. By default this means that the URL does not contain periods. You can configure user internet options to explicitly add the PaperCut Application Server to the intranet zone.
  6. Your organization’s recommended web browser supports IWA. Browsers that support IWA include Internet Explorer, Chrome, and Firefox. (Note that Firefox requires additional configuration to enable IWA support.)

Integrated Windows Authentication is part of Windows, so if your site meets the above criteria, no additional setup is needed prior to configuring SSO.

WebAuth considerations

WebAuth uses a reverse proxy server to manage HTTP traffic between users and PaperCut. If you are considering WebAuth, you need the resources and skills to implement and configure an Apache web server and perform the installation instructions provided by WebAuth .

WebAuth takes care of authorizing the user and inserts a special HTTP header in all authorized requests sent to PaperCut. Specify the name of this header and also a list of whitelisted source IP addresses when integrating WebAuth with PaperCut

Although WebAuth SSO is considerably more complex to implement than IWA, it does have the advantage of supporting a non-Windows environment.

Configuring Web SSO

Configuring SSO in PaperCut NG/MF is easy, but you must work through the preparation steps above, or you might not be able to log in to PaperCut NG/MF!

  1. Select Options > Advanced. The Advanced page is displayed.

  2. In the Web Single Sign-on (SSO) area, select the Enable Single sign-on check box to enable SSO. Additional configuration items are displayed.

  3. Select the SSO method:

    • Integrated Windows Authentication
    • WebAuth

  4. If you select WebAuth, complete the following fields:

    • WebAuth HTTP header key—the WebAuth HTTP header name.
    • Allowed WebAuth IP addresses—a comma-separated list of whitelisted IP addresses.

  5. Specify the SSO behavior you want for the user web interface and mobile client, Admin web interface, and other interfaces:

    1. Standard (username and password)—don’t use SSO and show the PaperCut NG/MF login screen.
    2. SSO with confirmation page—use SSO and present a confirmation page at login.
    3. SSO with direct access—use SSO and directly log in the user with no confirmation page.

  6. If you want to show a Switch User link on the confirmation page, select the Show “Switch User” link on confirmation page check box.

  7. In On logout, direct user to URL, enter a URL to go to on logout. A typical example would be the URL for your intranet portal.

Advanced configuration

You can set advanced config keys to fine tune SSO behavior. For more information, see Using the Advanced Config Editor .

  1. Some installations want to enable SSO for web users, but not for users of the mobile client and mobile release apps. To disable SSO for mobile users, set the advanced config key: auth.web-login.sso-enable.mobile-user to N.
  2. By default, Windows SSO does not authenticate users belonging to the “Guest” group. You can change this behavior by setting the advanced config key auth.web-login.sso-allow-guest to Y.

Post installation testing

After enabling SSO, perform the following tests to ensure that users can successfully access the PaperCut interface.

  1. Verify that you can still log in to the Admin web interface.
  2. Verify that a user without admin rights can still access their user web pages.
  3. If in use, verify that a user with the appropriate admin rights can still access other interfaces, such as Release Station or Web Cashier.
  4. Try logging in from other computers in the domain.
  5. Try logging in from different browsers supported in your organization.
  6. If using IWA, try logging in from a non-Windows client or a PC outside the domain. Verify you can still log in after providing your Windows credentials.

 

Comments