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

[Colin Walters]

On Thu, 2004-08-26 at 14:14 -0400, Michael Sweet wrote:
> 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 

Basically, for Kerberos authentication.  When the IPP backend is exec'd
from the session server, it can just pick up the credentials from the
user session.

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

Reply to this below.

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

Why won't it scale?  The user session only polls their particular jobs,
while the jobs are active.  As soon as the job is complete, polling
stops.

>  which is why we are keen on using IPP
> notifications for this sort of monitoring.  

I could be convinced that IPP notification is the way of the future.
Right now our printing architecture is based on polling, which obviously
sucks.  But the fact is, IPP notification doesn't exist at all yet in
CUPS, and I'm doubtful it has been implemented in very many other IPP
servers.  On the client side, we will still need to keep the polling
architecture as a fallback even after IPP notification is implemented.

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

As I said above and several times in the printing architecture document,
the system cupsd is still around.

> they can quite easily stomp all
> over each other, 

How is that?

> and printer sharing on non-server machines becomes
> an issue.  

That was an issue before, too.

> Also, with all of the extra processes 

The cups server is pretty small relative to the rest of the desktop
session.  

> and polling you are
> doing, 

This was addressed above.

> you are adding a lot of overhead that will limit the size of
> the network that can be supported.

All I can say in response to this is: I don't think so.  If you can come
up with some hard facts about this instead of some vague references to
"extra processes" and "polling", I'd be happy to discuss.

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

After the job is ultimately sent, yes.  Imagine a very large job (say a
100 page OpenOffice document).  We want the user to just be able to
click "print", and close OpenOffice, and the job should keep printing.

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

That's not clear at all; if our solution is a sledgehammer, then it
certainly seems to me that for this problem, IPP notification is a
construction crew wielding sledgehammers :)  Obviously IPP notification
is trying to solve a larger problem than hanging a picture, as you've
said.

> It is much simpler to either 1) talk to the remote cupsd directly

See above.

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

Like I said, I'm interested in this.

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

For MTAs, or for CUPS?  I very seriously doubt it is used for many MTA
setups, since for example with Kerberos, short of actually shipping the
user's Kerberos credentials over the network (violating several
principles of Kerberos), you can't do it.  In the case of plaintext
logins, you need to ship the user's unencrypted password. 

SMTP doesn't have any way of talking back to the client session.

As for CUPS - certainly it doesn't implement this now.  So what are you
talking about?

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

Umm...that's a rather vague statement.  I could answer yes, no, or maybe
to it.  In terms of printing - no, I haven't.  In other terms (e.g. file
retrieval, yes, I have).

> >>    remote cupsdN -> device
> > 
> > 
> > And here as well.
> 
> I guess you've never used the "smb" backend in SAMBA?

The SMB backend should work similarly to IPP, being invoked directly
from the user session.  But since Windows is moving to IPP for printing,
I am not too concerned about it.

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

If you do that, then you need for the server-to-server transport to be
encrypted and authenticated, otherwise a MITM attacker can steal
credentials.  And a compromised server can steal credentials.  So
essentially, you have to trust the server.  If you trust the server,
then you can trust what username it sends.

Now in a protocol where you have some means of reconnecting to the
client to re-acquire authentication credentials, this could work better.

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

I don't see how our current architecture would change in these different
scenarios.  If you have a particular instance of a problem, please
describe it.

> even if some of the nodes use domain sockets (new in 1.2
> for local access), 

Interesting, we can use this instead of binding to a TCP port for the
user session.

> IPv4, IPv6, or any other network protocol we
> support in the future.

The transport layer should be basically irrelevant here as long as it
provides the same guarantees as TCP.


-------------- 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/034b6b27/attachment.bin>