Re: Sharing/Forwarding website credentials programatically

From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 05/02/03 

Date: Thu, 1 May 2003 16:41:52 -0700

Hmm... I cannot think of a ready-made solution to do what you are asking.
What you are wanting is not really delegation of credentials from the portal
to individual partner servers but rather automatic login to individual
partner servers. The difference between the two is whether the client is
aware of the partner servers or not (by "aware" I mean whether the client
can directly contact that server). The reason I make this distinction is
because delegation is a pretty trusted operation that carries implications.
While delegation can result in SSO, there are other ways to achieve SSO.

You now have me curious about this problem space. I'll be asking around
about this... 

-- 
//David
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Halcyon Woodward" <kenbeaver@pacbell.net> wrote in message
news:e1U%23NTDEDHA.212@TK2MSFTNGP10.phx.gbl...
David,
Thank you very much for your response, sorry that my post was unclear; I
actually re-wrote it entirely for a cross-post to the ASP.Net security
forum.
Dispite the ambiguity, you did get to the heart of our problem, however I'll
rephrase:
The solution we are implementing is a portal that exposes information from
other web applications (business services) which reside on separate physical
servers. The portal, and each web application, require the user to
authenticate via standard IIS6 methods; namely basic [clear text]
authentication over SSL against a standard Active Directory account.  The
same AD account is used unilaterally across the portal and all applications.
Because IE 6 does not support automatic credential supplication for
clear-text authentication (otherwise placing the sites within the Trusted
Sites Zone would work) the user would have to repeatedly have to log on.
e.g. We have a link exposed through a custom webpart on the portal that
would take the user to a page served by one of the satellite web
applications - when clicking the link they would have to present their
credentials to the application server, even though they've already supplied
them to the portal.  This is what we are trying to avoid.
Passport is not an option for us, unfortunately, so I'm going to concentrate
on the second scenario:
Since all links to content can be programmatically controlled, my question
was essentialy how to encode those links so that the credentials were passed
essentially in the request-headers or URI itself.  My initial thoughts were
to accomplish this using a server-side redirect.
I've slashed together a quick example of this:
The User is authenticated and has cached credentials to ServerA but has not
authenticated to ServerB.
ServerA serves PageY with a pseudo-link to PageZ on ServerB.
PageY is the actual target of the the link, and a back-end snippet of code
intercepts the request.  The code then builds a new URI to PageZ, placing
the user's credentials (obtained from server variables) in the URI itself
like so:
    http://[username]:[password]@Server-B/Page-Z
A server-side redirect then sends the client to this URI.
PageZ accepts the request, and the credentials are authenticated for the new
server and cached on the client.  PageZ examines the incomming URI and then
builds another URI, this one without the credentials, and performs another
redirect to the 'plain' URI.
The 'plain' URI is not intercepted and the content is delivered.
The user is completey unaware that anything has taken place other than a
standard link (hopefully) and because the transaction is over SSL, there's
no chance of exposing usernames and passwords to the outside world.
--------------------------------------------------------
The code works, but is certianally not the most elegant of solutions.  I
guess what I was looking for from IIS 6 was a way of passing the credentials
without necessarally using the actual username/password combination, i.e. a
certificate that could be encoded into the URI or a header tag that the
client frog-hopped to the next server.
Wishful thinking?
hb.

Relevant Pages

  • Re: Sharing/Forwarding website credentials programatically
    ... authentication over SSL against a standard Active Directory account. ... credentials to the application server, ... was essentialy how to encode those links so that the credentials were passed ... essentially in the request-headers or URI itself. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Cached Logon
    ... > current credentials and only after failing would prompt for credentials. ... Keep in mind that whether the IE browser will supply the Windows ... the scenes" windows authentication information? ... > On the server I was logged in as domain1\administrator. ...
    (microsoft.public.sqlserver.connect)
  • Re: Cached Logon
    ... > current credentials and only after failing would prompt for credentials. ... Keep in mind that whether the IE browser will supply the Windows ... the scenes" windows authentication information? ... > On the server I was logged in as domain1\administrator. ...
    (microsoft.public.sqlserver.server)
  • Re: Cached Logon
    ... > current credentials and only after failing would prompt for credentials. ... Keep in mind that whether the IE browser will supply the Windows ... the scenes" windows authentication information? ... > On the server I was logged in as domain1\administrator. ...
    (microsoft.public.win2000.networking)
  • Re: Cached Logon
    ... > current credentials and only after failing would prompt for credentials. ... Keep in mind that whether the IE browser will supply the Windows ... the scenes" windows authentication information? ... > On the server I was logged in as domain1\administrator. ...
    (microsoft.public.inetserver.iis)