Considerations When Using Claims with SharePoint

Chapter F (A guide to claims-based identity and access control)

Users who access a SharePoint 2010 application that is configured to use claims-based authentication and has multiple authentication methods set up will have the same access to resources and services

when using any of the authentication methods. However, if the user has two different accounts configured (in other words, has accounts in two different repositories, such as a social identity provider and

ASP.NET), and the authentication method used validates the user against one of these accounts, the user will have access to only resources and services configured for the account that was validated.

When upgrading existing applications to SharePoint 2010, be aware of the following factors that may affect your choice of authentication type:

• Claims-based authentication requires communication over HTTPS with a token issuer and identity provider. It typically also requires multiple redirects for clients that are using a web browser. These are likely to be slower than Windows Authentication or ASP.NET forms-based authentication lookup. Even after initial authentication, as users move between applications taking advantage of single sign-on, the applications and services must make calls over HTTPS to validate the authentication tokens.
• Web Parts or custom code that relies on or uses Windows identities must be modified if you choose claims-based authentication. Consider choosing classic mode authentication until all custom code is updated.
• When you upgrade a web application from classic mode to claims-based authentication, you must use Windows PowerShell®command-line interface to convert Windows identities to claims identities. This can take time, and you must factor in time for this operation as part of the upgrade process.
• Search alerts are currently not supported with claims-based authentication.
• You cannot use custom ISAPI extensions or HTTP modules with the forms-based authentication method because the SharePoint STS communicates directly with the forms authentication provider by calling its ValidateUsermethod.
• Some client-hosted applications may attempt to authenticate with the server when displaying content linked from SharePoint application web pages. If you are using claims-based authentication and the client-hosted application is not claims-aware (as in the case of Windows Media Player), this content might not be displayed.
• Managing the session lifetime is not a trivial exercise when using claims-based authentication. For details of how you can manage session lifetime, see Chapter 11, “Claims-Based Single Sign-On for Microsoft SharePoint 2010.”
• The External Content Type Designer in SharePoint Designer 2010 cannot discover claims aware WSDL endpoints. For more information, see MSDN®Knowledge Base article 982268 at Link

SharePoint 2013 & SkyDrive(Pro)

SkyDive Pro in SharePoint 2013 has nothing to do with SkyDrive.com. Do not worry, nothing will go to Microsoft's server or users personal SkyDrive accounts.

SkyDrive Pro, while being your MySite Documents library, is also the name of the technology that syncs SharePoint 2013 to your desktop.

The desktop sync works like original SkyDrive with an entry in favorites of windows explorer. You can have multiple libraries synced to your desktop (now drag and drop documents).

References

• Todd Klindt

Cross-site publishing in SharePoint 2013

The great site barrier for content in SharePoint has been the pivot for development projects for long. Ranging from custom event handlers, custom timer jobs, even custom windows services etc. to harvest data from cross sites have been common talk.

And then SharePoint 2013 walks in like a boss and turns off the switch on all of above. The question is how this fits with your needs and where/how can you avoid custom code?

A simple example can be when you want to publish the content secured behind your intranet to extranet or to the internet site. With this feature you can pull news/blog entries from the company’s intranet and publish them on your public website. This will act like a passive hot link to the item on your secured site with the refresh rate dependent on the search crawl.

Basics

There are a few logical components to consider

• An authoring site is where content is created and hosted
•  A catalog is an attribute that you can add to a list or a library in the authoring site. Marking a list or a library as a catalog makes the content easily accessible to other site collections.
• Search is the engine/glue that connects your catalog to a publishing site.
• The term store holds metadata terms that are used to organize content for publishing on target sites.
• A publishing site is where visitors go to see and read content.

Limitation

The content which can be indexed is the requirement for cross site publishing. The files (images, documents) still need to be handled traditionally.

Benefits of Using Cross Site Publishing

• Site architectures will have a broader canvas (Do remember to plan the assets).
• Allows content to be shared anonymously from intranets/extranets
•  Can be used across site collections and even across farms.
•  Separates content authoring from branding and rendering , avoids content duplication.

SharePoint 2013 Top 10 New Features

From Joel Oleson's Blog, SharePoint 2013 looks very promising!

Fake CVs : it's a big problem

A fast growing technology/development platform like SharePoint will always face the talent crunch. The simple principle of demand and supply in recent times have made the SharePoint developer a hot commodity, this puts pressure on companies which doles out extra dough as compared to a similar experienced developer.

All this has been attracting low lives who will fake their CVs and their salary information to secure that lucrative job. Landing a job is easier, trouble starts afterwards when expectations are higher than their calibre, no amount of text mugging or tech talk will help them in getting the task done. Two attributes will clearly suffer i.e. time and quality. There is cost involved too but by the time the hole is identified, the damage of time and quality would be irreparable.

Switching the resource immediately is the best solution otherwise the technology has to take all the blame later.

From my experience, following checklist should ensure a credible technical screening:

1. Pseudo code for a variety of scenarios should be discussed on paper to get the candidate's grasp on technology. In SharePoint it means the API. 
2. Just talking topics and basics of terms is not at all sufficient. Better ask them about a recent challenge that you have faced, the response will tell about their depth of knowledge and experience. Talking about topics is once thing a fraudster will prepare best. 
3. Ignore Microsoft certification like MCP, MCTS etc. Anybody or everybody can get one easily.
4. It goes mainly for HR, instead of asking for salary slips ask for last few years income tax return. It's so easy to forge a computer generated slip than it is to forge a tax return.
5. The professional background checking company are the most lazy of lot. A couple of calls to landline of previous company should be enough. In a few instances in India, I have seen people staging these too with their previous managers, so don't always trust the number given by them!

Hope it helps somebody somewhere. It's far easier to train a technical guy in a technology than hiring a poser with high expectations.