We've just done something that _appears_ similar to the
question here, but on an IIS Server.
Clients had credentials to identify themselves to Server A,
but were unwilling to have their credentials presented to server B.
Server A therefore, opened an SSL connection on Server B using
its own certificate. The mechanism we used was IIS ASP, and
we found an SSL client control somewhere on the Internet. The
only excitement was suppressing any request for which certificate
to use on this client, and passwords for access to it.
A disadvantage of this is that client must trust server A to report
accurately its conversation with server B. We came up with a
way to do this that would work in low-volume, because this server
wouldn't have more than 5.000 hits in its entire life. Server A
created a token for client which client's owner could trace into
Server B's output.
I imagine that what we did on IIS could be scripted around s_client
(but I'm not volunteering to write it!) on any server.
HTH
Mike Murphy
> -----Original Message-----
> From: Rich Salz [mailto:[EMAIL PROTECTED]]
> Sent: donderdag 23 maart 2000 5:15
> To: [EMAIL PROTECTED]
> Subject: Re: authentication delegation
>
>
> > My question is, how's a typical authentication
> delegation implemented
> > using SSL? I can visualize a point-to-point authetication
> happening between
> > the client and ServiceA. But, how can I control access to ServiceB's
> > resources by ServiceA unless ServiceA is acting on behalf
> of a authorised
> > user? Surely, I dont want ServiceA to know the clients
> Private key....
>
> Assuming
> Client <--> Service A <--> Service B
> I don't believe you can do this with straight SSL. You will have to
> build some extra security protocol on top of, underneath, or "next to"
> it. Simplest is to define a protocol where A can say "treat
> me like you
> would the Client" and B is configured to allow A to do arbitrary
> impersonation. You might be able, with participation of the
> Client, have
> A play a man-in-the-middle game.
>
> This is really one of those places where it is important to understand
> the subtlies of *transport* level security as opposed to
> end-to-end. :)
>
> > Wonder how those CORBA ORB-s use SSL for security when
> delegation is
> > involved.
>
> Those who do it right add their own I&A (identification and
> authorization)
> on top of SSL. There's a reason why (last time I looked) IIOP had its
> own security payload.
> /r$
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
