WebISO: the killer kerberos app?

[Wyllys Ingersoll]

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; 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? ;-)

The browsers don't have any idea how your realms are configured,
thats an administrative issue that is beyond the scope of the
browser.

> 
> 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

The browser will not prompt you for a user/password
when using the Negotiate authentication method.  The user must already
have credentials for the BAMBI realm or the authentication will
just fail and the user will be denied access to that particular web site.


> 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?

It can't.  See above.  Your user must be able to acquire a TGT for the BAMBI
realm (either directly or via a cross-realm exchange) or this will never work.

*IF* the browser is able to find the correct credentials in the user's
cred cache, the initial HTTP authentication header contains the uuencoded
token returned by gss_init_sec_context.

-Wyllys


> 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.
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos


-- 

Wyllys Ingersoll
Sun Microsystems, Inc
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF353913
Fingerprint: 92CD E875 59A0 798E ED9A  D75B 303A 57F0 AF35 3913