Robert Collins wrote:
> I'm not quite sure I follow on the use@something... could you elaborate?
Lets assume the forwarding is configured to use
login=*@this-cache.com:my_secret_password
And the parent is configured to receive forwarded credentials using this
format. What the parent then could do is to strip away the user@ part
from the credentials for it's own authentication processing, but use the
full credentials for logging and "user" ACL list processing.
> a) it's replayable (I know - broken record)
And this I do not get fully get. Please explain.
> b) the upstream cache's own authentication mechanism gets trodden all over. The point being that we're not doing procy
> authentication here, we're doing name passing.
In many cases the peer also does authentication and access controls, as
you describe below.
> AND cannot easily simultaneously authenticate the actual proxy
> and other users (ie they have a RADIUS based authenticator, that
> all their local users use. They have to code a special case to
> detect and authenticate the overloaded proxy case. And we're
> still extending rfc 2616 - without addressing the core issue.
By using the *@this-cache.com extension, this-cache.com is put in the
domain of the peer for authentication purposes, but user@this-cache.com
is used for identification.
And no, we are not extending RFC 2616, or even 2617. The protocols stays
exacly the same, only the application of the protocols differs. What the
login= option does is authentication to the upstream, and the method of
authentication is defined to optionally include the name of the locally
authorized user.
No, this is not a credentials passing method per se.
/Henrik
Received on Tue Jan 09 2001 - 08:56:44 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:15 MST