WebISO: the killer kerberos app?
Damon Rand
damon-mail at cybermagic.co.nz
Mon Mar 15 18:50:16 EST 2004
Jeffrey Altman <jaltman2 at nyc.rr.com> wrote in message news:<4055CAEF.8040303 at nyc.rr.com>...
> Damon Rand wrote:
> > Sorry to jump in late here but..
> >
> > Is the clientside solution fundamentally flawed in the extranet sense?
> > I was under the impression that the client workstation had to be
> > logged into the same domain as the server.. ie. If a web user was
> > logged into the ACME domain from their ACME workstation then they
> > can't come to my site and use SPNEGO (or SASL?) protocol to login into
> > my website authenticated against the BAMBI domain?
> >
> > I hope I am completely wrong of course!!
> >
> > Damon.
>
> 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; then the application must create a new credential cache
> and obtain a TGT for the user in BAMBI before continuing with the logon.
Do msie and mozilla manage things properly? ;-)
Looking the following negotiation example from here.
http://www.ietf.org/internet-drafts/draft-brezak-kerberos-http-00.txt
.. I can't see how this will work in the extranet scenario. Assuming
the our ACME user has just been asked to Negotiate by our BAMBI server
they will prompt the user for a username/password then
msg=my_generate_gssapi_message(username, password) then pass msg in an
Authorization header to the BAMBI server. What will this message
contain? At this point the ACME user does not have a shared secret
with the BAMBI server so how can it provide credentials?
Damon.
5. Negotiate Operation Example
The client requests an access-protected document from server via a
GET method request. The URI of the document is
"http://www.nowhere.org/dir/index.html".
C: GET dir/index.html
The first time the client requests the document, no Authorization
header is sent, so the server responds with:
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Negotiate
The client will obtain the user credentials using the SPNEGO GSSAPI
mechanism type to identify generate a GSSAPI message to be sent to
the server with a new request, including the following
Authorization
header:
C: GET dir/index.html
C: Authorization: Negotiate a87421000492aa874209af8bc028
The server will decode the gssapi-data and pass this to the SPNEGO
GSSAPI mechanism in the gss_accept_security_context function. If
the
context is not complete, the server will respond with a 401 status
code with a WWW-Authenticate header containing the gssapi-data.
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356
The client will decode the gssapi-data and pass this into
gss_init_security_context and return the new gssapi-data to the
server.
C: GET dir/index.html
C: Authorization: Negotiate 89a8742aa8729a8b028
This cycle can continue until the security context is complete.
When the return value from the gss_accept_security_context function
indicates that the security context is complete, it may supply
final
authentication data to be returned to the client. If the server has
more gssapi data to send to the client to complete the context it
is
to be carried in WWW-Authenticate header with the final response
containing the HTTP body.
S: HTTP/1.1 200 Success
S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca
The client will decode the gssapi-data and supply it to
gss_init_security_context using the context for this server. If the
status is successful from the final gss_init_security_context, the
response can be used by the application.
More information about the Kerberos
mailing list