Claims-Based Identity Model

.NET Framework 4.5

10 out of 11 rated this helpful - Rate this topic

---

When you build claims-aware applications, the user identity is represented in your application as a set of claims. One claim could be the user’s name, another might be an e-mail address. The idea is that an external identity system is configured to give your application everything it needs to know about the user with each request she makes, along with cryptographic assurance that the identity data you receive comes from a trusted source.
Under this model, single sign-on is much easier to achieve, and your application is no longer responsible for the following:

• Authenticating users.
  
• Storing user accounts and passwords.
  
• Calling to enterprise directories to look up user identity details.
  
• Integrating with identity systems from other platforms or companies.
  

Under this model, your application makes identity-related decisions based on claims supplied by the system that authenticated your user. This could be anything from simple application personalization with the user’s first name, to authorizing the user to access higher valued features and resources in your application.
This topic provides the following information:

• Introduction to Claims-Based Identity
  
• Basic Scenario for a Claims-Based Identity Model
  

Introduction to Claims-Based Identity

---

The following terminology and concepts can help you understand this new architecture for identity.

Identity

---

For the purposes of describing the programming model in Windows Identity Foundation (WIF), we will use the term “identity” to represent a set of attributes that describe a user or some other entity in a system that you want to secure.

Claim

---

Think of a claim as a piece of identity information such as name, e-mail address, age, membership in the Sales role. The more claims your application receives, the more you’ll know about your user. You may be wondering why these are called “claims,” rather than “attributes,” as is commonly used in describing enterprise directories. The reason has to do with the delivery method. In this model, your application doesn’t look up user attributes in a directory. Instead, the user delivers claims to your application, and your application examines them. Each claim is made by an issuer, and you trust the claim only as much as you trust the issuer. For example, you trust a claim made by your company’s domain controller more than you trust a claim made by the user herself. WIF represents claims with a Claim type, which has an Issuer property that allows you to find out who issued the claim.

Security Token

---

The user delivers a set of claims to your application along with a request. In a Web service, these claims are carried in the security header of the SOAP envelope. In a browser-based Web application, the claims arrive through an HTTP POST from the user’s browser, and may later be cached in a cookie if a session is desired. Regardless of how these claims arrive, they must be serialized, which is where security tokens come in. A security token is a serialized set of claims that is digitally signed by the issuing authority. The signature is important: it gives you assurance that the user didn’t just make up a bunch of claims and send them to you. In low security situations where cryptography isn’t necessary or desired, you can use unsigned tokens, but that scenario is not described in this topic.
One of the core features in WIF is the ability to create and read security tokens. WIF and the .NET Framework handle all of the cryptographic work, and present your application with a set of claims that you can read.

Issuing Authority

---

There are lots of different types of issuing authorities, from domain controllers that issue Kerberos tickets, to certification authorities that issue X.509 certificates, but the specific type of authority discussed in this topic issues security tokens that contain claims. This issuing authority is a Web application or Web service that knows how to issue security tokens. It must have enough knowledge to be able to issue the proper claims given the target relying party and the user making the request, and might be responsible for interacting with user stores to look up claims and authenticate the users themselves.
Whatever issuing authority you choose, it plays a central role in your identity solution. When you factor authentication out of your application by relying on claims, you’re passing responsibility to that authority and asking it to authenticate users on your behalf.

Security Token Service (STS)

---

A security token service (STS) is the service component that builds, signs, and issues security tokens according to the WS-Trust and WS-Federation protocols. There’s a lot of work that goes into implementing these protocols, but WIF does all of this work for you, making it feasible for someone who isn’t an expert in the protocols to get an STS up and running with very little effort. You can use a pre-built STS such as Active Directory® Federation Services (AD FS) 2.0, a cloud STS such as a Windows Azure Access Control Service (ACS), or, if you want to issue custom tokens or provide custom authentication or authorization, you can build your own custom STS using WIF. WIF makes it easy to build your own STS.

Relying Party Application

---

When you build an application that relies on claims, you are building a relying party (RP) application. Synonyms for an RP include “claims-aware application” and “claims-based application”. Web applications and Web services can both be RPs. A RP application consumes the tokens issued by a STS and extracts the claims from tokens to use them for identity related tasks. WIF offers functionalities to help you build RP applications.

Standards

---

In order to make all of this interoperable, several WS-* standards are used in the previous scenario. Policy is retrieved using WS-MetadataExchange, and the policy itself is structured according to the WS-Policy specification. The STS exposes endpoints that implement the WS-Trust specification, which describes how to request and receive security tokens. Most STSs today issue tokens formatted with Security Assertion Markup Langauge (SAML). SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way. Or, in a multi-platform situation, this allows you to communicate with an STS on an entirely different platform and achieve single sign-on across all of your applications, regardless of platform.

Browser-Based Applications

---

Smart clients aren’t the only ones who can use the claims-based identity model. Browser-based applications (also referred to as passive clients) can use it as well. The following scenario describes how this works.
First, the user points a browser at a claims-aware Web application (the relying party application). The Web application redirects the browser to the STS so the user can be authenticated. The STS is hosted in a simple web application that reads the incoming request, authenticates the user using standard HTTP mechanisms, and then creates a SAML token and replies with a piece of JavaScript code that causes the browser to initiate an HTTP POST that sends the SAML token back to the RP. The body of this POST contains the claims that the RP requested. At this point, it is common for the RP to package the claims into a cookie so that the user doesn’t have to be redirected for each request.

Basic Scenario for a Claims-Based Identity Model

---

The following is an example of a claims-based system.

This diagram shows a Web site (the relying party application, RP) that has been configured to use WIF for authentication and a client, a web browser, that wants to use that site.

1. When an unauthenticated user requests a page their browser is redirected to the identity provider (IP) pages.
   
2. The IP requires the user to present their credentials, e.g. username/password, Kerberos, etc.
   
3. The IP issues a token back to that is returned to the browser.
   
4. The browser is now redirected back to the originally requested page where WIF determines if the token satisfies the requirements to access the page. If so a cookie is issued to establish a session so the authentication only needs to occur once, and control is passed to the application.
   

deploy a master page

http://www.sharepointchick.com/archive/2010/03/26/deploying-a-custom-master-page-in-sharepoint-2010.aspx

wcf in sharepoint

1) No multi-header set in IIS of a site. Set environment compatibility "Allowed" in IService.

Hosting WCF in SharePoint 2010

Original Article is located -

http://www.c-sharpcorner.com/uploadfile/gaikwaduc/hosting-wcf-in-sharepoint-2010/

Introduction

SharePoint 2007 provided the capability to add custom ASMX web services. Web Services could be deployed to the LAYOUTS folder, or could be deployed to the ISAPI folder and supported accessing site settings and list data under the SharePoint user context. Since SharePoint 2007 was built on the ASP.NET 2.0 model, it did not natively support web service enhancements that were introduced with Windows Communication Foundation (WCF) in .NET Framework 3.0 and 3.5 or the additional WCF-based service frameworks like ADO.NET Data Services (now WCF Data Services).

For those familiar with writing custom ASMX services for 2007, there were some pitfalls. Since SharePoint requires dynamic service endpoints (the ability to call the web service using any site-relative virtual path under the /_vti_bin/ folder), you had to hand-tool your WSDL files to dynamic service locations. This had to be done every time your changed your web-service signature. Not terribly complicated, but certainly tedious.

The good news is that SharePoint 2010 is based upon ASP.NET 3.5 and now supports WCF custom services including SOAP, REST, and WCF Data Services. The even better news is that is makes it easy to deploy custom WCF services with dynamic endpoints by supporting a number of custom Service Host Factory implementations that can auto-generate. This means it is not necessary to modify the SharePoint web.config to deploy your service endpoint configurations.

In this article, I will walkthrough and highlight the important aspects of the SharePoint 2010 support for custom WCF services.

Steps for Implementation of WCF in SharePoint 2010

Step 1: Create Empty SharePoint project.

Run Visual Studio 2010 as an administrator.

Create New Empty SharePoint project.

Visual Studio 2010 now includes templates for developing just about every type of SharePoint customization including Web Parts, List Handlers, custom Site Definitions, List Templates, etc. It does not include a template for a SharePoint Web Service, so we will want to start with the Empty SharePoint Project template. The will automatically create a project that includes references to the core Microsoft.SharePoint assembly, and includes special capabilities for defining Features, and automatically packaging and deploying your solution as a WSP.

Select Deploy as a farm solution and click on finish

Step 2: Mapping of ISAPI folder and Creating Structure of services

Map the ISAP folder into the project as shown below.

Step 3: Adding references

To support a custom WCF we need to perform a few additional steps:

• Add a reference to the Microsoft.SharePoint.Client.ServerRuntime assembly. This assembly contains the Service Host Factory classes, as well as some attributes we need later on.
• Add a SharePoint Mapped Folder to the ISAPI folder, and create an empty text file with the .SVC extension. Note that it is always a good practice to create a sub-folder when deploying your custom code to the SharePoint file system. It helps keep you custom code separate from the original installed files.

Step 4: Adding ".svc" and "Web.config" file

Select  text file template and add Sample.svc  file into the directory structure of ISAPI

Similarly select the text file template and add Web.config file into the directory structure.

Step 5: Adding Service contracts

The next step is to add the WCF service contract and implementation. For my sample, I have written a very simple service that returns the Url of the current SharePoint context. This is a good way to verify that the service endpoints generated for us by SharePoint are dynamic.

The important thing to note here are the attributes required on the implementation class. These attributes allow SharePoint to automatically support metadata exchange endpoints, and is the secret sauce that allows us to develop custom WCF services without having to deploy endpoint configuration to the SharePoint web.config.

using System;

using System.ServiceModel;

using System.ServiceModel.Activation;

using Microsoft.SharePoint;

using System.Collections;

using Microsoft.SharePoint.Client.Services;

using System.Runtime.Serialization;

namespace WCFSharePoint

{

          //add service contract here

          //add class implementation here

          //add datacontract here

}

[ServiceContract]

    public interface ISampleService

    {

        [OperationContract]

        System.Collections.Generic.List<MyCityClass>GetCityList();

    }

[ServiceContract]

    public interface ISampleService

    {

        [OperationContract]

        System.Collections.Generic.List<MyCityClass>GetCityList();

    }

[BasicHttpBindingServiceMetadataExchangeEndpointAttribute]

    [AspNetCompatibilityRequirementsAttribute(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]

    public class SampleService : ISampleService

    {

        SPWeb oWeb;

        SPList oList;

        public System.Collections.Generic.List<MyCityClass> GetCityList()

        {

            try

            {

                System.Collections.Generic.List<MyCityClass>retList = new System.Collections.Generic.List<MyCityClass>();

                SPSecurity.RunWithElevatedPrivileges(delegate()

                {

                    using (SPSite oSite = new SPSite("http://ocs-wks-106:5000/sites/HealthInsight"))

                    {

                        using (SPWeb oWeb = oSite.OpenWeb())

                        {

                            oList = oWeb.Lists["CityList"];

                            SPListItemCollection collListItems = oList.Items;

                            foreach (SPListItem oListItem in collListItems)

                            {

                                if (oListItem["CityName"] != null && oListItem["ID"] != null)

                                {

                                    MyCityClass tempClass = new MyCityClass();

                                    tempClass.ID = Convert.ToInt32(oListItem["ID"]);

                                    tempClass.CityName = Convert.ToString(oListItem["CityName"]);

                                    retList.Add(tempClass);

                                }

                            }

                        }

                    }

                });

                return retList;

            }

            catch (Exception ex)

            {

                throw new Exception(ex.Message);

            }

        }

    }

Step 6: Configure service host definition.

IIS-hosted WCF services are registered using a special content file (.svc files) that contain a processing instruction that allows the WCF infrastructure to activate the service to respond to incoming messages. The primary attribute in the ServiceHost processing instruction is the Service attribute that defines the type name and assembly or code-behind reference for the service.

The Microsoft.SharePoint.Client.ServerRuntime supports a number of service host factory classes depending on whether you are implementing SOAP, REST or WCF Data Services:

• SOAP = MultipleBaseAddressBasicHttpBindingServiceHostFactory
• REST = MultipleBaseAddressWebServiceHostFactory
• Data Service = MultipleBaseAddressDataServiceHostFactory

SharePoint custom WCF services need to utilize one of these factories to dynamically generate the service endpoint during execution. In my sample, below I have selected the service factory for a SOAP web service.

The important element of defining your service host is to include the Factory attribute and select the appropriate service host factory class for your implementation.

<%@ ServiceHost Debug="true" Language="C#" CodeBehind="MyContractClass.cs"

Service="WCFSharePoint.SampleService,WCFSharePoint,Version=1.0.0.0,Culture=neutral,PublicKeyToken=6c66e01558558943"%>

To get all above attributes use SN.EXE utitlity.

Version, PublicKeyToken, and Assembly type name

Step 7: Updating web.config file

<?xml version="1.0"?>

<configuration>

  <system.serviceModel>

    <services>

      <service behaviorConfiguration="WCFSharePoint.CustomServiceBehaviour"

        name="WCFSharePoint.SampleService">

        <endpoint address=""

                  binding="basicHttpBinding"

                  contract="WCFSharePoint.ISampleService" >

          <identity>

            <dns value="localhost" />

          </identity>

        </endpoint>

        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

        <host>

          <baseAddresses>

            <add baseAddress="http://ocs-wks-106:5000/sites/HealthInsight"></add>

          </baseAddresses>

        </host>

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior name="WCFSharePoint.CustomServiceBehaviour">

          <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->

          <serviceMetadata httpGetEnabled="true"/>

          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid

disclosing exception information -->

          <serviceDebug includeExceptionDetailInFaults="false"/>

        </behavior>

      </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

</configuration>

Step 8: Checking anonymous authentication to the SharePoint site

Step 9: Adding ClientAccessPolicy.xml and crossdomain.xml

Step 10: Build, Deploy, and Test Your Service

One of the benefits of the new SharePoint 2010 templates in Visual Studio 2010 is that they now support automatically packaging and deploying your solution as a WSP.

When you are ready to test your custom service, right-click on the project node, then select Deploy from the menu. Your assembly will be automatically deployed to the GAC, and your .SVC file will be deployed to the SharePoint ISAPI folder. When it comes time to deploy to production, you can just pass your WSP file to your SharePoint Administrator and he can easily add your solution to the SharePoint farm.

One of the easiest ways to quickly test if your service is working is to access the service from a browser and verify that it is correctly generating the WSDL for our service (if you are deploying a SOAP service).

Open your browser and browse to:

http://yoursite/_vti_bin/<service>.svc

You need to be sure to include the /MEX at the end since the service being deployed is using a Metadata Exchange Endpoint.

References

http://answers.oreilly.com/topic/1404-how-to-customize-wcf-services-in-sharepoint-2010/

http://mstecharchitect.blogspot.com/2010/03/hosting-wcf-service-inside-sharepoint.html

wcf in sharepoint

1) no multi-header set in IIS of a site. Set environment compatibility "Allowed" in IService.

inforpath workflow

1) You need to create a customized workflow and publish it in order to attach the workflow to the infopath.

Infopath data connection

1) Click data->data connection.

publish web browser enabled infopath

1) from infopath 2010, choose publis -> sharepoint server

 

2)  Click SharePoint Server button, enter the sharepoint site collection which contains Infopath Forms Services. (http://comspolydvs30.com.wa.lcl:5188)

3) check "Enable this form to be filled out by using a brower" and select "Administrator...".

 4) publish the template to a local folder.

 5) click Next until publish.

6) Go to CA->General Application Settings->InfoPath Forms Services->Manage form templates

7) Upload template

8) Activate the template to a particular site collection. 

9) Create a new document in Library of a site. Go to "Library" to click "Library Settings". Click "Advanced settings" and click Yes for "Allow management of content types.

10)  Add from existing site content types to that new document. Select sharepoint2 template to the type.

11) Add infopath form webpart. Select List or Library.

12) If you want to add a new infopath document in the document library, go to the document, click "Document" in the ribbon. Select the infopath template to create and save a new doc.