Reverse Proxy?
-
@jimmy9008 said in Reverse Proxy?:
even though they are outside of the office.
But that's not what they are paying for, at least from how you described it here.
-
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
because the IP recognition isnt working getting
The IP recognition is 100% working. It's doing exactly what it was, presumably, designed to do.
Yes. It does work. Folks on premise at their respective org using the service can get where they need to go. Its when those folk want to use the service from home, from starbucks, from a hotel, from whererver... thats the issue. Despite easy ways to reset your own password, they open calls to our helpdesk as they cant login (as since they are off their main site, they will require the UN/PW as they cannot be IP rec'd)
-
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
because the IP recognition isnt working getting
The IP recognition is 100% working. It's doing exactly what it was, presumably, designed to do.
Yes. It does work. Folks on premise at their respective org using the service can get where they need to go. Its when those folk want to use the service from home, from starbucks, from a hotel, from whererver... thats the issue. Despite easy ways to reset your own password, they open calls to our helpdesk as they cant login (as since they are off their main site, they will require the UN/PW as they cannot be IP rec'd)
I understand how the software works, you've done a wonderful job explaining it. It just seems like you're searching for a solution to a problem that doesn't actually exist, at least to me. The customer (I was mistaken that it was just Universities) pays for their public IP address to be white-listed with the service and now wants access from anywhere with the same rights.
Here is a product idea. Implement a SAML-esque (or just SAML) login tool and push the authentication off to the businesses that purchase from you. Your company could up sell it calling it "login from anywhere" and charge for it similar as to how you're doing IP white-listing.
-
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
even though they are outside of the office.
But that's not what they are paying for, at least from how you described it here.
I'd like to find a way where we are able to accomplish that for them when working outside of the office. It will give them the same level of servcie and the site will work in the same way; and for us, we will lose a lot of helpdesk tickets for UN/PW where the folks do not remember what it is.
-
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
even though they are outside of the office.
But that's not what they are paying for, at least from how you described it here.
I'd like to find a way where we are able to accomplish that for them when working outside of the office. It will give them the same level of servcie and the site will work in the same way; and for us, we will lose a lot of helpdesk tickets for UN/PW where the folks do not remember what it is.
Sure but how much does that solution cost as opposed to the tickets in the system? You've said that users can reset their own password. Just forwarding them the link to that tool and closing the ticket would be faster and cheaper then trying to figure out how to do this with the current authentication method.
-
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
because the IP recognition isnt working getting
The IP recognition is 100% working. It's doing exactly what it was, presumably, designed to do.
Yes. It does work. Folks on premise at their respective org using the service can get where they need to go. Its when those folk want to use the service from home, from starbucks, from a hotel, from whererver... thats the issue. Despite easy ways to reset your own password, they open calls to our helpdesk as they cant login (as since they are off their main site, they will require the UN/PW as they cannot be IP rec'd)
I understand how the software works, you've done a wonderful job explaining it. It just seems like you're searching for a solution to a problem that doesn't actually exist, at least to me. The customer (I was mistaken that it was just Universities) pays for their public IP address to be white-listed with the service and now wants access from anywhere with the same rights.
Here is a product idea. Implement a SAML-esque (or just SAML) login tool and push the authentication off to the businesses that purchase from you. Your company could up sell it calling it "login from anywhere" and charge for it similar as to how you're doing IP white-listing.
That sounds like an idea worth looking at, as the proxy will not work. We would not want all of their traffic hitting us.
Any pointers? -
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
because the IP recognition isnt working getting
The IP recognition is 100% working. It's doing exactly what it was, presumably, designed to do.
Yes. It does work. Folks on premise at their respective org using the service can get where they need to go. Its when those folk want to use the service from home, from starbucks, from a hotel, from whererver... thats the issue. Despite easy ways to reset your own password, they open calls to our helpdesk as they cant login (as since they are off their main site, they will require the UN/PW as they cannot be IP rec'd)
I understand how the software works, you've done a wonderful job explaining it. It just seems like you're searching for a solution to a problem that doesn't actually exist, at least to me. The customer (I was mistaken that it was just Universities) pays for their public IP address to be white-listed with the service and now wants access from anywhere with the same rights.
Here is a product idea. Implement a SAML-esque (or just SAML) login tool and push the authentication off to the businesses that purchase from you. Your company could up sell it calling it "login from anywhere" and charge for it similar as to how you're doing IP white-listing.
That sounds like an idea worth looking at, as the proxy will not work. We would not want all of their traffic hitting us.
Any pointers?It really depends on how your app is written.... as well as how your customer's implement authentication/authorization. I like SAML and SSO but it doesn't fit with a lot of businesses in a lot of places.
-
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
even though they are outside of the office.
But that's not what they are paying for, at least from how you described it here.
I'd like to find a way where we are able to accomplish that for them when working outside of the office. It will give them the same level of servcie and the site will work in the same way; and for us, we will lose a lot of helpdesk tickets for UN/PW where the folks do not remember what it is.
Sure but how much does that solution cost as opposed to the tickets in the system? You've said that users can reset their own password. Just forwarding them the link to that tool and closing the ticket would be faster and cheaper then trying to figure out how to do this with the current authentication method.
Having users open a call as they cannot access a service they thought they had access to (via IP rec), is pretty bad. They dont understand that outside of the office = not IP rec. However, as it happens, if those users feedback that they cannot login repeatedly, we could lose the subscription in following years. By having a way (I guess non IP based) to allow them easy access in and out of the office, they are getting what they expect, and no complaints = resubscribe.
-
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
because the IP recognition isnt working getting
The IP recognition is 100% working. It's doing exactly what it was, presumably, designed to do.
Yes. It does work. Folks on premise at their respective org using the service can get where they need to go. Its when those folk want to use the service from home, from starbucks, from a hotel, from whererver... thats the issue. Despite easy ways to reset your own password, they open calls to our helpdesk as they cant login (as since they are off their main site, they will require the UN/PW as they cannot be IP rec'd)
I understand how the software works, you've done a wonderful job explaining it. It just seems like you're searching for a solution to a problem that doesn't actually exist, at least to me. The customer (I was mistaken that it was just Universities) pays for their public IP address to be white-listed with the service and now wants access from anywhere with the same rights.
Here is a product idea. Implement a SAML-esque (or just SAML) login tool and push the authentication off to the businesses that purchase from you. Your company could up sell it calling it "login from anywhere" and charge for it similar as to how you're doing IP white-listing.
That sounds like an idea worth looking at, as the proxy will not work. We would not want all of their traffic hitting us.
Any pointers?It really depends on how your app is written.... as well as how your customer's implement authentication/authorization. I like SAML and SSO but it doesn't fit with a lot of businesses in a lot of places.
This is a bit outside of my knowledge, but are we able to provide them with a certificate they deploy? When they visit the site, the page can check for the certificate and display to the level they expect?
-
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
even though they are outside of the office.
But that's not what they are paying for, at least from how you described it here.
I'd like to find a way where we are able to accomplish that for them when working outside of the office. It will give them the same level of servcie and the site will work in the same way; and for us, we will lose a lot of helpdesk tickets for UN/PW where the folks do not remember what it is.
Sure but how much does that solution cost as opposed to the tickets in the system? You've said that users can reset their own password. Just forwarding them the link to that tool and closing the ticket would be faster and cheaper then trying to figure out how to do this with the current authentication method.
Having users open a call as they cannot access a service they thought they had access to (via IP rec), is pretty bad. They dont understand that outside of the office = not IP rec. However, as it happens, if those users feedback that they cannot login repeatedly, we could lose the subscription in following years. By having a way (I guess non IP based) to allow them easy access in and out of the office, they are getting what they expect, and no complaints = resubscribe.
No this is not bad. THis is poorly educated users. Users do not buy your systems. Universities do. The University is the one with the problem. You update your education to the University. They have to be responsible for updating their users.
-
@jaredbusch said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
even though they are outside of the office.
But that's not what they are paying for, at least from how you described it here.
I'd like to find a way where we are able to accomplish that for them when working outside of the office. It will give them the same level of servcie and the site will work in the same way; and for us, we will lose a lot of helpdesk tickets for UN/PW where the folks do not remember what it is.
Sure but how much does that solution cost as opposed to the tickets in the system? You've said that users can reset their own password. Just forwarding them the link to that tool and closing the ticket would be faster and cheaper then trying to figure out how to do this with the current authentication method.
Having users open a call as they cannot access a service they thought they had access to (via IP rec), is pretty bad. They dont understand that outside of the office = not IP rec. However, as it happens, if those users feedback that they cannot login repeatedly, we could lose the subscription in following years. By having a way (I guess non IP based) to allow them easy access in and out of the office, they are getting what they expect, and no complaints = resubscribe.
No this is not bad. THis is poorly educated users. Users do not buy your systems. Universities do. The University is the one with the problem. You update your education to the University. They have to be responsible for updating their users.
I do see your point. The reset password feature is more than easy to use. Its standard reset password link as with other sites... I get what you are saying above too.
-
Pretty simple, User must access from your web app from customer wan address range initially, place a session cookie without expiration for 30/60/90 days and just keep them logged in that way.
It’s definitely something you can resolve within your web server and app without tunnels or proxies.
Anything else you are referring to would require IT planning from the university side.
-
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@bigbear said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@bigbear said in Reverse Proxy?:
What is the website/service offering?
Were a research platform for law. This doesnt affect the content at all. This regards users accessing the service...
Gotcha, similar to a Lexis Nexis?
So you are restricting traffic to ip ranges as a method of adding additional security?
Yes. Similar indeed. No, not for additional security. Its additional functionality. For organisations that sign up for that service, all users of their LAN (as they all have the same gateway/ip) have access to the site without needing a un/pw.
Problem is, when off of the LAN, they still expect to have access but cannot. By having a proxy, they can.
So they pay for people on their LAN to have access. Is it defined that way in the agreement? If it is then your job is done.
They will subscribe to the service with IP recognition, so that users that do not login (although all have creds), can still access 90% of functionality.
What im trying to solve is that we get a lot of helpdesk calls from users outside of their physical office, saying that they are unable to login (many dont bother to remember their passwords), because the IP recognition isnt working getting them to the point they usually work...
Tell them too bad? The schools pay for one thing and you're trying to provide something above and beyond that. If they want that type of access then you need to build out a system to support that.
They already have, it's called a username/password when not on campus.
-
@dashrender said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@bigbear said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@bigbear said in Reverse Proxy?:
What is the website/service offering?
Were a research platform for law. This doesnt affect the content at all. This regards users accessing the service...
Gotcha, similar to a Lexis Nexis?
So you are restricting traffic to ip ranges as a method of adding additional security?
Yes. Similar indeed. No, not for additional security. Its additional functionality. For organisations that sign up for that service, all users of their LAN (as they all have the same gateway/ip) have access to the site without needing a un/pw.
Problem is, when off of the LAN, they still expect to have access but cannot. By having a proxy, they can.
So they pay for people on their LAN to have access. Is it defined that way in the agreement? If it is then your job is done.
They will subscribe to the service with IP recognition, so that users that do not login (although all have creds), can still access 90% of functionality.
What im trying to solve is that we get a lot of helpdesk calls from users outside of their physical office, saying that they are unable to login (many dont bother to remember their passwords), because the IP recognition isnt working getting them to the point they usually work...
Tell them too bad? The schools pay for one thing and you're trying to provide something above and beyond that. If they want that type of access then you need to build out a system to support that.
They already have, it's called a username/password when not on campus.
Exactly!
-
@bigbear said in Reverse Proxy?:
Pretty simple, User must access from your web app from customer wan address range initially, place a session cookie without expiration for 30/60/90 days and just keep them logged in that way.
It’s definitely something you can resolve within your web server and app without tunnels or proxies.
Anything else you are referring to would require IT planning from the university side.
That would work well. I will look in to it.
Are we able to supply them with a file they can distribute internally, thather than a cookie on first visit?
-
@bigbear said in Reverse Proxy?:
Pretty simple, User must access from your web app from customer wan address range initially, place a session cookie without expiration for 30/60/90 days and just keep them logged in that way.
It’s definitely something you can resolve within your web server and app without tunnels or proxies.
Anything else you are referring to would require IT planning from the university side.
Actually do a $_cookie and you can then get more metrics on users or a HTTP cookie.
-
@jimmy9008 said in Reverse Proxy?:
@bigbear said in Reverse Proxy?:
Pretty simple, User must access from your web app from customer wan address range initially, place a session cookie without expiration for 30/60/90 days and just keep them logged in that way.
It’s definitely something you can resolve within your web server and app without tunnels or proxies.
Anything else you are referring to would require IT planning from the university side.
That would work well. I will look in to it.
Are we able to supply them with a file they can distribute internally, thather than a cookie on first visit?
Really wouldn’t make sense to add that layer of complication but yes you could.
It would be less effort to the user to identify wan address and place a unique $_cookie file while they initially access the site from campus. That would give you metrics to play with later about individual use, and you could identify and block based on unique ID later if there is abuse (like a one time visitor gaining access who never returns to campus)
-
@jaredbusch said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
@coliver said in Reverse Proxy?:
@jimmy9008 said in Reverse Proxy?:
even though they are outside of the office.
But that's not what they are paying for, at least from how you described it here.
I'd like to find a way where we are able to accomplish that for them when working outside of the office. It will give them the same level of servcie and the site will work in the same way; and for us, we will lose a lot of helpdesk tickets for UN/PW where the folks do not remember what it is.
Sure but how much does that solution cost as opposed to the tickets in the system? You've said that users can reset their own password. Just forwarding them the link to that tool and closing the ticket would be faster and cheaper then trying to figure out how to do this with the current authentication method.
Having users open a call as they cannot access a service they thought they had access to (via IP rec), is pretty bad. They dont understand that outside of the office = not IP rec. However, as it happens, if those users feedback that they cannot login repeatedly, we could lose the subscription in following years. By having a way (I guess non IP based) to allow them easy access in and out of the office, they are getting what they expect, and no complaints = resubscribe.
No this is not bad. THis is poorly educated users. Users do not buy your systems. Universities do. The University is the one with the problem. You update your education to the University. They have to be responsible for updating their users.
Totally this! Whomever is buying this service from you - be it law offices or Law schools, etc... they have a requirement, set forth by you, that they educate their users that in office access requires no authentication, and out of office access requires authentication.
I suppose one thing you could look at doing is put a logon page in front the IP whitelisted folks that has a per-authorized button on it to force the users to realize that they are in fact going through a logon process regardless of location. When they are onsite, they only click the pre-auth button, when offsite, they type in their username/passwords.
-
@bigbear said in Reverse Proxy?:
Pretty simple, User must access from your web app from customer wan address range initially, place a session cookie without expiration for 30/60/90 days and just keep them logged in that way.
It’s definitely something you can resolve within your web server and app without tunnels or proxies.
Anything else you are referring to would require IT planning from the university side.
Not a half bad idea. I wonder though - would the cookie be stealable, and therefore usable by anyone? Not sure how much this would matter, just trying to cover more of the bases.
-
@dashrender said in Reverse Proxy?:
@bigbear said in Reverse Proxy?:
Pretty simple, User must access from your web app from customer wan address range initially, place a session cookie without expiration for 30/60/90 days and just keep them logged in that way.
It’s definitely something you can resolve within your web server and app without tunnels or proxies.
Anything else you are referring to would require IT planning from the university side.
Not a half bad idea. I wonder though - would the cookie be stealable, and therefore usable by anyone? Not sure how much this would matter, just trying to cover more of the bases.
It could live for say 2 weeks. Provisint the person checks in from the correct location at least every two weeks, they will have a valid cookie.
Interesting re being stolen? Could we put the machine name encoded within the cookie? If stolen, it wont match the other machine name...
