Restrict access based on originating IP address

[toofastdad]

I have a client who has three IP address with x amount of work stations
coming from each IP address. The client does not want the users to login
each time and has requested to restrict access by originating IP address.
For example if the originating IP's are: 24.111.12.21 24.111.12.22 and
24.111.15.178.
How do I achieve this?

Thanks...Colin

[CriticalIM]

<!--- Only Security Needed Is IP Address---> <cfif #cgi.remote_addr# NEQ
24.111.12.21 AND #cgi.remote_addr# NEQ 24.111.12.22 AND #cgi.remote_addr# NEQ
24.111.15.178> <!--- Redirect To An Error Invalid Page Access --->
<cflocation url='PAGE' addtoken='No'> <cfexit method='EXITTEMPLATE'> </cfif>

[Sarge]

I would actually leverage the web server to prevent the connections from the IP
addresses. You can restrict access down to subnets if necessary. This is more
efficient than having CF (or any middleware for that matter) perform the CGI
comparison. As for the login part, how are you enforcing login now? Are you
using username/password prompts? Are you using Integrated Authentication with
IIS, Digest authentication w/Apache, etc.?

[toofastdad]

On 3/21/05 12:01 PM, in article d1mr44$hvn$1@forums.macromedia.com, "Sarge"
<ssargent@macromedia.com> wrote:

> I would actually leverage the web server to prevent the connections from the
> IP
> addresses. You can restrict access down to subnets if necessary. This is more
> efficient than having CF (or any middleware for that matter) perform the CGI
> comparison. As for the login part, how are you enforcing login now? Are you
> using username/password prompts? Are you using Integrated Authentication with
> IIS, Digest authentication w/Apache, etc.?
>

At the moment access is restricted by username/password and userrole_ID but,
this is a new area that the client wants. They have 3 IP's so I put the
IP's in the database along with userrole_ID. The IP address is used for the
username and password and I've passed the variable to get the job done...see
below.




<form name="form1" id="form1" method="POST"
action="<cfoutput>#MM_loginAction#</cfoutput>">
<p>
<input name="address" type="hidden" id="username"
value="<cfoutput>#cgi.SERVER_NAME#</cfoutput>" />
<input name="password" type="hidden" id="password"
value="<cfoutput>#cgi.SERVER_NAME#</cfoutput>" />
</p>
<p>
<input type="submit" name="Submit" value="Enter Area" />
</p>
</form>

Is this a good way of doing it?

Thanks...C

[toofastdad]

On 3/21/05 11:26 AM, in article d1mp2u$ejg$1@forums.macromedia.com,
"CriticalIM" <webforumsuser@macromedia.com> wrote:

> <cfif #cgi.remote_addr# NEQ
> 24.111.12.21 AND #cgi.remote_addr# NEQ 24.111.12.22 AND #cgi.remote_addr# NEQ
> 24.111.15.178> <!--- Redirect To An Error Invalid Page Access --->
> <cflocation url='PAGE' addtoken='No'> <cfexit method='EXITTEMPLATE'>
> </cfif>

Thanks..I tried this and it worked

<form name="form1" id="form1" method="POST"
action="<cfoutput>#MM_loginAction#</cfoutput>">
<p>
<input name="address" type="hidden" id="username"
value="<cfoutput>#cgi.SERVER_NAME#</cfoutput>" />
<input name="password" type="hidden" id="password"
value="<cfoutput>#cgi.SERVER_NAME#</cfoutput>" />
</p>
<p>
<input type="submit" name="Submit" value="Enter Area" />
</p>
</form>

Is this a good method? The example you have shown me, would that reside in
the Application.cfm

C

[Sarge]

Originally posted by: Newsgroup User At the moment access is restricted by
username/password and userrole_ID but, this is a new area that the client
wants. They have 3 IP's so I put the IP's in the database along with
userrole_ID. The IP address is used for the username and password and I've
passed the variable to get the job done...see below. <form name='form1'
id='form1' method='POST' action='<cfoutput>#MM_loginAction#</cfoutput>'> <p>
<input name='address' type='hidden' id='username'
value='<cfoutput>#cgi.SERVER_NAME#</cfoutput>' /> <input name='password'
type='hidden' id='password' value='<cfoutput>#cgi.SERVER_NAME#</cfoutput>' />
</p> <p> <input type='submit' name='Submit' value='Enter Area' /> </p>
</form> OK I think you are merging two areas of restriction -- IP-based and
username/password. If I understand you correctly, the client has multiple
machines accessing the CF server from one of 3 different IP addresses:
24.111.12.21, 24.111.12.22, and 24.111.15.178. Your requirements:to only allow
access from these three IP addresses Allow authenticated user access without
re-prompting for authentication Again, for host restriction I would leverage
the web server -- or even better at the router/firewall level. This is the most
efficient and scalable method. What happens if additional authorized IPs are
added, then you'd have to update the code (and database in your case). It would
be easier from an administrative standpoint to lock down the authorized IPs to
a subnet -- e.g. 24.111. CGI.Server_Name is actually the IP address, host
name, or DNS of the server running CF. So in effect this part of the
authentication scheme is always going to be true -- in other words it is not
working. Besides, I would not tie a user_id to an IP address because what if
the user leaves their desk and tries to authenticate from another one of the
authorized IPs? It sounds as if you are authenticating the users in another
section of the application or perhaps in another application all together, and
you want to implement single sign-on (SSO) capabilities. The key to this is to
use Cookies and Session/Client variables appropriately. You can have this new
code look for an unique user identifier in the Cookie, Client, or Session
scope, then match that with a database entry that was set when the user logged
in. So at whatever point the user logs in, create a unique identifier and
store it in a row for the user in an authorization table and in a cookie (or
client or session). Now when the user accesses this new part of the site,
verify the identifier exists and use it to seemlessly re-authenticate the user.
You can also do this with a roles-based metaphor where you retrieve the user's
roles during the first log in, then secure the new site with a role. If the
authenticated user is not a member of that role, then they do not get access to
it. HTH,