Hi,

We have a website on IIS6, for which we want some customers to have the
option of accessing via clicking a button only.

Initial thought was to validate on the IP address, assuming the IP we
receive is their public facing firewall or their own proxy.

However, some customers go through third party proxies (in this case
Messagelabs). I'm asuming therefore that other companies may be going
through that proxy since its a third pary, and appear to come from that
same proxy address, so we cannot validate on that.

The header x-forwarded contains the proxy address, and not the IPs of the
customers public IP.

The customer does not want to have to login through a tradition ID/Password
scheme, and they can have multiple users.

The ideal scenario is to limit the access to that customer, so if they
forwarded the URL, it wouldn't work because its off their corporate IP.

It doesn't look like client certs will halp here either.

Does anyone have any guidance?

Cheers
Paul

The only real way to have secure authentication is to have a shared secret
that both the client, and you, share. That can either be a password, or a
client certificate, or some kind of federated identity/SSO system (e.g.
provided by ADFS).

Cheers
Ken

--
My IIS Blog: www.adOpenStatic.com/cs/blogs/ken

"Paul" <gupta [at] spireite.ndo.co.uk> wrote in message
news:1nse39x3t5kv1.9zes9nebhgl2$.dlg [at] 40tude.net...
> Hi,
>
> We have a website on IIS6, for which we want some customers to have the
> option of accessing via clicking a button only.
>
> Initial thought was to validate on the IP address, assuming the IP we
> receive is their public facing firewall or their own proxy.
>
> However, some customers go through third party proxies (in this case
> Messagelabs). I'm asuming therefore that other companies may be going
> through that proxy since its a third pary, and appear to come from that
> same proxy address, so we cannot validate on that.
>
> The header x-forwarded contains the proxy address, and not the IPs of the
> customers public IP.
>
> The customer does not want to have to login through a tradition
> ID/Password
> scheme, and they can have multiple users.
>
> The ideal scenario is to limit the access to that customer, so if they
> forwarded the URL, it wouldn't work because its off their corporate IP.
>
> It doesn't look like client certs will halp here either.
>
> Does anyone have any guidance?
>
> Cheers
> Paul
>
>
>

On Wed, 11 Jul 2007 22:26:56 +1000, Ken Schaefer wrote:

> The only real way to have secure authentication is to have a shared secret
> that both the client, and you, share. That can either be a password, or a
> client certificate, or some kind of federated identity/SSO system (e.g.
> provided by ADFS).
>
> Cheers
> Ken


Thanks Ken

My understanding is that a client certificate is unique per workstation -
isn't that going to be large overhead on management?

"Paul" <gupta [at] spireite.ndo.co.uk> wrote in message
news:1c73nlwk5pjts$.jzebbvvkb2io.dlg [at] 40tude.net...
> On Wed, 11 Jul 2007 22:26:56 +1000, Ken Schaefer wrote:
>
>> The only real way to have secure authentication is to have a shared
>> secret
>> that both the client, and you, share. That can either be a password, or a
>> client certificate, or some kind of federated identity/SSO system (e.g.
>> provided by ADFS).
>>
>> Cheers
>> Ken
>
>
> Thanks Ken
>
> My understanding is that a client certificate is unique per workstation -
> isn't that going to be large overhead on management?

Client certificates can be used "per machine" (they identify machines, but
not the users on them), or "per user" (they identify a user, not a machine)

For per user certificates, common mechanisms for transporting them resolve
around "auto enrollment" (a feature provided with Windows Server 2003
domains), or smartcards (the user carries their certificates on a physical
device).

What are you trying to authenticate though? Remote users? Or remote
workstations?

Cheers
Ken

You could create a second site on the same server with the same content, but
different IP address and anonymous access. Then allow access on your
firewall to that site only from the client IP address range. If they use NAT
on the firewall that should be quite simple,
Anthony -
http://www.airdesk.co.uk



"Paul" <gupta [at] spireite.ndo.co.uk> wrote in message
news:1nse39x3t5kv1.9zes9nebhgl2$.dlg [at] 40tude.net...
> Hi,
>
> We have a website on IIS6, for which we want some customers to have the
> option of accessing via clicking a button only.
>
> Initial thought was to validate on the IP address, assuming the IP we
> receive is their public facing firewall or their own proxy.
>
> However, some customers go through third party proxies (in this case
> Messagelabs). I'm asuming therefore that other companies may be going
> through that proxy since its a third pary, and appear to come from that
> same proxy address, so we cannot validate on that.
>
> The header x-forwarded contains the proxy address, and not the IPs of the
> customers public IP.
>
> The customer does not want to have to login through a tradition
> ID/Password
> scheme, and they can have multiple users.
>
> The ideal scenario is to limit the access to that customer, so if they
> forwarded the URL, it wouldn't work because its off their corporate IP.
>
> It doesn't look like client certs will halp here either.
>
> Does anyone have any guidance?
>
> Cheers
> Paul
>
>
>