Accessing SharePoint over the Internet


Very soon after you start working with SharePoint, you will find that it contains more and more of your business-critical data. You also become aware of the fact that you need online access to the SharePoint server in order to work with the documents, projects, and everything else stored in the SharePoint database. So you start thinking, "How do I access this information when I am not at the office?" One way is to use the offline functionality of MS Outlook 2007, which allows a user to make a copy for a document library in an Outlook folder, thus making it possible to read and even update documents while offline. Another answer is: You can make your SharePoint information accessible over the Internet, in a secure way, while still getting good performance. You have to plan this carefully and configure SharePoint and the other modules involved, such as the firewall.

Important 

If the SharePoint server is accessible over the Internet, SharePoint 2007 allows even a mobile phone to connect to a SharePoint list using a special view that only shows text.

How You Do It

Because SharePoint is a web application running on top of IIS 6, it is very easy to make SharePoint accessible from outside your organization. You simply open up your firewall so that it allows connections to the SharePoint server from the outside. But this is not a good solution from a security perspective. This leaves your SharePoint server wide open to the world, and there are lots of threats for this server that could destroy it or even the other servers on your network. Another big problem with this simple solution is that your password and user account could be transferred over the Internet unencrypted, depending on what type of authentication method you use. Someone listening in on your communication could learn your password and be able to log on as you!

A better solution is to install a Secure Socket Layer (SSL) certificate on your IIS 6 and demand that every access to the SharePoint server use SSL-encrypted connections. That is, the user must enter the Uniform Resource Locator (URL) address to the SharePoint server starting with https://. The effect of this is that your logon credentials are protected. There is no longer any risk that someone will see your password.

The best solution is to prohibit the external users from accessing the SharePoint server directly from the outside, combined with the SSL-encrypted connection. Instead, your users would access something that looks like the SharePoint server but in reality is a replica. This type of replica is known as an application proxy server. Microsoft has a product for this: the Internet Security and Acceleration Server, also known as the MS ISA server. With this solution, things works like this:

  1. The external user connects to the SharePoint web address over the Internet, using an SSL connection such as https://intranet.filobit.com . This could be the exact same address for users on the inside, except for the https:// part (internally, you would use http:// instead).

  2. The user connection is passing through the firewall but is directed to the MS ISA server instead of the real SharePoint server.

  3. The MS ISA server looks at the requested URL address, checks its rules, and if everything is okay, connects to that URL and retrieves the SharePoint page. This page is then sent back to the user.

  4. The user sees the requested URL and believes he is connected to the real SharePoint server. He clicks a link on that page, and, once again, the MS ISA server gets a request for a new URL, repeating step 3.

The nice thing with this solution is that the user never gets access to anything more than the MS ISA server, which normally is installed on the Demilitarized Zone (DMZ) segment of the network. This segment is where you put all your publicly available servers, such as your public web site. You can use the rules in the MS ISA server to control exactly what the user can see and do. For example, in some organizations, users have different levels of access, depending on where they are situated at the moment. Inside the network, they have full access; on the Internet, they have access to only some part of SharePoint. This is something that only the MS ISA server can help you deploy because SharePoint itself cannot distinguish access to its information in this way. Another bonus effect is that frequently requested web pages are cached on the MS ISA server, meaning that these pages will be displayed more quickly for the users.

Allowing External Partners Access

Now you know the general steps in configuring the SharePoint environment for access over the Internet. But what about partners and other users living outside your organization? If there is a need to give them limited access to your SharePoint server, it can be done! Before you do this, you must understand how SharePoint controls what the user can do with its access control feature.

Every user who wants to access any part of SharePoint must belong to a SharePoint group that defines the exact permission. Some of the default SharePoint groups are these:

  • q Visitor: Allows the user to open and read information, including documents, pictures, and list content. The user will not be able to create, modify, or delete information in SharePoint.

  • q Member: Allows the user to do everything a Visitor can do, plus create, modify, and delete information, including news, documents, contacts, and so on.

  • q Owner: Has full access to the site. Can do everything, including adding and deleting members and changing their access. This group is often referred to as the site administrator group.

Important 

SharePoint groups are not specifically used for intranet scenarios; instead they are used for controlling access to any part of SharePoint, regardless of user access.

First, look at how you can allow access internally. Assume that you have an employee named Anna. She needs access to your intranet, and she will only read information. You add Anna's user account to the SharePoint group Visitors on the intranet portal site. Later, Anna comes back to you and says that she needs both read and write access to a given project site; now you add Anna's user account to the site group Members for this particular project site. Anna now belongs to different SharePoint groups in different parts of the SharePoint environment. Whenever she is accessing SharePoint, it will validate her user account and check what SharePoint group she belongs to.

If you want to allow access to a user outside your organization, it must be possible to authenticate that user. In other words, the external user needs to log on so that SharePoint can see what access he is granted. This will be a problem with external users because they don't have a user account in your network. One simple way to resolve this is to create a local user account for each of these external users. You can assign the user membership in any SharePoint group you like, and you can create rules in the MS ISA server to control exactly what part of SharePoint they can access. The external user must remember to log on with the local account you created. So everyone is happy now, at least for a while.

Problems with This Solution

But this solution is far from perfect. It works, this is true, but what happens if this external person moves to another company? For example, suppose that Michael works for the company ABC. Michael is involved in a project in your organization, Filobit Inc, and needs access to the SharePoint site where all the project information is stored. You create a local user account for Michael, grant him the proper access, and tell him the URL for the project site and that his logon name is Filobit\Michael. He starts working on the project, and everything works as expected. One month later, Michael leaves ABC, and starts working for its competitor, XYZ. You don't have an agreement with XYZ, so its employees are not allowed access to your project site. You need to disable the account Filobit\Michael. But how will you know that Michael has left his old company, ABC? There is no automatic process that will inform you about this. Hopefully, someone at ABC tells you this, or somebody in the project team gets this information and tells you. Clearly, this situation will be very hard to handle if you have 10 or more external partners. But at the moment, this is how things work.

Important 

A new feature in SharePoint 2007 called Forms Based Authentication allows you to create a logon page for external users and store those external accounts in an SQL Server database, instead of the Active Directory. This feature is beyond the scope of this book, since it requires both programming skills and good understanding of SQL Server; for more information see http://blogs.msdn.com/sharepoint/archive/2006/08/16/configuring-multiple-authentication-providers-for-sharepoint-2007.aspx.

ADFS

However, there is some light at the end of the tunnel. Starting with Release 2 of Windows 2003 Server, Microsoft released a feature called Active Directory Federation Service (ADFS). The objective of ADFS is to resolve precisely this type situation (that is, letting two completely separate organizations share access to web applications like SharePoint without the need to create local accounts for the remote organization). The idea is rather simple and easy to understand, but the technique beneath is advanced and worth its own book.

The basic idea of ADFS is to make it possible for an organization to use its own user accounts to get access on a remote web application. For example, assume that you have two companies, A and B. User Bob works for B, and he needs access to a SharePoint site in A. Bob talks to the administrator for the site in A, which then grants the B\Bob account access to the requested site.

The magic in this scenario is managed by adding extra servers to your Active Directory domain, one in each organization. The primary ADFS server is referred to as the federation server and hosts the federation service component. Its primary task is to route incoming requests from the Internet to the web site a user is trying to access. It is also responsible for creating a security token that will be passed on to the web application. The process that validates the external user is the ADFS Web Agent, which runs on the web server (in this case, the SharePoint server).

Most organizations do not want their federation server exposed to the Internet. You can protect it by installing an optional federation proxy server. This proxy relays federation requests from the outside world to your internal federation server, meaning that your federation server is no longer exposed directly to the outside world.

Important 

ADFS is based on the standard Security Assertion Markup Language (SAML), which means that that the external company need not be running MS Windows.

MS Groove

With SharePoint 2007 there is a new type of solution for this situation. Using MS Groove, a project's members are able to share and collaborate on SharePoint lists and libraries, regardless of the project members' organizational membership. It is a very attractive solution for teams and groups of up to 15 members, and Groove will automatically synchronize any updates of these lists and libraries between all members as soon as they get connected to the Internet. The current version of MS Groove has its own user database, so there is no requirement that all members have user accounts in the same Windows domain.

One thing to remember with Groove is that it is an independent application that may be used as a standalone product or synchronized with SharePoint content. It is not a special application made for SharePoint as of today, although this will probably change in the future. In a way, Groove and SharePoint are both offering a shared workplace for teams, although the strength of Groove is its great replication engine that works independently of the users' organizational membership, while SharePoint's strength is all the functionality mentioned earlier in this chapter, including integration with all MS Office products.

Important 

For more information about MS G¡roove look at http://www.microsoft.com/office/groove.



Beginning SharePoint 2007 Administration. Windows SharePoint Services 3 and Microsoft Office SharePoint Server 2007
Software Testing Fundamentals: Methods and Metrics
ISBN: 047143020X
EAN: 2147483647
Year: 2004
Pages: 119

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net