Is there an efficient way to block REST services to anonymous users?
I am running a website in ASP.NET 4.0 where people log in and according to their credentials they have access to different maps. I would like to avoid having them log in again.
The ESRI WebAdaptor is only running in ASP.NET 2.0 and I'm having a real hard time making it work with the rest of the website. I am not a web guru at all, just inherited this project lucky me.
Thank you for any suggestions or ideas!
Alex,
We had to deal with this issue within our organisation as well. We used an Apache load balancer as a reverse-proxy solution so that only authenticated user's requests to REST services were redirected.
This was the most reasonable solution in our case but you might look into ArcGIS Server token service:
Securing Internet connections to services
Which version of AGS are You using?
Related
I am being driven slowly and inexorably mad by the setup of IIS to allow access to Exchange Web Services from ASP.NET website that uses Windows Authentication. I have found literally dozens of articles on how to set this up, each of which seems to say something different, or else describes a process to me that fails when I duplicate it, presumably by there being some assumed knowledge on my part.
Application uses windows authentication to identify the user.
Application sends emails using EWS such that the email ends up in the users "sent items"
Exchange is hosted on a separate server than the web server, so I am assuming the "double-hop" I have read about issue is occurring. I am not a sysadmin, so I do not really understand this.
Is there some clear way for me to setup this up to work, and then potentially troubleshoot the problem?
Yes, from your description it certainly looks like a double-hop problem. It's non-trivial to fix, basically you need to setup delegation between the web server and the exchange server to for the web server to be able to use the kerberos ticket issued when the user logs in to the web server.
I have yet to deploy a single solution that actually does that. We have always ended up either using a service account (with appropriate access rights to exchange, mailboxes etc.) or place the web application on the exchange server. Neither option is particularly elegant, but in most cases operations teams have been unwilling to set up delegation or known how to do it properly.
Wondering about how to do the following efficiently, securely, and in a fashion that won't have us tearing our hair out because of overcomplication: we have an ASP.Net site that uses forms authentication and would like to implement some WCF restful web services that can be called from the first site, provided the user calling them has been authenticated.
We'd like to host the WCF RESTful service in a different web site from the ASP.Net site. Both sites will be in the same domain (my-domain.com for instance).
I've been reading up on the various bindings in WCF and am not sure if webHttpBindings are the way to go here (they being the most REST-friendly, but can they accommodate forms-authenticated users?)
I'm looking for suggestions and references as much as code, but I'd love to know where to start and what to look for, what's possible and what isn't.
Every time I read about WCF authentication it seems to inevitably sluice into discussions about WS-security and X509 certificates, and I don't know that I need all that for what I'm doing? What I'm really looking to build is a series of WCF restful services that only respond to forms-authenticated users. If that's not possible without diving deep into WS-Security and X509 then so be it, but I'd like to keep it as simple as possible.
Note: I asked a somewhat similar question about a month ago, but have decided to go with forms authentication.
If you are not calling your WCF services from the browser, then you don't even need to secure them. Just call them from your ASPX code to a non-public site that hosts WCF. Or use X509 certs in a server-to-server mode.
If you do plan to call them from the browser, then things get more complicated. In this case, you may want to ditch WCF and look at with Web API included in the MVC 4 beta release to build your REST services.
http://www.asp.net/web-api
Have your javascript generated from the code behind. If Page.User.IsAuthenticated, render the ajax script. If not, render javascript that alerts the user that they need to be logged in. If you don't want the user cutting the javascript out of the browser source and running it later, when they are not authenticated, you will need to generate a token based on the session ID, that can be passed between the site and the service.
We manage a website that runs of the .NET 4 framework and we need to implement SAML 2.0 to support single sign on. We do not wish to run Active Directory federation services as all user accounts are stored in a SQL server. What do I need to consider when developing a single sign on service whereby we are the identity provider?
I work with SiteMinder Federation Services (SMFSS) and Federtation Manager for CA. Are you planning on also doing Authorization for the SP based on Attributes? Do you have an Authorization SSO Solution already? IF so what is it? If it is SiteMinde then the fastes easiest to impliment solution would be SMFSS. Aside from from ServletExec and Java JDK bugs which are pretty much fixed up now I can get customers who have never used Federation up and running in a day for a SAML 2.0 POC. So, if you do have SiteMinder I would give that a try and I am sure you will be quite pleased. If not we also have Federtion Manager which can run as a proxy into your site or not. We have customers who do things such as use the SiteMinder access logs to charge users for access to SP sites a certain charge per access. We have the attribute Authority so that if you want to provide Authorization based on user attributes you can do that. If SMFSS is on the SO side you can just have the attributes stored on the SPO sides session store. Can you tell more about your use case? When SiteMinder was orignally created one of the uses cases was for SSO between different web servers, etc.
Let me know if I can help with any follow up questions and have a splendid day!
Thanks!
Crissy Krueger Stone
CA SiteMinder Support
Based on your initial requirements, you should take a look at PingFederate from Ping Identity [Note: I do work for Ping I'd]. It can support multiple databases and directories simultaneously as well as provide multi-protocol support in both an IDP and SP role. We can also support different development languages you may have beyond. NET.
HTH- Ian
I need to lock down a wcf service with basic authentication and SSL. However it is on shared hosting who won't enable it for me. Is there a way of mimicing basic authentication in code with just code that would likely work in a shared environment? I want SharePoint Online to read this wcf service and apparently it presents credentials as basic.
You probably will not be able to get this done with your shared hosting service. SSL requires a registered domain name to associate with the keys. Your hosting service should offer a dedicated site with SSL, shop around for the best price.
First let me explain the problem:
I have a little portal that any user from the internet can access.This portal is responsible only for the user authentication against a DB.If user is validated than the portal shows a list of links where they redirect to multiple web sites(this sites are in various coding languages like PHP,ASP.net and Java). If the user input the url off a web site directly on the browser, the user can access the website.I want the multiple sites can only be viewed if the page request came from the portal and not directly inputed n browser.
I have local server with IIS 6, and the portal and websites are in this server.
Can anyone help?
Thanks in advance.
Gabe
If possible , host those applications as Virtual Directories under your authentication application and restrict access to only authenticated users, this shall solve the problem.
I don't know if you are able to do this, but you could try this with an ISA/Forefront server.
You can configure this to do the redirecting for you if someone enters the website url. This way users will need to authenticate themselves and you can let ISA or FF handle the authentication part.
This is implemented a lot for OWA, but can also be used for other purposes (I've done this for several SharePoint solutions).
Of course you do need an extra server, licences and all that stuff.
Don't know how you can pull something like this with only IIS. Perhaps with some IIS Modules, but I haven't got any experience with that kind of stuff, so don't know for sure.