"Herriot, Robert" wrote:
> ...
> > Both names. The group name (and password) gets past the HTTP
> > authentication, and the student name is used for accounting (and in
> > some cases billing).
>> So in the above case, I assume that it is fairly easy to spoof another
> student's name, but the spoofer is likely to be another member of the
> group.
Correct. If the student is getting billed for the prints s/he makes,
then then they'd need to look at the server logs to see where the
request came from, and then check to see who was logged on at the
time.
I'm not saying that using the requesting-user-name over the HTTP
authenticated user is a perfect solution, but if we decide that
implementation should use the HTTP username over the IPP user name,
it'll make any authentication in the "group" scenario impossible.
> >
> > We even have some customers that are using barcode readers to
> > validate jobs before they are printed (the student puts his ID card
> > under the reader to release the job in the queue).
>> How do you see the above solution fitting in to the IPP issues we are
> discussing?
We'll need to have a consistent way to identify users, as the barcode
reader will have to associate a print job with a specific student.
Also, when submitting a job the returned job status will be
pending-held instead of pending. The IPP server will have to implement
the barcode reader interface, and then release jobs when the correct
user's card is read (this actually can be a separate program that then
changes the job status, which is how we're providing the hooks for it.)
> ...
> > I say "weak" because in your original proposal the HTTP username
> > would override the requesting-user-name attribute. The HTTP
> > username *should* be used, but IMHO only if requesting-user-name is
> > not supplied.
>> But if the requesting-user-name overrides the HTTP name, then I can
> gain access via digest using my name/password and then pretend I am
> someone else by sending in a bogus requesting-user-name.
If you are able to gain access, then you'll be able to print. Period.
The "requesting-user-name" attribute should *not* be used for access
control, only the HTTP authentication user should be (that's the
one with the password). The requesting user should only be used for
accounting stuff, with the HTTP username substituted *only* if the
requesting-user-name attribute is not provided.
This is at odds with section 4.3.6 of the model document, but IMHO
it needs to be changed to address the "real" world.
If we really want to keep the HTTP user around, I suggest adding a
job-authenticated-user-name attribute which contains the HTTP user
name, while the job-originating-user-name will contain the
requested-user-name or (if not specified) the HTTP user name.
> ...
> > Also, since the spec doesn't require requesting-user-name, I don't
> > think that a compliant server can refuse the job on that basis.
>> A compliant implementation cannot refuse such a job, but an
> administrator may be allowed by the conforming implementation to
> enable such a policy. Clealy, an administrator should not do this in
> an environment where clients mostly don't include the
> requesting-user-name.
I think we're confusing the authentication done with the HTTP username
and password, and the accounting that can be performed with the
requesting-user-name attribute.
Most typical HTTP servers will log the time, IP/hostname, and username
of the requester. While spoofing of the IPP user name could be done,
it wouldn't accomplish much.
Again, I'm not saying to use requesting-user-name for access control.
That would be ridiculous considering how easy it would be to spoof
another user.
What I *am* saying is that the requesting-user-name attribute should
not be overridden by default by the HTTP username. If a client sends
a user name, that user name should be used throughout the life of a
job (and its "afterlife", if the server stores old jobs). If a client
doesn't send an IPP user name, the server should use the HTTP user name
(if available) so that *some* log of the printing user is made.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com