WebISO: the killer kerberos app?

[Damon Rand]

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.