How to block access to certain domains?

[yoursurrogategod]

This is more of a software design concept, so I wasn't really sure where to post it.

 

Say I have a customer portal.  But, I'd like to limit who has access to it.  It should block out those who try to access it based on domain.  Say, the company has a service and they would like to provide it only to specific (read: paying) entities.  What I was thinking about was having a white-list setup, where you have two tiers of permissions:

 

1 - You let people in based on domain, so if they're coming from www.yahoo.com, then they're all good, but if the request is coming from 129.34.92.32 and we have no idea what this is, the request is simply ignored.

2 - Now, you might want to let others in later on.  Say you have employees that work from home.  Then, from the permitted domain, you can enter specific domain access based on IP-address or other domain and assign some expiration parameters (how long this person will have access to this site, does the access expire after a set amount of time, etc.)

 

Does this sound reasonable?  Logical?  Does it seem that I'm missing something?

Edited March 18, 2013 by yoursurrogategod

[requinix]

Those are two different things. #1 is about checking the referrer: where the user was before they reached the site. This is not trustworthy and very much spoofable so don't use it for security.

 

#2 is about a firewall configuration and only allowing access from certain IP addresses. This is okay. Keep in mind that many people may share the same address, such as in an office or college dorm. Spoofing IP addresses is possible but almost always a fruitless endeavor so it's fairly safe to use.

[yoursurrogategod]

Those are two different things. #1 is about checking the referrer: where the user was before they reached the site. This is not trustworthy and very much spoofable so don't use it for security.

 

#2 is about a firewall configuration and only allowing access from certain IP addresses. This is okay. Keep in mind that many people may share the same address, such as in an office or college dorm. Spoofing IP addresses is possible but almost always a fruitless endeavor so it's fairly safe to use.

Ok, I don't really understand what you wrote for #1 .  Is it possible to spoof a domain like yahoo.com or microsoft.com?  What I was envisioning is something that permits access based on those domains and then when you're established there, you can grant access to other users outside that domain.  Feel free to correct me if what I'm saying doesn't sound like a good idea.

[requinix]

I can set a referrer of absolutely anything I want. Doesn't have to be a page I've been on. Doesn't even have to be a URL.

 

But now it sounds like you're talking about things like OAuth: someone signs into another site (like microsoft.com or yahoo.com) and you receive information telling you about who the user is - not the credentials, but say username and real name and potentially other things. "Social login" is another term I've heard because nowadays it's most commonly used for Facebook or Twitter users.

[yoursurrogategod]

I can set a referrer of absolutely anything I want. Doesn't have to be a page I've been on. Doesn't even have to be a URL.

 

But now it sounds like you're talking about things like OAuth: someone signs into another site (like microsoft.com or yahoo.com) and you receive information telling you about who the user is - not the credentials, but say username and real name and potentially other things. "Social login" is another term I've heard because nowadays it's most commonly used for Facebook or Twitter users.

I'll look into OAuth.  Thanks for the moment.  I'll post again if there are questions that I have no idea about.

[yoursurrogategod]

I can set a referrer of absolutely anything I want. Doesn't have to be a page I've been on. Doesn't even have to be a URL.

 

But now it sounds like you're talking about things like OAuth: someone signs into another site (like microsoft.com or yahoo.com) and you receive information telling you about who the user is - not the credentials, but say username and real name and potentially other things. "Social login" is another term I've heard because nowadays it's most commonly used for Facebook or Twitter users.

Hey, quick question.

 

I'm reading this RFC on Oauth:

http://tools.ietf.org/html/rfc6749

 

I get to this point:

 

In the traditional client-server authentication model, the client

requests an access-restricted resource (protected resource) on the

server by authenticating with the server using the resource owner's

credentials. In order to provide third-party applications access to

restricted resources, the resource owner shares its credentials with

the third party. This creates several problems and limitations:

 

Who would be the resource owner in this case?  The client?  I see primarily 3 parties involved: the host, the client and the 3rd party that wants what the client has access to.

[yoursurrogategod]

Like, this is how I view this universe based on reading that paragraph.

 

+--------+       +----------------+       +-----------------+
| Client | --- > | Resource Owner | --- > | Resource Server |
+--------+       +----------------+       +-----------------+

So, lets say that the "Resource Server" is facebook and the "Resource Owner" is Bob (he posts pictures and greets his friends on there), but he would like to give access to a Desktop app -- the "Client" -- to collect some metrics on his media (the scope of this access can be defined).  So, "Resource Owner" Bob would log into "Resource Server" facebook, generate a token and paste it into the "Client" Desktop app and have that little puppy go on its merry way.

 

Is my explanation sensible?  Am I missing something?

Edited March 20, 2013 by yoursurrogategod

[requinix]

Almost, except Bob doesn't have to do that himself.

 

Say it's a Web app instead of a Desktop app - easier to demonstrate (and more common).

Before anything else,

1. The developers of the Web app sign up for a "developer account" at Facebook. There they receive unique information such as a developer ID and an API key. Those two are used to contact facebook.com for pretty much everything it may want to do. They also tell Facebook where their Web app can be contacted - this is the most important point. With that setup either side can start communication with the other.

2. The Web app is set up to allow for a Facebook login.

 

Bob comes to the Web app.

1. He chooses the "Log in with Facebook" (or whatever) option.

2. Behind the scenes the app tells facebook.com that it wants to let a user log in. facebook.com responds with a special URL, or maybe just a token to use in a URL.

3. The app sends Bob to that URL and he logs in.

4. facebook.com knows from the URL that the user was logging in from the Web app. Assuming all went well it contacts the app back (also behind the scenes) with some special key it can use to get more information about Bob later.

5. facebook.com sends Bob back to the Web app.

6. The App remembers Bob from the session, recalls the key it received moments before, and uses the facebook.com API to get whatever user information it wants/has access to.

 

The three main steps are (1) the Client negotiates with the Server to get a location where it sends the Owner to authenticate, (2) the Server processes the login and sends a key to the Client that it can use to look up Owner's information (how it does so is irrelevant to this process), then as a common courtesy it (3) returns the Owner to the Client.

I'm not sure how this gets translated to desktop apps because facebook.com can't communicate with them directly and that's a very important part of the security model.

[yoursurrogategod]

Almost, except Bob doesn't have to do that himself.

 

Say it's a Web app instead of a Desktop app - easier to demonstrate (and more common).

Before anything else,

1. The developers of the Web app sign up for a "developer account" at Facebook. There they receive unique information such as a developer ID and an API key. Those two are used to contact facebook.com for pretty much everything it may want to do. They also tell Facebook where their Web app can be contacted - this is the most important point. With that setup either side can start communication with the other.

2. The Web app is set up to allow for a Facebook login.

 

Bob comes to the Web app.

1. He chooses the "Log in with Facebook" (or whatever) option.

2. Behind the scenes the app tells facebook.com that it wants to let a user log in. facebook.com responds with a special URL, or maybe just a token to use in a URL.

3. The app sends Bob to that URL and he logs in.

4. facebook.com knows from the URL that the user was logging in from the Web app. Assuming all went well it contacts the app back (also behind the scenes) with some special key it can use to get more information about Bob later.

5. facebook.com sends Bob back to the Web app.

6. The App remembers Bob from the session, recalls the key it received moments before, and uses the facebook.com API to get whatever user information it wants/has access to.

 

The three main steps are (1) the Client negotiates with the Server to get a location where it sends the Owner to authenticate, (2) the Server processes the login and sends a key to the Client that it can use to look up Owner's information (how it does so is irrelevant to this process), then as a common courtesy it (3) returns the Owner to the Client.

I'm not sure how this gets translated to desktop apps because facebook.com can't communicate with them directly and that's a very important part of the security model.

Doesn't have to be a desktop app, that's just the first thing that I came up with .

 

Thanks for your help.