Monday, 1 October 2012

Windows Identity Foundation(WIF)

Introduction

First of all, I'll say Windows Identity Foundation is a Microsoft way to leverage the Claim based Authentication. Let's see the definition from MSDN.
Windows Identity Foundation enables .NET developers to externalize identity logic from their application, improving developer productivity, enhancing application security, and enabling interoperability. Enjoy greater productivity, applying the same tools and programming model to build on-premises software as well as cloud services. Create more secure applications by reducing custom implementations and using a single simplified identity model based on claims. Enjoy greater flexibility in application deployment through interoperability based on industry standard protocols, allowing applications and identity infrastructure services to communicate via claims.
So we can say, Windows Identity foundation provides a set of classes which facilitates in implementing Claim based authentication.

Prerequisites

To use WIF, you need Windows 2003 server+ or Windows 7/8/Vista.
  • WIF for Win server 2003 - download it from here
  • WIF for Win 7+ - download it from here
  • WIF SDK - download it from here
WIF SDK provides some Visual Studio templates that help in developing Claim aware applications. These templates are:
  • ASP.NET Security Token Service Web Site
  • Claims-aware ASP.NET Web Site
  • Claims-aware WCF Service
  • WCF Security Token Service
The above templates are available in New Website under File Menu.

Let's Discuss an Example

So today, we will create an ASP.NET application (Relying Party Application-RP). And also, we'll create a custom Identity provider and we'll use this identity provider for authentication of the user.
Following are the main steps we need to perform:
  • Create a Custom Identity Provider
  • Create an ASP.NET application
  • Create a trust between Identity provider and ASP.NET application
So let's first create an Identity Provider.

Creating a Custom Identity Provider

So here, I will create a step by step process to create a Custom Identity Provider.
Open Visual Studio-> Create new website -> select ASP.NET Security Token Service Web Site (I have selected the location HTTP to host it at IIS directly.)
Create STS
Now your sample Identity provider is created. It provides the basic infrastructure for you. It includes one login page that actually authenticates the user and here forms authentication is used.

Create an ASP.NET application

I have created an ASP.NET application as below:
Creating ASP.NET website
Now as this already created an inbuilt authentication module. You can remove it all because we'll not be using this. Or you can create an empty ASP.NET solution and some page as per your requirement. I have removed the account folder for the demo.
Create a trust between Identity provider and ASP.NET application(RP)
This can be done using FedUtil provided by WIF SDK. Also from UI, we can add an STS reference in the ASP.NET website and make a trust relationship between Identity Provider and Relying Party. Look the following steps to add the reference.
  • Add an STS Reference to ASP.NET website.
Add STS reference
  • This is the first screen of FedUtil which displays the URI and location of ASP.NET website(RP):

  • If you have not hosted your ASP.NET website(RP) on SSL, it will show the following Warning. At Production, all the communication between Identity Provider and ASP.NET website(RP) should happen over SSL only. Here for demo purposes, I didn't use SSL. I clicked on Yes.
fedutil1.png
  • In this screen, it asks to select the STS (Security Token Service). And has three options. As we have created the STS, we need to select the option "Use an existing STS".

To build the trust relationship, we need to provide the federation metadata provided Identity Provider.
  • Now we need to browse the FederationMetada XML file of the STS that we created.
fedutil3.png
FederationMetadata file resides in a special folder hierarchy “FederationMetadata/2007-06? under the STSWebsite physical folder.
  • And Select the FederationMetdata. And Click next.

  • Again as my STS is not hosted at SSL, it is showing the below warning message. I just clicked Yes.

  • Here it asks if one wants to encrypt the token. It should be encrypted on production. Here I have selected the option "No Encryption" for the demo.

  • Now it shows all the claims passed by STS to RP. We can pass more claims from STS to RP as per our requirement. All the Claims is shown here while adding the STS reference.By default, there are only two roles provided by STS (Name & Role).
fedutil7.png
  • This is the Summary screen, shows the details about STS and RP. One needs to review and click finish.

Note: Here there is an option to update the federation metadata on a routine basis. One needs to know if the STS is getting changes, say Token or Claims, etc. RP would only come to know about when federationmetadata will be updated, else say if someone removed a Claim and metadata is not updated, it will allow to get the that Claim but actually at runtime you would not get that claim which will not be a good condition. One should always have the metadata in updated form.
After clicking Finish. A folder FederationMetadata is added to ASP.NET website (Relying Party -RP) as below:

Let's run the application.
Now if you run the application, it will throw an exception as “Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.”
This is an issue with it and I have made a small post on it. You can get it resolved easily. Please check this [^] .
Now after changes, it will run smoothly and it will take you to the login page that is provided by STS. This is the default login page provided STS, here you don't need to write password, just put some name and click on login as below:
STS Login
It will redirect to another page to STS which will actually initiate the process to create the token and claims. Then after creating, it will be transferred to your website as authenticated user.
Now our application is running. As here in STS, we have a sample login page the uses Forms authentication and by default authenticates every user. Here we can put our code, whether we want to authenticate the user using windows authentication/Form authentication and use database all we can and also we can get some data of the user from any store say DB here and that we can send using in Claims as per our requirement.
So now here I’ll show how to pass some more information to the user in Claims. So one can get additional claims here. When you create an STS, there are four files get added in App_Code folder. One file named CustomSecurityTokenService.cs. In this file, there is a method GetOutputClaimsIdentity that actually creates the claims. We need to add the claims here (I have added few):

/// <summary>
/// This method returns the claims to be issued in the token.
/// </summary>
/// <param name="principal">The caller's principal.
/// <param name="request">The incoming RST, can be used to obtain additional information.
/// <param name="scope">The scope information corresponding to this request.
/// <exception cref="ArgumentNullException">If 'principal' parameter is null.</exception>
/// <returns>The outgoing claimsIdentity to be included in the issued token.</returns>
protected override IClaimsIdentity GetOutputClaimsIdentity
    ( IClaimsPrincipal principal, RequestSecurityToken request, Scope scope )
{
    if ( null == principal )
    {
        throw new ArgumentNullException( "principal" );
    }
    IClaimsIdentity claimsIdentity = (IClaimsIdentity)principal.Identities[0];

    ClaimsIdentity outputIdentity = new ClaimsIdentity();
    // Issue custom claims.
    // Update the application's configuration file too to reflect new claims requirement.

    outputIdentity.Claims.Add( new Claim
    ( System.IdentityModel.Claims.ClaimTypes.Name, principal.Identity.Name ) );

    outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "Manager"));
    //I added these custom claims
    outputIdentity.Claims.Add(new Claim(ClaimTypes.Email, "
brij@gmail.com"));
    outputIdentity.Claims.Add(new Claim(ClaimTypes.Gender, "Male"));

    return outputIdentity;
}
 
I have added two claims (Email, Gender) as above. These claims will be available at ASP.NET website (Relying Party).
The same Identity provider can be used in multiple applications.
I hope the above sample will help a lot. In my new post of this series, I will discuss another technique to implement use Claim based Authentication which is widely used called Identity Federation.

Claim Based Authentication and WIF

Introduction

There is a lot of buzz about Claim based Authentication. In this article, we'll understand what is Claim based Authentication, what are the benefits and a lot more. This is my first article in this series. In subsequent posts, we will see the implementation and more scenarios.
Let's first understand what the need is for Claim based authentication?

Problems with Current Authentication

We make several user accounts at several portals/websites. Everytime we need to access the corresponding website, we need to remember the username and password and if somehow we forget the password, then we need to remember some specific details like security question, etc. to get the access of the account again. And every time we might not remember all these details. Also, it is never advisable to write your user credentials physically.
One more problem, most of the applications use some authentication mechanism, mainly Classic UserName and Password. As most of the developers are not really security experts; they leave loopholes during development which are easy to break. So it is a major security risk.
Most of the developers have some or the other day worked on the SingleSignOn feature. It's not always been a simple task. It leads to a lot of challenges and many issues after the application is deployed on UAT/Production.
As a user, we create new user credentials (username and password) to many applications on the internet like Facebook, Yahoo, Gmail, etc. and some in-house sites like some college portal, etc. or some enterprise application. So to create new credentials every time and to remember all these credentials and see that all are secure enough is very tedious. If there is any errors, you might lose some credentials and could end up in a big loss.

Solution

Imagine the situation where you just need to have one user credential, i.e., username and password and that is enough to access all your portals/websites. This will be an ideal situation. Might be it could not take place completely, but we are somehow moving in this direction.
But how can this take place?
Actually, nowadays, when we create an application which has an authentication page, we need to understand how it works. Actually when user logs in, an Identity is assigned to that session and that Identity is maintained throughout the session until the user logs out or it expires. So let’s view the current scenario.
Application using Authentication
This means that every application which has some authentication mechanism first authenticates the user and gives an Identity and then the user gets the rights to access the application. So somehow if we can externalize the authentication part from the application, then this will be very helpful and the same authentication application is used by several applications. I explain it pictorially.
Externalize the Authentication
So the basic idea is, if there are some applications that do the authentication and provide the Identity (called Identity Provider), and applications rely on this identity, like in our daily life:
daily Life scenario
The above picture is self-explanatory.

Claim Based Authentication

The same mechanism is also followed in Claim based Authentication. There are some authentication/identity providers which are used by various applications whenever a user tries to access some application. The application checks whether the user is authenticated or not, if not, it forwards the user to the Identity provider which actually authenticates the user, gives a token to the user and forwards the user to the application. The application verifies the token and the user is allowed to access the application.
But this is not so easy in a web scenario. There are few challenges - Who are the Identity Providers? - What is the data needed for the relying party, i.e., what data can be transferred from Identity provider and in which form - if there are multiple Identity providers. How does the application trust them?
Actually there are a couple of Identity providers nowadays like Google, Facebook, WindowsLive Id and many more. And even we can develop our own Identity provider for on premise applications. This can be used on Cloud as well.
Now if I am making an application and my application uses some Identity provider to authenticate a user, then the application must understand the token of that Identity provider and also there must be trust relation between the application and Identity providers, so that the application can rely on the token sent by that Identity provider.

Basics of Claim based Authentication

Now let us discuss what are the basic things involved in it. These are mainly Identity, Tokens, Claims, Identity Provider or Security Token Service, RP (Relying Party), etc. To move ahead, we need to understand all of these. Let's discuss them one by one.

What is an Identity

You can say Identity is a group of information that can uniquely identify anything. Most of the other things also have identity like your own PC, Vehicle, etc. But here, we are talking about person. So in this digital era, we can say a digital identity is a group of information to identify a person.

Token and Claims

When this digital identify is passed over wire, it is passed as a stream of bytes and that is known as token. Token contains some set of information about the user in the Claim format. A token can contain multiple claims and every claim contains some specific information. The token is digitally signed so that it can be verified at the receiver end. So we can show this pictorially as:
Token with Claims
Sometimes token can be XML based Security Assertion Markup Language (SAML) format. But now, the application uses a rather simpler token call as Simple web Token (SWT). So the benefit is that here, we do not pass user credential but we can also pass some other information of the user to the application.

Identity Provider and STS

Identity provider is the key in this technology, this actually authenticates the user and creates the token with claims, as per the requirement and digitally signs it before sending. Identity provider is also known as Security token service. So how does the STS work, let's have a view.
Identity Provider

RP (Relying Party)

Relying party are the applications that use these Identity Providers for authentication. They just need to understand and verify the token and get all the data from the token itself which is required. But before all this, RP needs to build a trust relationship and tell the Identity provider what all data is needed for a user. So that next time it receives a token, it can verify the issuer and get the required data.

Complete Scenario

Now you guys got all the basic information about Claim based Authentication. Now let us have a look at how this Identity provider is used.
Complete System
So this is the basics of Claim based Authentication.

Do share your views about this post and let me know if I have missed anything.

Wednesday, 12 September 2012

Convert SharePoint classic web application to claims based web application

To convert a classic mode web application to claims based web application, the following steps needs to be done
1) Open SharePoint 2010 powershell command prompt as administrator
2) Run the following commands
  • $webApp = Get-SPWebApplication “http://sp2010
  • $webApp.UseClaimsAuthentication = $True
  • $webApp.Update()
3) Go to central administration-> Application Management -> Site Collection Administrators
4) Select each site collection, delete and readd the primary and secondary site collection administrators
5) Open site collections in IE. If you get access denied message then run the following commands
  • $webApp = Get-SPWebApplication “http://sp2010
  • $webApp.MigrateUsers($True)
6) Wait for some time till the migrate users timer job finishes before you open site collection in IE

Wednesday, 25 July 2012

Whats new in Authentication in SharePoint 2013 Preview

Taken from the documentation:


What's new in authentication for SharePoint 2013 Preview




Authentication enhancements in SharePoint 2013 Preview make the use of claims-based authentication easier and enable new scenarios and functionality for Exchange Server 2013 Preview, Lync Server 2013 Preview, and apps in the SharePoint Store or App Catalog. SharePoint 2013 Preview introduces support for server-to-server authentication and app authentication by utilizing and extending the Open Authorization 2.0 (OAuth 2.0) web authorization protocol. OAuth is an industry standard protocol that provides temporary, redirection-based authorization. A user or a web application that acts on behalf of a user can request authorization to temporarily access specified network resources from a resource owner. For more information, see OAuth 2.0.
Support for OAuth in SharePoint 2013 Preview allows users to grant apps in the SharePoint Store and App Catalog access to specified, protected user resources and data (including contact lists, documents, photographs, and videos) without requiring the app to obtain, store, or submit the user's credentials. OAuth allows app and services to act on behalf of users for limited access to SharePoint resources. For example, a user might approve permissions to an app to grant access to a specific folder of a document library. This enables an app, such as a third-party photo printing app, to access and copy the files in the specific folder upon user request, without having to use or verify the user's account credentials.


User authentication and authorization in SharePoint 2013 Preview


User authentication in SharePoint 2013 Preview is the process that verifies the identity of a user who requests access to a SharePoint web application. An authentication provider issues the authenticated user a security token that encapsulates a set of claims-based assertions about the user and is used to verify a set of permissions that are assigned to the user. User authorization in SharePoint 2013 Preview is the process that determines the users who can perform defined operations on a specified resource within a SharePoint web application. SharePoint 2013 Preview supports user authentication based on the following methods:

  • Windows claims
  • Security Assertion Markup Language (SAML)-based claims
  • Forms-based authentication claims

These claims-based authentication methods are now the recommended authentication methods for SharePoint 2013 Preview.
The app authentication and server-to-server authentication features of SharePoint 2013 Preview require claims-based authentication. Because of this, claims-based authentication is the default for new web applications in SharePoint 2013 Preview. When you create a web application in Central Administration, you can only specify authentication methods for claims-based authentication. Although Windows Classic mode authentication is still available in SharePoint 2013 Preview and can be configured through Windows PowerShell, we recommend that you use claims-based authentication. Windows Classic mode authentication is deprecated in SharePoint 2013 Preview.

Improvements in claims infrastructure


SharePoint 2013 Preview also includes the following improvements in claims authentication infrastructure:

  • Easier migration from classic mode to Windows-based claims mode with the new Convert-SPWebApplicationWindows PowerShell cmdlet
    Migration can be run against each content database and each web application. This is in contrast to SharePoint 2010 Products, in which the migration was run against each web application. For more information, see Migrate from classic-mode to claims-based authentication in SharePoint 2013 Preview.
  • Login tokens are now cached in the new Distributed Cache Service
    SharePoint 2013 Preview uses a new Distributed Cache Service to cache login tokens. In SharePoint 2010 Products, the login token is stored in the memory of each web front-end server. Each time a user accesses a specific web front-end server, it needs to authenticate. If you use network load balancers in front of your web front-ends, users need to authenticate for each web front-end server that is accessed behind the load balancer, causing possible multiple re-authentications. To avoid re-authentication and its delay, it is recommended to enable and configure load balancer affinity (also known as sticky sessions). By storing the login tokens in the Distributed Cache Service in SharePoint 2013 Preview, the configuration of affinity in your load balancing solution is no longer required. There are also scale-out benefits and less memory utilization in the web front-ends because of a dedicated cache service.
  • More logging makes the troubleshooting of authentication issues easier
    SharePoint 2013 Preview has much more logging to help you troubleshoot authentication issues. Examples of enhanced logging support are the following:
    • Separate categorized-claims related logs for each authentication mode
    • Information about adding and removing FedAuth cookies from the Distributed Cache Service
    • Information about the reason why a FedAuth cookie could not be used, such as a cookie expiration or a failure to decrypt
    • Information about where authentication requests are redirected
    • Information about the failures of user migration in a specific site collection

Server-to-server authentication


SharePoint 2013 Preview extends OAuth to implement a server-to-server authentication protocol that can be used by services such as SharePoint 2013 Preview to authenticate other services such as Exchange Server 2013 Preview or Lync Server 2013 Preview or services that are compliant with the server-to-server authentication protocol.
SharePoint 2013 Preview has a dedicated local server-to-server security token service (STS) that provides server-to-server security tokens that contain user identity claims to enable cross-server authenticated access. These user identity claims are used by the other service to lookup the user against its own identity provider. A trust established between the local STS (the SharePoint 2013 Preview server-to-server STS) and other server-to-server compliant services (the Exchange Server 2013 Preview or Lync Server 2013 Preview server-to-server STS) is the key functionality that makes server-to-server possible. For on-premises deployments, you configure the JavaScript Object Notation (JSON) metadata endpoint of the other server-to-server compliant service to establish this trust relationship. For online services, an instance of the Windows Azure Access Control Service (ACS) acts as a trust broker to enable cross-server communications among the three types of servers.
The new server-to-server STS in SharePoint 2013 Preview issues access tokens for server-to-server authentication. In SharePoint 2013 Preview (and also in SharePoint 2010 Products), trusted identity providers that are compliant with the WS-Federation protocol are supported. However, the new server-to-server STS in SharePoint 2013 Preview performs only the functionality that enables temporary access tokens to access other services such as Exchange Server 2013 Preview and Lync Server 2013 Preview. The server-to-server STS is not used for user authentication and is not listed on the user sign-in page, the Authentication Provider UI in Central Administration, or in the People Picker in SharePoint 2013 Products.

App authentication


SharePoint 2013 Preview uses OAuth 2.0 to authorize requests by apps in the SharePoint Store and App Catalog to access SharePoint resources on behalf of a user. The user grants permission to apps in the SharePoint Store and App Catalog to access SharePoint resources on the user's behalf when they are installed. For example, a user installs an app from the SharePoint Store. A SharePoint site contains an embedded HTML inline frame (IFRAME) that the app renders and that requires the app to access a user list. When a Web browser displays the site, the app then calls back to the server running SharePoint 2013 Preview to access the list on behalf of the user. After the app obtains the data from the list, it displays the contents of the IFRAME.
The app authentication process in SharePoint 2013 Preview uses OAuth to verify a claim that an app makes and assert that the app can act on behalf of an authenticated user. In SharePoint 2013 Preview, an instance of the Windows Azure ACS acts as the app identity provider. You can also use app authentication without ACS. The authorization process verifies that an authenticated app has permission to perform a defined operation or to access a specified resource.

Whats new in Authentication in SharePoint 2013 Preview



Taken from the documentation:


What's new in authentication for SharePoint 2013 Preview




Authentication enhancements in SharePoint 2013 Preview make the use of claims-based authentication easier and enable new scenarios and functionality for Exchange Server 2013 Preview, Lync Server 2013 Preview, and apps in the SharePoint Store or App Catalog. SharePoint 2013 Preview introduces support for server-to-server authentication and app authentication by utilizing and extending the Open Authorization 2.0 (OAuth 2.0) web authorization protocol. OAuth is an industry standard protocol that provides temporary, redirection-based authorization. A user or a web application that acts on behalf of a user can request authorization to temporarily access specified network resources from a resource owner. For more information, see OAuth 2.0.
Support for OAuth in SharePoint 2013 Preview allows users to grant apps in the SharePoint Store and App Catalog access to specified, protected user resources and data (including contact lists, documents, photographs, and videos) without requiring the app to obtain, store, or submit the user's credentials. OAuth allows app and services to act on behalf of users for limited access to SharePoint resources. For example, a user might approve permissions to an app to grant access to a specific folder of a document library. This enables an app, such as a third-party photo printing app, to access and copy the files in the specific folder upon user request, without having to use or verify the user's account credentials.

User authentication and authorization in SharePoint 2013 Preview

User authentication in SharePoint 2013 Preview is the process that verifies the identity of a user who requests access to a SharePoint web application. An authentication provider issues the authenticated user a security token that encapsulates a set of claims-based assertions about the user and is used to verify a set of permissions that are assigned to the user. User authorization in SharePoint 2013 Preview is the process that determines the users who can perform defined operations on a specified resource within a SharePoint web application. SharePoint 2013 Preview supports user authentication based on the following methods:
  • Windows claims
  • Security Assertion Markup Language (SAML)-based claims
  • Forms-based authentication claims
These claims-based authentication methods are now the recommended authentication methods for SharePoint 2013 Preview.
The app authentication and server-to-server authentication features of SharePoint 2013 Preview require claims-based authentication. Because of this, claims-based authentication is the default for new web applications in SharePoint 2013 Preview. When you create a web application in Central Administration, you can only specify authentication methods for claims-based authentication. Although Windows Classic mode authentication is still available in SharePoint 2013 Preview and can be configured through Windows PowerShell, we recommend that you use claims-based authentication. Windows Classic mode authentication is deprecated in SharePoint 2013 Preview.

Improvements in claims infrastructure

SharePoint 2013 Preview also includes the following improvements in claims authentication infrastructure:
  • Easier migration from classic mode to Windows-based claims mode with the new Convert-SPWebApplicationWindows PowerShell cmdlet
    Migration can be run against each content database and each web application. This is in contrast to SharePoint 2010 Products, in which the migration was run against each web application. For more information, see Migrate from classic-mode to claims-based authentication in SharePoint 2013 Preview.
  • Login tokens are now cached in the new Distributed Cache Service
    SharePoint 2013 Preview uses a new Distributed Cache Service to cache login tokens. In SharePoint 2010 Products, the login token is stored in the memory of each web front-end server. Each time a user accesses a specific web front-end server, it needs to authenticate. If you use network load balancers in front of your web front-ends, users need to authenticate for each web front-end server that is accessed behind the load balancer, causing possible multiple re-authentications. To avoid re-authentication and its delay, it is recommended to enable and configure load balancer affinity (also known as sticky sessions). By storing the login tokens in the Distributed Cache Service in SharePoint 2013 Preview, the configuration of affinity in your load balancing solution is no longer required. There are also scale-out benefits and less memory utilization in the web front-ends because of a dedicated cache service.
  • More logging makes the troubleshooting of authentication issues easier
    SharePoint 2013 Preview has much more logging to help you troubleshoot authentication issues. Examples of enhanced logging support are the following:
    • Separate categorized-claims related logs for each authentication mode
    • Information about adding and removing FedAuth cookies from the Distributed Cache Service
    • Information about the reason why a FedAuth cookie could not be used, such as a cookie expiration or a failure to decrypt
    • Information about where authentication requests are redirected
    • Information about the failures of user migration in a specific site collection

Server-to-server authentication

SharePoint 2013 Preview extends OAuth to implement a server-to-server authentication protocol that can be used by services such as SharePoint 2013 Preview to authenticate other services such as Exchange Server 2013 Preview or Lync Server 2013 Preview or services that are compliant with the server-to-server authentication protocol.
SharePoint 2013 Preview has a dedicated local server-to-server security token service (STS) that provides server-to-server security tokens that contain user identity claims to enable cross-server authenticated access. These user identity claims are used by the other service to lookup the user against its own identity provider. A trust established between the local STS (the SharePoint 2013 Preview server-to-server STS) and other server-to-server compliant services (the Exchange Server 2013 Preview or Lync Server 2013 Preview server-to-server STS) is the key functionality that makes server-to-server possible. For on-premises deployments, you configure the JavaScript Object Notation (JSON) metadata endpoint of the other server-to-server compliant service to establish this trust relationship. For online services, an instance of the Windows Azure Access Control Service (ACS) acts as a trust broker to enable cross-server communications among the three types of servers.
The new server-to-server STS in SharePoint 2013 Preview issues access tokens for server-to-server authentication. In SharePoint 2013 Preview (and also in SharePoint 2010 Products), trusted identity providers that are compliant with the WS-Federation protocol are supported. However, the new server-to-server STS in SharePoint 2013 Preview performs only the functionality that enables temporary access tokens to access other services such as Exchange Server 2013 Preview and Lync Server 2013 Preview. The server-to-server STS is not used for user authentication and is not listed on the user sign-in page, the Authentication Provider UI in Central Administration, or in the People Picker in SharePoint 2013 Products.

App authentication

SharePoint 2013 Preview uses OAuth 2.0 to authorize requests by apps in the SharePoint Store and App Catalog to access SharePoint resources on behalf of a user. The user grants permission to apps in the SharePoint Store and App Catalog to access SharePoint resources on the user's behalf when they are installed. For example, a user installs an app from the SharePoint Store. A SharePoint site contains an embedded HTML inline frame (IFRAME) that the app renders and that requires the app to access a user list. When a Web browser displays the site, the app then calls back to the server running SharePoint 2013 Preview to access the list on behalf of the user. After the app obtains the data from the list, it displays the contents of the IFRAME.
The app authentication process in SharePoint 2013 Preview uses OAuth to verify a claim that an app makes and assert that the app can act on behalf of an authenticated user. In SharePoint 2013 Preview, an instance of the Windows Azure ACS acts as the app identity provider. You can also use app authentication without ACS. The authorization process verifies that an authenticated app has permission to perform a defined operation or to access a specified resource.

Changes from SharePoint 2010 to 2013

Taken from Documentation release for SharePoint 2013 Preview......


Features deprecated in SharePoint 2013 Preview

The following features and functionality have been deprecated or changed in SharePoint 2013 Preview.

Visual upgrade

 

Description: The visual upgrade feature in SharePoint Server 2010 is not available in SharePoint 2013 Preview. For the upgrade from Office SharePoint Server 2007 to SharePoint Server 2010, you could choose to use the visual upgrade feature to give site collection owners and site owners the opportunity to preserve the previous user interface temporarily while still upgrading the infrastructure and databases, site collections, and features to the latest version. This allowed site collection owners and site owners to update customizations to work in the new user interface. Once the database and site collection upgrade was complete, the user had the option to upgrade the user interface on a more granular level of the website (SPWeb object).
Reason for change: The visual upgrade feature is replaced with deferred site collection upgrade. The site collection upgrade process is not reversible. The deferred site collection upgrade is a more comprehensive upgrade process than visual upgrade.
Visual upgrade preserved only the old master pages, CSS files, and HTML files. Deferred site collection upgrade preserves much more, including SPFeature functionality. To achieve the deferred site collection upgrade, major changes in the architecture were required, including the removal of visual upgrade.
With deferred site collection upgrade, you can continue to use the UI from the previous version (SharePoint Server 2010) more seamlessly than is possible with visual upgrade. The master page, CSS, JScript, and SPFeatures will remain in SharePoint Server 2010 mode. One key difference is that the granularity of upgrading the user interface is per site collection (SPSite) instead of site (SPWeb). Users can still preview their site in the new SharePoint 2013 Preview user interface before committing. However, this is accomplished by creating and upgrading a temporary copy of their site collection instead of a preview in the existing instance of the site collection. The reason for previewing a copy of the site collection is because of the complexity of what occurs during site collection upgrade. Once a site collection is upgraded, it cannot be rolled back. Therefore, performing a preview would not be possible except in a copy of the site collection.
Migration path: Site collection administrators who are using visual upgrade to continue to use SharePoint Server 2007 must move to the SharePoint Server 2010 user interface before upgrading to SharePoint 2013 Preview. After the content database is upgraded, users can use deferred site collection upgrade to continue to use the SharePoint Server 2010 experience for their site collections. Site collection administrators can be notified by their farm administrator when a site collection is ready for upgrade and the site collection administrators can then choose to either perform the upgrade of their site collection or optionally first preview the new functionality in a temporary copy of their site collection.
Any SharePoint user interface might have dependencies on visual upgrade. The main dependency was getting the user interface version and then outputting the correct user interface (new or legacy). The visual upgrade API feature is updated so that the user interface version is remapped to the new site collection compatibility level property. This returns the same information about which version the site uses as before. Therefore, dependent code does not need to change.

Document Workspace site template

Description: When you create a site in SharePoint 2013 Preview, the Document Workspace site template is not available.
Reason for change: The scenario of collaborating on a document is now provided by the Team Site site template. The Document Workspace site template was removed from SharePoint 2013 Preview to simplify the list of templates that are available when a user creates a new site collection.
Migration path: Existing sites that were created by using the Document Workspace site template will continue to operate in SharePoint 2013 Preview. The Document Workspace site template will be removed completely from the next major release of SharePoint and sites that were created by using the Document Workspace site template will not be supported.

Personalization Site site template

Description: When you create a site in SharePoint 2013 Preview, the Personalization Site site template is not available.
Reason for change: The Personalization Site site template was not a widely used site template. The Personalization Site site template was removed from SharePoint 2013 Preview to simplify the list of templates that are available when a user creates a new site collection.
Migration path: Existing sites that were created by using the Personalization Site site template will continue to operate in SharePoint 2013 Preview. The Personalization Site site template will be removed completely from the next major release of SharePoint and sites that were created by using the Personalization Site site template will not be supported.

 Meeting Workspace site templates
Description: When you create a site in SharePoint 2013 Preview, all five of the Meeting Workspace site templates are not available. This includes the Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and Multipage Meeting Workspace.
Reason for change: SharePoint 2013 Preview and Office 2013 Preview provide other features that support meetings and collaboration. For example, you can use Lync to conduct live meetings, OneNote to take notes during meetings, and a SharePoint team site or My Site to store shared meeting notes.
Migration path: Existing sites that were created by using the Meeting Workspace site templates will continue to operate in SharePoint 2013 Preview. The Meeting Workspace site templates will be removed completely from the next major release of SharePoint and sites that were created by using the Meeting Workspace site templates will not be supported.

Group Work site template and Group Work solution

Description: When you create a site in SharePoint 2013 Preview, the Group Work site template is not available. This Group Work site template provides a groupware solution that teams can use to create, organize, and share information. The Group Work site template includes the Group Calendar, Circulation, Phone-Call Memo, document library, and other basic lists. The Group Work site template and the Group Work solution are discontinued and not available in SharePoint 2013 Preview.
Reason for change: The Group Work site template was not a widely used site template. The Group Work site template was removed from SharePoint 2013 Preview to simplify the list of templates that are available when a user creates a new site collection.
Migration path: Existing sites that were created by using the Group Work site template will continue to operate in SharePoint 2013 Preview. The Group Work site template will be removed completely from the next major release of SharePoint and sites that were created by using the Group Work site template will not be supported.

Visio Process Repository site template

Description: When you create a site in SharePoint 2013 Preview, the Visio Process Repository site template will continue to be available. However, the Visio Process Repository site template will be removed in the next major release of SharePoint.
Reason for change: The Visio Process Repository site template is not a widely used site template. The Visio Process Repository site template was removed from SharePoint 2013 Preview to simplify the list of templates that are available when a user creates a new site collection.
Migration path: Not required. The Visio Process Repository site template is available in SharePoint 2013 Preview.

Unghosting and customizing CSS files

Description: The following methods are included in SharePoint 2013 Preview, but will be removed from the next major release of SharePoint:

  • Microsoft.SharePoint.SoapServer.Webs.CustomizeCss
  • Microsoft.SharePoint.SoapServer.Webs.RevertCss

The Webs.CustomizeCss method applies style sheet customization to a particular file.
The Webs.RevertCss method reverts style sheet customization of a file to the default style sheet.
These two methods are stored in Webs.asmx.cs and are defined in Webswsdl.asps.
Reason for change: The methods are outdated and are no longer needed.
Migration path: None.

Imaging Web service

Description: The Imaging Web service provides functionality for creating and managing picture libraries. The Imaging Web service will be removed from the next major release of SharePoint. The Imaging Web service is included and supported in SharePoint 2013 Preview.
Reason for change: The Imaging Web service is not widely used. The only client application for the Imaging Web service, Office Picture Manager, is no longer included with SharePoint 2013 Preview. The Imaging Web service is being removed to reduce security vulnerabilities and to simplify the number of ways to connect to SharePoint 2013 Preview.
Migration path: All the functionality of the Imaging Web service is available through the client-side object model (CSOM). The CSOM provides client-side applications with access to a subset of the SharePoint Foundation server object model, including core objects such as site collections, sites, lists, and list items. Also, Web Distributed Authoring and Versioning (WebDAV) provides clients with key functionality of the Imaging Web service (for example, upload, download, and rename).

Excel Services — Can't edit workbooks in the browser that have external data connections

Description: Workbooks with external data connections that use Windows authentication cannot be refreshed in the browser. Instead, you are prompted to open the workbook in the Excel client program. Workbooks that have database or Windows credentials stored either in the Secure Store Service or in the connection string can still be edited in the browser. This change applies only when Excel Web App Preview in Office Web Apps Server Preview is used to view workbooks, not when Excel Services in SharePoint Server 2013 Preview is used.
Reason for change: This is a design limitation in SharePoint 2013 Preview.
Migration path: You can still refresh these workbooks in the Excel client program. Additionally, a service application administrator can configure that workbooks are viewed in SharePoint 2013 Preview instead of Office Web Apps Server Preview.

Web Analytics in SharePoint Server 2010

Description: Web Analytics in SharePoint Server 2010 has been discontinued and is not available in SharePoint 2013 Preview. Analytics processing for SharePoint 2013 Preview is now a component of the Search service.
Reason for change: A new analytics system was required for SharePoint 2013 Preview that included improvements in scalability and performance, and that had an infrastructure that encompasses SharePoint Online. The Analytics Processing Component in SharePoint 2013 Preview runs analytics jobs to analyze content in the search index and user actions that are performed on SharePoint sites.
SharePoint 2013 Preview still logs every click in SharePoint sites and still provides a count of hits for every document. User data is made anonymous early in the logging process and the Analytics Processing Component is scalable to the service.
This analytics data is used in SharePoint 2013 Preview to provide new item-to-item recommendation features, to show view counts that are embedded in SharePoint 2013 Preview and Search Server user interface, to provide a report of the top items in a site and list, and to influence the relevancy algorithm of search.
What happens to Web Analytics after upgrade: The Web Analytics Service is not upgraded to the Analytics Processing Component in SharePoint 2013 Preview. When you upgrade to SharePoint 2013 Preview, the databases that contain the data from Web Analytics in SharePoint Server 2010 are not removed. These databases are not used by or maintained by the Analytics Processing Component in SharePoint 2013 Preview. This means that documents on sites in SharePoint Server 2010 that are upgraded will show a hit count of 0.
When you upgrade to SharePoint 2013 Preview, do not attach and upgrade the databases that contain the data from Web Analytics in SharePoint Server 2010. We recommend that you turn off Web Analytics in the SharePoint Server 2010 environment before you copy the content databases that you want to upgrade to SharePoint 2013 Preview.
Reports from Web Analytics for the top items in a site are carried forward. Reports that show browser traffic, top users of a site, and referring URL are not carried forward and are not used by the Analytics Processing Component in SharePoint 2013 Preview.
Administrative reports for the quota usage of site collections in the farm are not available in SharePoint 2013 Preview.
SharePoint 2013 Preview does not support the Web Analytics Web Part. After a farm is upgraded to SharePoint 2013 Preview, all instances of a Web Analytics Web Part will not function. The page that includes the Analytics Web Part will render and a message appears that informs the user that the Web Part is no longer supported.
Migration path: None. Data collection for Analytics Processing in SharePoint 2013 Preview starts immediately for sites, including SharePoint Server 2010 sites.

Friday, 27 May 2011

SharePoint 2010: 'Hiding' Folders in a Document Library

One challenge we always face when working with clients is to respond to requests that don't use a technical solution exactly as it should be used. Case in point: a client is now working in a new SharePoint 2010 environment we're building out. They're working within a Document Library, and they want to hide a folder from view of (most) users. Not a problem. Use Permissions, right? Wrong. Client doesn't want to hassle with Permissions, but simply wants to hide a folder so only a few people who know about it can upload content to that folder by going directly there via a URL.
Check out the screenshots below.
I met the challenge by:
  • Creating a Folder Content Type called “Special Folder”
  • Creating a Site Column called “Hidden Folder” as a Choice list with “Yes” set as the Default Value
  • Attaching the Site Column “Hidden Folder” to the Content Type “Special Folder” (making it required)
  • Modifying the default View of the Shared Documents Document Library to hide the folder if the Content Type “Hidden Folder” is set to “Yes”.
This nets out to a simple scenario: The client can create a folder called “Special Folder” which will be hidden from being seen in the Document Library. The client can access the folder by opening the Document Library in Explorer view via an exact URL, the folder(s) can be seen and documents can be uploaded into the folder(s) but remain out of sight because the folders are hidden.
Not an ideal solution (Permissions would be a better choice), but it does satisfy the client need. Case closed? I hope not.
 Is there another (EASIER) way to do this?
VIEWS:
Standard Document Library (note there is no folder in view)

Creating the Site Column (Note that "Yes" is the default choice)

Creating the site column

Creating the Custom Content Type called Special Folder

Creating the Content Type

Viewing the Content Type settings (Note that the Site Column Hidden Folder is attached to this Content Type)

Custom Content Type




Creating a new Special Folder (Note that this folder will be hidden and will not appear in the Document Library)

Creating a New Hidden Folder

Creating a new Special Folder (Note that this folder will be hidden and will not appear in the Document Library)

Creating a new folder


Opening the Document Library in Explorer View (Note that we still don't see the new Hidden Folder)

Open with Explorer View

Hidden folder in Explorer view (Note that documents copy/pasted into this folder will not be visible in the Document Library view)

Hidden Folder in Explorer View

Friday, 20 May 2011

SharePoint Search

Create and Configure a Scope to Only Return Documents in a Search Result


It is evident that SharePoint can index content in web sites, file shares, exchange public folders, or any other content that has a URL. However, many users like to execute a search which is restricted to a specific type of content such as Tasks, Announcements, Events, Documents, Blogs etc or a content source such as a document workspace or a team site or a file share etc. On a similar note I would like to quote what one of our customers who was evaluating our search product Longitude for SharePoint asked for.
"We are most concerned with documents and to us, most of the other items that come up that may contain the search string are clutter and it would be nice to easily filter them out"
The customer basically wanted a provision to narrow down search to documents only and was not interested in the announcements, events, and wiki pages etc that came up in the resutls.Typically when the requirement is about being able to execute a search restricted to a content type or a content source, SharePoint Search scope is the way to go.
In this article, we will go through all those configurations required to create a search scope that will be dedicated to return only documents. Before we start with the configurations required, let's take a look at the basics of SharePoint search scope.
In an enterprise, gigs and terabytes of data is crawled from various content sources on a regular basis. The crawls create a single content index representing all the content sources. SharePoint provides search scopes as a way to filter the content index to define a subset of it. By effectively defining a section of the content index a head of the query time, search scopes facilitate to limit the results that are returned from the index. Search scopes are pre-compiled and efficient.
SharePoint has two types of search scopes.
The Contextual scopes are created automatically based on the context of the site area user is currently working on such as a web or a list etc. In a SharePoint site, these scopes read like "this site", "this list" etc.
The Custom Scopes are the ones that an administrator can create to target a specific type of content. Two types of custom scopes can be created:
  • SSP Level Scopes are global and shared across all the site collections that are associated with the SSP. The SSP level scopes are managed at the SSP level by a farm administrator.
  • Site collection level scopes are local to a site collection and are managed by the site collection administrator.
Create a scope to return only documents in search
In the steps outlined below, we will be creating a SSP level scope called "All Documents" and add a rule to include only documents.
Step1: Create a all documents scope
  • Browse to the central administration site and Click on the SSP.
  • Click on search settings and then Click on view Scopes.
  • Click on new scope link.
  • Enter title as "All Documents" and leave other details blank and Click OK.
Step2: Allow the "IsDocument" property to be used in scopes
IsDocument is a managed property provided by SharePoint and is true for all documents only. Therefore, before adding a scope rule to the scope "All Documents", we must ensure that this property can be used in scope. Follow the steps to allow the property to be used in scopes.
  • Browse to the central administration site.
  • Click on the Shared Service Provider (SSP).
  • Click on Search settings
  • Click on metadata property mappings.
  • Find the managed property IsDocument and set "Use in Scope" property to true and Click Ok.
Step3: Add scope rule
  • Browse to the central administration site.
  • Click on the Shared Service Provider (SSP) for the site.
  • Click on Search settings
  • Click on View Scopes.
  • Click on Edit Properties and rules for the scope "All Documents".
  • Click on New Rule.
  • Add a property query rule where the property IsDocument=1 and set the scope behavior to require and click OK.
Step4: Add the scope to a scope display group
A scope display group is used to organize a list of scopes. The scope display group is then assigned to a search box to be able to search on those scopes. To add the scope "All Documents" to a scope display group, follow the steps below:
  • Browse to the site collection for your search center (This is the site collection which has your search page).
  • Select Site actions>Site settings>Search scopes. You will notice that the scope "All Documents" has no scope display group assigned at this time. We can either create a new display group and add or add it to an existing group.
  • Click on the scope display group "Search Dropdown" and Select the scope "All Documents".
Step5: Using the scope display group for a search box web part
The scope display group "Search Dropdown" has our scope included in it. In this step, we will ensure that our search box webpart uses this scope display group.
  • Browse to the search page and select site actions>edit page.
  • Select edit>modify shared webpart on the search box web part.
  • On the properties pane, expand the section miscellaneous and check the property value for the property scope display group and make sure that it is "Search Dropdown" as selected at #Step4.
Step6: Update the scope
Unless the scope is updated, it will not appear on the scopes dropdown of the search box webpart. To update the scope, follow the steps below.
  • Browse to the central administration site and Click the SSP for the site collection.
  • Click on search settings and then Click on Start update now.
We are done. The scope "All Documents" must be available on the scopes dropdown of the search box webpart. If it does not, you would want to make sure that show scope dropdown option is selected for the webpart.
Finally, some frequently asked business requirements questions from our customers where search scopes have been used.
1) I have a content source (cs1) which is an archive of past projects and is static and I have another content source (cs2) which has all active projects with dynamic content. I crawl cs1 once a week and crawl cs2 once a day. However, I want to be able to search results from both content sources at one place in a Global Search Center.
  • Create a scope say "Global Scope".
  • Add an include rule by selecting cs1 as the content source.
  • Add another include rule by selecting cs2 as the content source.
  • Use the scope "Global Scope" in your Global Search Center to be able to view results from both the site collections at one place.
2) How do I get only PDF documents in my search results?

  • Create a scope say "PDF Documents"
  • Add a property query based rule where FileExtension is equal to pdf.
  • Set the scope rule behavior to include.
  • Update the scopes.
  • Search using the scope "PDF Documents".
3) I want to search on only those documents that have been tagged as "Legal Documents".
This requirement has got two aspects of it:

  • Results must be documents not a blog posts or wiki pages or a list item etc
  • Results must have only those documents which have been tagged as Legal documents.
Here you will have to create a document with two scope rules. The first would be to include all the documents from the content index and the second would be to ensure that only Legal documents are included. Assuming that you have a managed property called "Tag" mapped to the column that stores the tags for the documents, follow the steps below to create a scope to search against.

  • Create a scope say "Legal Documents"
  • Add a property query based rule where IsDocument is equal to 1 and Set the scope rule behavior to include.
  • Add another property query based rule where Tag is equal to "Legal" and Set the scope rule behavior to require.
  • Update the scopes.
  • Search using the scope "Legal Documents".
4) I want to search on only those documents that have been tagged as "Legal Documents" and are not authored by Martin.
As opposed to the requirement #3, this one has got three aspects of it:

  • Results must be documents not a blog posts or wiki pages or a list item etc
  • Results must have only those documents which have been tagged as Legal documents.
  • Results must not have those documents which are authored by Martin.
In addition to the two rules as mentioned #3, we would also need a third rule to exclude those documents where Martin is the author. Therefore, assuming that you have a managed property called "Tag" mapped to the column that stores the tags for the documents, follow the steps below to create a scope to search against.

  • Create a scope say "Legal Documents"
  • Add a property query based rule where IsDocument is equal to 1 and Set the scope rule behavior to include.
  • Add another property query based rule where Tag is equal to "Legal" and Set the scope rule behavior to require.
  • Add another property query based rule where Author is equal to "Martin" and Set the scope rule behavior to exclude.
  • Update the scopes.
  • Search using the scope "Legal Documents".
5) I have many blog sites which are spread over different site collections. How do I have a search scope that returns only blogs related results.
This requirement is to include content specific i.e. blog related items in the search scope that can be search against. We must see if there is a property which represents a specific type of content. Fortunately, contentclass is one such property that distinguishes content from one another. Therefore follow the steps below to create a scope.
  • Create a scope say "Blogs"
  • Add a property query based rule where contentClass is equal to "sts_listitem_posts" and Set the scope rule behavior to include.
  • Add another property query based rule where contentClass is equal to "sts_listitem_comments" and Set the scope rule behavior to include.
  • Update the scopes.
  • Search using the scope "Blogs".
Note: Just like "sts_listitem_posts" and "sts_listitem_comments", there are other pre-defined values Sharepoint assigns to the property contentClass to represent different types of content. The table below has most of them.

STS_Document

STS_List_Comments

STS_List_300

STS_List_Contacts

STS_List_850

STS_List_DiscussionBoard

STS_List_Announcements

STS_List_DocumentLibrary

STS_List_Categories

STS_List_Events

STS_List_GenericList

STS_list_Links

STS_List_PictureLibrary

STS_List_Posts

STS_List_Tasks

STS_ListItem_300

STS_ListItem_850

STS_ListItem_Announcements

STS_ListItem_Categories

STS_ListItem_Comments

STS_ListItem_Contacts

STS_ListItem_DiscussionBoard

STS_ListItem_DocumentLibrary

STS_ListItem_Events

STS_ListItem_GenericList

STS_ListItem_Links

STS_ListItem_Posts

STS_Site

STS_Web