Damon Rand wrote:
There is no reason why a user cannot obtain tickets for more than
one realm provided that they are managed properly by the application.
The TGT for the ACME domain will be in one credential cache; if
the ACME domain TGT cannot be used for cross-realm authentication
with BAMBI;
Russ Allbery [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
[snip]
The application server then receives and decodes that authenticator,
validates it, and then creates a cookie containing a more persistant
authenticator just for that service. That cookie is, however, now that
Russ Allbery [EMAIL PROTECTED] write:
kevin mcgowan [EMAIL PROTECTED] writes:
With kx.509, users have the power to never send their Kerberos password
over the network -- translating desktop single sign-on to the web.
Cosign uses no domain cookies, allows users to logout of all cosign
On Mar 9, 2004, at 1:14 AM, Russ Allbery wrote:
For whatever it's worth, the reason why we didn't go with a solution
based
on client-side certificates is that it doesn't make it possible for
application servers to obtain credentials on behalf of the user and
that
was one of our requirements.
Kevin Coffman [EMAIL PROTECTED] writes:
Our answer to the proxy issue when certificates are used for
authentication is Kerberized Credentials Translation (KCT). The web
server captures the SSL handshake between itself and the client,
forwards that handshake and other info to the KCT (a
Russ Allbery wrote:
Kevin Coffman [EMAIL PROTECTED] writes:
Our answer to the proxy issue when certificates are used for
authentication is Kerberized Credentials Translation (KCT). The web
server captures the SSL handshake between itself and the client,
forwards that handshake and
On Thu, 2004-03-04 at 20:43, Russ Allbery wrote:
Christopher Kranz [EMAIL PROTECTED] writes:
It occurred to me that if you think of the web client as the credentials
cache Kerberos could easily be used as a WebISO solution. The web
client connects to the web app. If you don't already
Wyllys Ingersoll [EMAIL PROTECTED] writes:
Isn't this very similar to the what Passport and Project Liberty propose
to use? Basically, its a variation of the secure cookie scheme.
Netegrity does something similar as well.
Right.
Is there a comparison anywhere between webauthv3 and the
One thing I dislike about webauth is that it is using raw KRB5 as
opposed to the more portable and extensible GSSAPI interface. Why was
GSSAPI not chosen?
WebAuth only uses Kerberos v5 in one particular place, namely the
bootstrap for an application server. Note that any
Wyllys Ingersoll [EMAIL PROTECTED] writes:
Writing new code is the barrier that will prevent it from going much
beyond the experimental stage unless it is adopted by a mainstream
browser (mozilla) and web server (apache).
What makes you think that WebAuth hasn't gone beyond the experimental
On Mon, 2004-03-08 at 14:21, Russ Allbery wrote:
Wyllys Ingersoll [EMAIL PROTECTED] writes:
Writing new code is the barrier that will prevent it from going much
beyond the experimental stage unless it is adopted by a mainstream
browser (mozilla) and web server (apache).
What makes you
What makes you think that WebAuth hasn't gone beyond the experimental
stage?
I guess I chose the wrong words there. Basically, I just meant moving
it beyond Stanford and into the mainstream. I did not mean to
marginalize your efforts.
Actually ... judging by the people who want some form
kevin mcgowan [EMAIL PROTECTED] writes:
With kx.509, users have the power to never send their Kerberos password
over the network -- translating desktop single sign-on to the web.
Cosign uses no domain cookies, allows users to logout of all cosign
protected services, is capable of transferring
There's also kx509.
At 12:00 PM -0500 3/8/04, [EMAIL PROTECTED] wrote:
Date: Mon, 08 Mar 2004 08:38:05 -0500
From: Wyllys Ingersoll [EMAIL PROTECTED]
To: Russ Allbery [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: WebISO: the killer kerberos app?
Message-ID: [EMAIL PROTECTED]
In-Reply
Russ Allbery [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
Christopher Kranz [EMAIL PROTECTED] writes:
Why not just pass the TGT, the session ticket, and the authenticator as
cookies? Let Kerberos do the hard stuff. Kerberos was designed to be
able to securely
On Thursday, March 04, 2004 7:43p [EMAIL PROTECTED] wrote:
This is exactly the design of Stanford's WebAuth v3. :) See:
http://webauthv3.stanford.edu/
Is there a similar solution that will work with apache 1.3?
CDC
Christopher D. Clausen
[EMAIL PROTECTED] SysAdmin
Christopher Kranz [EMAIL PROTECTED] writes:
Why not just pass the TGT, the session ticket, and the authenticator as
cookies? Let Kerberos do the hard stuff. Kerberos was designed to be
able to securely authenticate someone over an insecure network. This way
you don't have to create new
Russ Allbery [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
This is exactly the design of Stanford's WebAuth v3. :) See:
http://webauthv3.stanford.edu/
This is lot closer to what I had envisioned than say Pubcookie. But
it still looks like it does more work than it has
I've been looking into a number of WebISO solutions over the last
several months. The one thing that struck me is how Kerberos like a
number of the solutions appear to be. That is, they use a trusted 3rd
party with a shared secret and then have a persistent token that
allows logins without
Christopher Kranz [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
No, you still have to require that the connection between the web
client and the web application server be encrypted. The thing that
you're missing is that doing regular Kerberos involves a computational
step
Christopher Kranz [EMAIL PROTECTED] writes:
I've been looking into a number of WebISO solutions over the last
several months. The one thing that struck me is how Kerberos like a
number of the solutions appear to be. That is, they use a trusted 3rd
party with a shared secret and then have a
21 matches
Mail list logo
