LPR just get the user name and client host from the client environment. This
is probably adequate for unauthenticated IPP transactions.
For authenticated IPP transactions, the user name can be taken from the Basic
or Digest authentication fields. The notion of client host isn't defined, but
the realm can play a similar role. Realms are defined by the server, and are
used to provide context for the user name (avoiding name clashes).
There is a major difference between LPD user names and authenticated IPP user
names. That is since the IPP user name are based on interactions with a
particular server, one user can have several different user names (one for
each server). This is different from LPD where a user generally had the same
name when using different servers.
Another issue the sequence of how a user is authenticated with the server.
1) A client makes a request of the server.
2) The server notifies the client that access is denied, and it needs to be
authenticated. This is when the server tells the client the realm.
3) The client acquires the user name & password and resubmits the original
request to the server. The details of how the credentials are passed from
client to server are the main difference between Basic & Digest authentication.
4) The server checks the client credentials and accepts or rejects the
request.
So the client has unauthenticated communications with the server (with the
unauthenticated user name) until such time the server requires authorization.
Then the client gets the authenicated user name and uses that for further
communications. So the job-originating-user will differ depending on where in
the sequence it is.
The issue does need to be clarified and addressed, probably in the security
document.
/John
------- Forwarded Message
Date: Fri, 25 Jul 1997 12:55:16 PDT
From: Robert.Herriot@Eng.Sun.COM (Robert Herriot)
To: ipp@pwg.org, rdebry@us.ibm.com
Subject: Re: IPP>SEC >MOD security and the LPD gateway
Sender: ipp-owner@pwg.org
Roger,
According to my reading of the RFC's, both basic authentication and
digest pass along a user name, but neither passes the client's host.
However, digest has the concept of realm which is the context of the
user name, and that is essentially the purpose of host name in LPD.
But I still stand by my original comment which stated that the security
document does not address the issue of supporting job-originating-host
or job-originating-user. Perhaps the model needs to abandon
job-originating-host and replace it by 'realm'.
In any case, the security document needs to state how to support the
job security attributes, such as job-originating-user, for each
security solution. Otherwise, we don't have interoperability.
Bob Herriot
> From rdebry@us.ibm.com Fri Jul 25 07:09:39 1997
>
> Doesn't digest or http basic authentication handle this? It certainly can
> identify the user.
>
> Roger K deBry
> Senior Techncial Staff Member
> Architecture and Technology
> IBM Printing Systems
> email: rdebry@us.ibm.com
> phone: 1-303-924-4080
>
>
> ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 07/25/97 07:52
> AM ---------------------------
>
> ipp-owner @ pwg.org
> 07/24/97 06:08 PM
> Please respond to ipp-owner@pwg.org @ internet
>
> To: ipp @ pwg.org @ internet
> cc:
> Subject: IPP>SEC >MOD security and the LPD gateway
>
> As I work on the LPD gateway document, I realize, once again, that the
> security documents don't deal with two attributes that we in the model
> have assumed would be handled at the security level. These attributes
> are:
>
> o job-originating-user
> o job-originating-host
>
> The LPD-to-IPP gateway receives these two values in the control file and
> the IPP-to-LPD gateway needs to put these into the control file.
>
> There may be work-arounds for the gateway. But that still leaves
> these two job attributes without any way to set them unless we make
> them explicit parameters in operations or create new HTTP headers.
>
> Comments?
>
> Bob Herriot
>
>
>
------- End of Forwarded Message