I would like to suggest that your example of a student who uses a group
name/password to access the printer but uses his name for accounting is
a worthy case, but beyond the current architecture of IPP.
To allow your example to work, IPP would need the concept of users and group
membership. It has only the former.
I believe that we should not overload existing features in IPP in order to
support this new feature. So, I stand by my statement that a printer must
ignore "requesting-user-name" when using basic, digest or none.
Bob Herriot
> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Saturday, March 27, 1999 5:29 AM
> To: Herriot, Robert
> Cc: ipp at pwg.org> Subject: Re: IPP> MOD - Issue 2: How can client force authentication,
> i.e., identified mode? Solution #2 preferred
>>> "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>