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