SharePoint 2010 Service Application Design Best Practices

Through SharePoint 2010, there is an improvement of the services infrastructure that was previously introduced in an earlier version. This infrastructure also hosts services for the SharePoint Foundation 2010. The configuration of services offered is very flexible. This allows the individual services to be configured independent of each other. It also makes it possible for 3rd party companies to be able to add services to that platform. The configuration of services aren’t exclusive to SharePoint Server. The services aren’t restricted to Shared Services Providers.

When service applications are deployed from a farm there are a couple of different methods that can be used.
They include the use of Windows PowerShell, adding services one at a time through the Manage Service Applications page, and choosing services for running the SharePoint Products Configuration Wizard.

The infrastructure of the services has been updated so that there is more control over the types of services that have been deployed. There is also control over the types of service applications that have been shared. Only the service applications that are necessary for a farm can be deployed. The various web applications can be configured so that they only use certain service applications. This is better than them using all of the various services that have been deployed. Service applications can be shared across various web applications that are within the same farm. All of the service applications that are included in a default group will remain unless you change them. There are settings for service applications that can be created. You can add or remove service applications in that default group any time you want to.

The creation of web applications allow you to select the default group you want or to create one that is customized. If you want to customize your service applications you can do by selecting those that you want to be part of the web application. When custom groups are created in Central Administration, they can’t be used for all of your web applications. When you select custom to create a web application you will limit them to only that specific web application you happen to be using. Each of the service applications has a single Internet Information Services website. This is the default setting and you won’t be able to change it. However, you do have the option of customizing how it is configured for various application groups.

There are several characteristics of a farm that you need to be familiar with. Web applications will connect to the default group or a custom group of service applications. All of the service applications will be found within the same Internet Information Services website. Service applications are in a group as defaults or customized. However, not all of the service applications have to be placed into one of those groups. They can be used by a single web application if you wish.

It is possible for service applications to be deployed to different applications pools. This results in process isolation occurring. If you want to optimize how your farm performs then it is recommended that you deploy service applications to only one application pool. In order for that isolation to occur with a service application, you need to create a new application for the pool service application.

While creating a service application there is a connection for the service application that is being created at the same time. There is a connection that is a virtual entity for connecting to web applications. With Windows PowerShell these connections are known as proxies. A proxy will be at the end of the type description for a connection which is through the Manage Service Application in Central Administration. Some of these connections may include settings that you can modify. This includes the Managed Metadata service application, Term Store Administrators, and Default Language.

When you directly manage service applications in Central Administration you can manage and monitor them from a remote location. They can also be managed and scripted through Windows PowerShell. There are some service applications that are shared among many farms. Others though can only be shared in a singular fashion with a given farm server.

Computing intense service applications that operate within a central farm. This is done to minimize the overhead costs relating to administration. This is also to help keep everything operating efficiently, even as the requirements of the farm grow. If you use service applications to support sharing across farms, they should be controlled by a central farm. Then they can be consumed from that core location. For each of the web applications that will be configured, use service applications from different farms.

Share

SharePoint Claims Based Authentication Architectures Explained Part 7 Transforming Identity In SharePoint

The role of the issuer involves taking the incoming identity and making it into a secure token that can be used for a given application. The token is very similar to a boarding pass it has pertinent information about the identity of the user. The only information that is on it is what the application needs. This is why such boarding passes often have a role that can be used immediately. This is faster that relying on Windows groups.

The issuer is often thought of as an identity transformer. It is able to convert the incoming identity into something that is readable to the application. There are users that can have one sign on credential that allows them to access all of the different application they may need. This is because there is an issuer in the realm with the trust to authenticate all of them.

There is a local issuer that offers claims to applications in their own realm as well as to those that are in others and need access to multiple applications. It allows them to use their local applications and those that are remote all with just that one credential being in place rather than needing one for each of them.

The Active Directory Federation Services (ADFS) relies on a rules engine that will support the claims transformation. They have a set of rule in place that say when a claim of X type is make with X as the value then issue this type of claim. For example you may have an application called Managers that allows special access to certain features. This claim will take that user to a Mangers group in the realm. That is where they will always be sent.

A partner group may have a group called Supervisors that needs to gain access to that Mangers area in the application. Through the transformation process both the Supervisors and the Mangers can access it as long as the issuer has trust for this to be acceptable. This is all possible due to the way in which the rules are written in the ADFS. The issuer has to be designed to support these types of transformations because the terminology used in each company can be very different.

Hopefully you now see what is possible with the concept of cross realm federation. Here are the steps involved with a browser based application:

  • A user in a remote realm clicks a link that will take them to your application
  • That user is redirected to your local issuer
  • The issuer redirects the users browser to the issuer that is in their realm.
  • The local issuer authenticates a token, sending the user’s browser back to your issuer with the token
  • Your issuer will validate the token, transform the claims, and then issue a token for your application to be used
  • Your issuer sends the user’s browser back to the application with a token that has the claims your application needs on it

In step three you may be wondering how the issuer knows that the user is from a remote realm. Why doesn’t it think that she is a local user and thus attempt to authenticate her directly first? Of course by doing so the user wouldn’t get in and they will be upset about it. Also, how does the issuer know that the user is from one particular realm versus another?

You will have more than one partner and so all of them will be differentiated out there. The home realm discovery is where the issuer has to determine if the user is from the local realm or one of the partners. If that user is local then they can be authenticated directly. If they are remote then the issuer has to be able to find out what the URL is to redirect her to so that they can be authenticated by the home realm issuer.

There are a couple of different ways in which this situation can be handled. The first one is for the user to help in some way. When the browser of the user is redirected to the ADFS, it will stop the protocol and display a web page to the user. Here they will be asked what company they are employed by. The credentials in place are only good for one company per user so they can’t give you false information here and continue to with any hopes of gaining access.

Once the user clicks the link for the company they are with, the protocol will continue the process. The issuer will know what to do from there. You can also set it up so that the user is only asked which company they work for one time. After that there can be a cookie in the browser that will always display that information without it being asked for in the future.

There is another way to handle this and it involves adding some type of hint to the query string in the link that the user clicks on in the first step. This query string is called whr with the hr being representative of home realm. It is a good idea for the IT department to ensure all of the links to remote applications include this information. That way the application is more user friendly. At the same time it will protect the privacy of the company as it doesn’t require revealing who all of the partners happen to be.

The issuer is going to find this hint and then map to the right URL for the home realm of the user. This means they won’t need to ask the user who their issuer is because the application is going to use the information it has available. A cookie will be in place to make sure users don’t have to take time to answer such questions.

The best way to get the users help for web applications is through the use of a web page. They are going to be interactive and the browser will conveniently be able to display a home realm discovery page when necessary. You may be wondering how to take care of this when it comes to web services and even your rich clients? Information cards can be a very useful tool for such circumstances.

Share

SharePoint Claims Based Authentication Architectures Explained Part 2 Claims Architecture Priming

You can use one of many different types of approaches in order to create a claims based application. Both Web applications and SOAP Web Services can accomplish the same thing but they take different approaches for making it happen. Yet the overall structure that is there is the same as it’s the overall goal. The purpose is to create claims that can communicate with each other and that are secure.

We are going to take a close look at how you can evaluate the different types of architecture that can be used. Taking variables into consideration including different perspectives, the experience of the user, opportunities for optimizing, the performance of the different applications, and even how the claims get passed from the application to the issuer all need to be closely looked at. Only then will you see the entire picture of what is offered. I will also give you some advice about how to create your claims and how to know your users.

The overall purpose of the different architectures is to allow for either an active for passive type of federation to be implemented. With an active federation you will have the WS-Trust and WS-Federation Active Requestor Profile in place. They help to describe the way in which the communication between the clients and the services go about requesting a token from the issuer. It also covers how that token is sent for authorization.

With passive federation, the WS-Federation Passive Requestor Profile describes the same type of communication flow between the web application and the browser. In order for tokens to be requested and authorized the web browser has to redirect those requests.

Share