|
Home > Archive > IIS Server Security > July 2007 > 'Corporate login' for a customer to a website
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
'Corporate login' for a customer to a website
|
|
|
| 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
| |
| Ken Schaefer 2007-07-11, 1:21 pm |
| 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@spireite.ndo.co.uk> wrote in message
news:1nse39x3t5kv1.9zes9nebhgl2$.dlg@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?
| |
| Ken Schaefer 2007-07-12, 1:22 am |
|
"Paul" <gupta@spireite.ndo.co.uk> wrote in message
news:1c73nlwk5pjts$.jzebbvvkb2io.dlg@40tude.net...
> On Wed, 11 Jul 2007 22:26:56 +1000, Ken Schaefer wrote:
>
>
>
> 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
| |
| Anthony 2007-07-25, 7:21 pm |
| 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@spireite.ndo.co.uk> wrote in message
news:1nse39x3t5kv1.9zes9nebhgl2$.dlg@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
>
>
>
|
|
|
|
|