We are developing a Intranet portal that uses integrated authentication, but a few sections of the site will be exposed to users who are not in the domain. For those users we plan to use anonymous access. However, our display logic for the entire application is based on the user logged into the portal, so we are not fully comfortable with this approach. The URL has to be same for both types of users and transitioning between both the environments has to be seamless.
We tried using user controls in pages to authenticate but things didnt pan out. When the page is reached the standard windows authentication grey box pops up.
Is there any way to intercept the request at the IIS level like an HTTP application?
If applicable we would disable anonymous access and for unauthenticated users we will impersonate with a least privileged domain account and redirect to the home page.
SharePoint isn't really designed for the scenario you describe of mixing types of authentication. It dedicates a web application to one type of authentication. You can then 'extend' that web application to use another type of authentication on another address. For example, your intranet portal would use Windows authentication. It could then be extended to use anonymous authentication on another port or domain name.
One option for what you describe is to configure two separate web applications. One is for users that need to authenticate. The other is for anonymous access. Configure the content in the appropriate locations and link between the two as necessary. Users within your domain should not receive a login prompt when connecting to the authenticated site if you use this approach. Users outside your domain will receive a login box and won't be able to access.
Consider using forms authentication for users outside your domain if they need to access your intranet. (Once again the 'forms authenticated' part of your site would be extended to a unique domain name or port.) This would mean they will be prompted to enter their credentials in a form on the page when first connecting.
Read more about authentication on the Authentication Resource Center.
A couple of final points... If you can use SharePoint's default authentication mechanisms rather than writing your own controls, use them as they are well tested and secure. Also, don't be tempted to change SharePoint's IIS settings unless you are certain there is no other way to do what you need. SharePoint regularly updates these itself and may overwrite your changes (or give you grief in other ways).
Related
I want to create a web page, that will serve to authenticate users based on credentials I give them (user1, pswd1 etc).
Only after a user authenticated, he should have access to a few other web sites,
on different folders of the web server, but which have no server side code(otherwise it would be simple.)
The user should be allowed access to the other sites, e.g. based on his IP,
for 24 hours or another period, or while he has the authentication site open on his browser.
The purpose if that the user will not have to enter credentials on each site,
and will enter his credentials only once, or once a day.
Restrictions:
I don't want to modify the target web site javascript code at all, e.g. to query a web service.
The user should be granted access using any browser,
so I assume I cannot use cookies.
If I would develop such a mechanism on Apache,I could, for example, have the authentication site PHP code add a line "Allow from ip" to the htaccess file of each target web folder, whenever a user authenticated successfully.
The issue is that I don't want to develop it as I am sure a solution already exists, and also I need a similar mechanism for both Apache and node.js (although i can live with two different solutions)
What information does the user have to identify themselves? How do you guarantee the user is who they say they are?
The whole point of authentication is to establish the user is who they say they are and that may create a session so that users need not reauthenticate.
If you want the user to authenticate in a single location and then reuse that "session" or set of credentials elsewhere, what you are looking for is single-sign-on / identity federation.
For instance, take airbnb.com. I do not need to authenticate there. All I have to do is authenticate with a third-party e.g. Google or Facebook. As a matter of fact, SO works in the same way.
One of the standards behind this technique is called Open ID Connect. Look into that. If you are willing to dish out money, you can look into commercial solutions e.g. Ping Identity. There is an open source implementation provided by Mitre / the MIT. It's available here.
In fact it occurs to me I can use simple routing.
In the top level folder have php code that does the authentication.
If the user is authenticated, route/redirect to the requested target site,
based on the requested url.
The url should be for example http://mysite/site1, where the authentication code is in the folder mysite, and site1 is not directly accessible.
Perhaps I can use something like php-express to reuse the same php code on node.js.
Google isn't being very friendly in terms of this are so I'll just ask the question here instead...
Just wondering are there any disadvantages or perils that I should be aware should I decide to enable Anonymous access on IIS 6 or 7 for a web app that runs internally? (i.e. never exposed to the Internet)
Thanks.
One disadvantage to anonymous access in an intranet is that it prevents you from having any control over user access for the web app.
For example, by using windows authentication, you can allow authenticated users access to your web app, thereby forcing users to be authenticated inside your domain. This is an extra security measure for intranet, and the usual implementation for an intranet web application in an enterprise environment.
It will be hard to audit access using IIS logs, as it will always be the anonymous identity used. This may impact any enterprise auditing requirements that may be in place. Again using windows authentication can allow all domain users to access the web app, while providing accurate auditing and access log information.
Looking for a pointer in the right direction ...
Is there a mechanism which allows you to configure SharePoint in such a way that:
if a user has been successfully authenticated within a SharePoint site that there is some kind of "authentication token" what can be passed or is available to 3rd party sites
or a way for 3rd party sites to "recognize" that the user is currently authenticated within a sharepoint environment
all 3rd party apps can be modified to accommodate whatever needs to be done
but the constraint is: SharePoint may or may not be a hosted (by a separate service provider) and how the original authentication took place is irrelevant i.e. just need to know they authenticated ok, not how
EDIT
scenario to help clarify:
authenticated SP users require access to a 3rd party service provider for additional content. a "link" on their SP site redirects through to the 3rd party. the 3rd party needs to recognize the referrer (based on a collection of evidence supplied by the request) so that it need not challenge for a secondary authentication process.
one of the 3rd parties is me. the SP instances are many and varied and would be any one of my clients (which i don't offer support to, just provide a content service to).
so the attempt is to solve more of a general "community/ecosystem" problem.
Going on the small amount of information available here.... You are probably going to use Windows Authentication (via Active Directory) or Forms based authentication.
If you are using AD within your organization and the other server you are authenticating to is using the same AD, it's a no brainer. If it's AD based but both servers are using different domains, it's much more complex. One option would be to setup a trusted share between the ADs.
If you are using Forms Based authentication it becomes a bit more of an issue. If both servers are using the same FBA, you could create the authentication cookie in SharePoint and then add the cookie as a header to a Request object and then redirect to the server.
If they are different authentication methods totally, you need to determine if your security requirements will allow users to authenticate via some URL based mechanism (like querystrings) and then develop the logic on your SP box to create the URL to authentication.
Your requirements are a little vuage but this should point you in the right direction.
Plan authentication methods (SharePoint Server 2010)
Specifically Claims based authentication.
I'm guessing that by "3rd party sites" you mean sites that aren't hosted in your domain. If that's the case, then the servers won't be able to use your AD authentication (unless you share them, which probably isn't worth it).
I would suggest modifying the way users are authenticated on the 3rd party servers, as you have control over how you send your users over there. You could easily encrypt their usernames/emails/unique IDs and a timestamp (to make sure they can't bookmark that link) in a query string.
The information is then decrypted on the 3rd party server. Invalid information and they are redirected to your login page. Valid information and the 3rd knows that they were authenticated in your sharepoint app.
Your question is very confusing.
SharePoint may or may not be a hosted
What do you mean by that?
Are you invoking a 3rd party web app from a SharePoint page? You can get the current user using SPWeb.CurrentUser property and make use of it.
Is it possible to access a sharepoint web service without authenication? If you can't do it directley can you think of any ways to get round it such as haveing an open service inbetween that does authenicate for you using a public account.
John,
The security model of the web application through which you're trying to access the web service in question is going to drive whether or not you can access the service anonymously. If you're attempting to access the web service through a web application on which anonymous access is enabled, then you'll be able to hit the web service. Go ahead and try this on an anonymous site (if you have one): http://yoursitehere/_vti_bin/lists.asmx. You'll get the friendly service page back, no auth required.
Here's the catch: once you traverse the web service layer, you've got another layer of security to deal with. SharePoint itself is going to want to check permissions for access via the web services just as it normally would, so unless you are attempting an operation or trying to access data that is allowed for anonymous users, you're going to get blocked.
You have a handful of options:
Simply ensure that everything you're trying to do is permitted anonymously. This may sound easy, but it can actually be pretty difficult for anything but the simplest and straightforward of operations. Most organizations, too, don't care for opening things up to this extent.
If you control the code that's calling the web service, then you have the ability to attach credentials to the web service request. I recommend starting here, as it is going to make things a lot easier than trying to throw everything wide open. Plenty of examples exist on attaching credentials to a web service proxy (e.g., http://msdn.microsoft.com/en-us/security/cc178918.aspx)
Finally, you could write your own web service that wraps the SharePoint web service (or services) of interest. You could permit anonymous access to your web service and then adopt an appropriate security context within your own service to access SharePoint with the required permissions level.
I hope this helps!
Sean
I don't think you can, most actions the webservices perform need an explicit user with the correct permissions set. If both sites are internal, your options might include
Using automatic NTLM authentication, give the complete Authenticated Users group the necessary acecss. Using IE or the proper extensions to FireFox credentials will be automatically passed without user prompting. Your mileage may vary.
Passing the proper credentials to a default user explicitly in the call to the webservice
from that other website.
If you feel creative, here is a blog from Reza Alirezaei where he walks through the steps of mapping the anonymous user onto a specific account. If you manage to give that acount the proper permissions, you are there. Not for the faint of heart, though.
We are having some issues getting SharePoint to work as we want it to.
We have an enterprise MOSS configuration on our domain and have the entry http://intranet pointing to it on port 80.
We also have another site collection and have pointed an internet domain name http:/nww.oursector.nhs.uk at it. We have done this to allow those outside our domain but on the same physical network to view it. Our network admin hasd configured the firewall to redirect any requests to this url to our sharepoint server.
The problem with this is that we have had to turn on anonymous access otherwise SharePoint sees this url as external and blocks authenticated access to the site. This means that all users need to manually sign in to the site, which is making working with SharePoint quite problematic.
Is there a way to configure SharePoint to allow the url http:/nww.oursector.nhs.uk to access the site collection without having anonymous access turned on for the site? I want users to be able to browse to the site and if authenticated then fine, if not then prompt them to login.
Can anyone suggest a way to achieve this?
I would say you need to use SharePoint's alternate access mapping to use the correct authentication type depending on the method users are using to access the website.
Basically i think this would work as follows for your situation:
For internal users, use the default zone, using NTLM with SSO configured.
Thus users should be signed in transparently without requiring to login.
For external users, extend the web application, using the extranet zone, using anonymous access.
This will allow external users, to browse the website without signing on.
See:
http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx