Planning for web SSO implementation
There are a number of considerations and preparation steps you must take prior to implementing SSO in PaperCut.
Preparing for SSO
An effective security system offers multiple layers of defence against unwanted intrusion. For example, an organization's firewall can provide the first layer of defence, but if an intruder penetrates that, the Windows login presents a second barrier. Once logged into Windows, PaperCut's login screen represents a third layer of defence.
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.
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. Decide your policy up front before configuring SSO.
Decide whether you want PaperCut NG 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.
- Decide if you want to redirect the user to your intranet portal after logout. A logout URL is required when direct access is configured.
Your PaperCut users must be sourced from a central directory server, such as Windows directory. Internal users (users managed by PaperCut NG), and the built-in admin are internal to PaperCut so do not work with SSO. If you have internal users, show the confirmation page with the Switch User link to make the PaperCut login page accessible.
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 StationPrint Release Stations place a print job on hold and allow users to release it when required. Often a Release Station is a dedicated PC terminal located next to the printers, however, Release Stations can take other forms such as a web browser based interface. Some common examples where Release Stations can be used include secure printing, approved printing, and authentication. In a secure printing environment jobs are only printed when the user arrives at the print area and confirms his or her identity. This ensures the user is there to collect the job and other users can't "accidentally" collect the document. In some organizations it may be appropriate to hold jobs until they are approved by selected individuals. A good example would be a teacher approving printing on an expensive color printer. Hold/Release queues can be used as a form of authentication in an unauthenticated environment. Users must authenticate prior to releasing their jobs allowing PaperCut NG to confirm their identity., Web CashierWeb Cashier is a basic Point of Sale (POS) system to charge items to PaperCut accounts and deposit funds into users' accounts., and Central ReportsCentral Reports provide a consolidated data and reporting view across multiple Application Servers. Central Reports provide a large subset of the same reports that provided by the standard PaperCut reporting feature..
Select which SSO technology is right for you. While many PaperCut NG 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.
Planning for integrated Windows authentication
Integrated Windows Authentication (IWA) is designed for Microsoft Windows environments where both the PaperCut Application ServerAn Application Server is the primary server program responsible for providing the PaperCut user interface, storing data, and providing services to users. PaperCut uses the Application Server to manage user and account information, manage printers, calculate print costs, provide a web browser interface to administrators and end users, and much more. and client PCs reside on the same Windows domain and intranet zone. In summary the requirements are:
The PaperCut Application Server must run on the Windows operating system.
PaperCut web users are using PCs running Windows
All computers are on the same domain
Your site uses Active Directory for managing users, including PaperCut users. Windows Authentication works only with users who are managed by Windows.
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.
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.
Planning for WebAuth
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.