[cups.general] Re: How to authenticate from printing software?

[Michael Sweet]

Colin Walters wrote:
> ...
> Sorry, I guess we were unclear in the printing architecture document.
> The local cups server stays around in this scenario, and is used for
> local printers.  Only for remote printers is the session CUPS server
> used.

I guess I don't see the usefulness of the session server - the main
server will enumerate the remote printers for you, and your app can
talk to the remote server directly and handle any authentication,
and printing will *still* happen in the background, so ???

> ...
>>or a means to track jobs through the network 
> 
> 
> Track jobs...like the job state, for presentation to the user?  We are

Not just state (which is already tracked), but which printer and
which server actually handles the job, and where the job is currently
being processed, and any number of additional bits of information
(including authentication data/requests).

> already doing this in eggcups; you get an icon with your print jobs and
> their status.  This works by having the session cups IPP backend send
> the remote job ID to the user session over DBus, which picks it up and
> starts polling until completion.

... which won't scale, which is why we are keen on using IPP
notifications for this sort of monitoring.  Also, we aren't just
talking about the user watching his/her job print - that is an
important but trivial part of the equation.  The job tracking we
are talking about needs to handle accounting, detailed history
tracking (think secure environments where you may need to determine
which printer was used for a particular job, who authenticated, etc.)

>>(something we are implementing
>>in CUPS 1.2), making your implementation unsuitable for all but a
>>single-user environment.
> 
> 
> I don't see any reason this wouldn't work in a multiuser environment.

If you only have the session cupsd, they can quite easily stomp all
over each other, and printer sharing on non-server machines becomes
an issue.  Also, with all of the extra processes and polling you are
doing, you are adding a lot of overhead that will limit the size of
the network that can be supported.

>>If all you want is for client applications to talk IPP directly to
>>the server, then you don't need the user-session cupsd, just lookup
>>the list of available printers and talk IPP directly to the
>>destination server! 
> 
> 
> We considered this, but the interaction model we want is that the user
> clicks "print", and they can close the application, and not lose their
> print job.  To do this you need some means of queueing, and running a
> session CUPS server seems to me like a sensible solution.

Um, since the remote CUPS server will queue the file, closing the
application after the job has been submitted will not cause the loss
of the job.

The only time you need to worry about queuing is when you are
printing directly to a printer, and you have already said that the
system cupsd handles that kind of printing, right?

>>The general problem is that a print job may require multiple
>>authentication credentials in order to print.  E.g.:
>>
>>     Application -> local cupsd
> 
> 
> This is still handled.
> 
> 
>>     local cupsd -> remote cupsd
> 
> 
> This is difficult in the current CUPS model - you need to go from the
> system back to the user session.  That's the problem we're solving, and
> I think this is the point that system administrators will want user
> authentication to occur.

The problem with your implementation is simply that you are using
a sledgehammer to hang a picture.

It is much simpler to either 1) talk to the remote cupsd directly
and/or 2) define a way for the application/user to provide the
authentication information that is required through the existing
system cupsd.  CUPS 1.2 will provide the infrastructure to do #2,
and you can already do #1.

>>     remote cupsd -> remote cupsdN
> 
> 
> We simply assume there is no *user* authentication required here.  This
> would be like having user authentication required between internal
> corporate mail servers; it just won't work, and doesn't even make sense.

Um, it is already used in a LOT of corporate and government
environments!

> Now the *servers* could authenticate to each other, and that's fine.
> But it doesn't require the user to be involved; once they've sent their
> job to the first server, that should be the end of their required
> authentication.

I guess you'd never worked in environments where multiple levels of
authentication are required to access a resource.

>>     remote cupsdN -> device
> 
> 
> And here as well.

I guess you've never used the "smb" backend in SAMBA?

>>The general solution is something which supports both common
>>authentication credentials through the whole system (e.g. Kerberos
>>tickets), 
> 
> 
> Very difficult.  Passing the user's Kerberos credentials around over the
> network is difficult to do, and very questionable from a security point
> of view.

No more so than passing a username and password, encrypted, over the
network.

>>a notification scheme whereby a user can be notified
>>when a job requires authentication, 
> 
> 
> Beyond requiring authentication at the first point of entry, I don't
> think this makes sense, as above.
> 
> 
>>and a caching mechanism which
>>can optionally be used to record previous authentication data
>>(securely) so that the user only provides their information once
>>(per day, per week, etc.)
> 
> 
> Kerberos will work well for single-sign on to the initial CUPS server.
> For password-based authentication I've implemented support in eggcups
> for storing passwords in the GNOME keyring.
> 
> 
>>>>We have some UI- and network-agnostic notification-based ideas that
>>>>we will be trying once CUPS 1.2 is released.  
>>>
>>>
>>>The D-BUS patches for cups are certainly UI agnostic; eggcups happens to
>>>implement a particular UI for them.  Not sure what you mean by network
>>>agnostic.
>>
>>Meaning it works over any network.
> 
> 
> Ok...."network" is a word with a lot of meanings.  Are you talking about
> IP/TCP, or a particular instantiation of printing architecture at a
> large site (what servers are run, how authentication works, etc), or
> something else?

Meaning that, no matter what network topology, protocol, etc., you
can use the same method to do notification over multiple channels.
The simplest example I can think of is that the same code will work
on the local machine, on the LAN, over a WAN link, or over the
Internet, even if some of the nodes use domain sockets (new in 1.2
for local access), IPv4, IPv6, or any other network protocol we
support in the future.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com