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

[Colin Walters]

On Thu, 2004-08-26 at 11:59 -0400, Michael Sweet wrote:

> The problem is that your solution will not work for both locally and
> remotely connected printers unless you disable all of the access
> control stuff on devices and allow user processes to reserve priviledged
> ports when talking to a network printer via LPD.  *That* is why cupsd
> by default runs as root and not as a normal user account.

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.

> Also, running a separate cupsd process for each user means that you
> don't have a common configuration (printers, security, etc.) 

The session cups server picks up some of the system cups configuration
(i.e. the mime types).  But in large part the session cups server
shouldn't need to be configured.

> or a means to track jobs through the network 

Track jobs...like the job state, for presentation to the user?  We are
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.

> (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 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.

> 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.

>      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.
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.

>      remote cupsdN -> device

And here as well.

> 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.

> 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?

> Nothing will be happening until 1.1.21 and 1.2 are released, but
> after that we will be working on the remote authentication design
> pretty heavily.

Ok.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cups.org/pipermail/cups/attachments/20040826/391a0e5c/attachment.bin>