Two important improvements in SharePoint 2013 include a change of Microsoft’s recommendation that web applications should use claims-based authentication by default, and the use of host-named site collections.
· As with SharePoint 2010, with SharePoint 2013 you can create web applications to use either classic or claims-based authentication.
· With either type of web application, claims authentication is used for authentication flow within the farm.
· SharePoint 2013 has extended claims-based authentication via OAuth 2.0 and a dedicated server to- server STS authentication, which together make it possible for your organization to use new scenarios and functionality for Exchange Server 2013, Lync Server 2013, apps in the SharePoint Store or App Catalog, and other services that are compliant with the server-to-server authentication protocol.
· SharePoint 2013 supports user authentication based on the following claims-based authentication methods:
-Forms-based authentication claims
When using the Central Administration website, only claims-based web applications can be created. Classic-based authentication is now deprecated, and to create classic-mode web applications, you must use Windows PowerShell. If you are upgrading from SharePoint 2010 to SharePoint 2013, you can convert your classic-mode web applications to claims-based before upgrading.
Host-named site collections
· Microsoft recommends that you create host-named site collections (HNSC) and not path-based site collection addressing.
· HNSC is a mechanism for consolidating web applications into individual site collections, yet letting them retain their existing URLs.
· In SharePoint 2010, web applications contained one or more site collections and the common practice was to create them under wildcard-managed paths such as http://intranet.adventure-works.com/sites/hr or http://intranet.adventure-works.com/sites/it.
· Using HNSC, each site collection can have its own top-level URL, so the equivalent site collection could be http://hr.adventure-works.com or http://it.adventure-works.com. Both of these site collections are created in the same web application and could be stored in the same content data.
· The web application that hosts the HNSC must have a default site collection at its root but does not need a template assigned to it, because it will not be used for anything. Also, for each HNSC you must update the DNS to point to the IP address for the web application that is hosting them or use a wildcard DNS entry.
However, there are still some limitations to this approach
· HNSC cannot be extended or mapped. You need to set a different set of policies as per the URL.
· HNSC should not be hosted in multiple web applications. Although this is technically possible, it is complicated to achieve and manage.
· You should consider perhaps using HNSC in one web application, even though you can create HNSC and path-based site collections on the same web application that you use path-based site collections in other web applications.
· And, of course, it is very unlikely that you would use HNSC for personal sites.
· HNSC cannot be created within Central Administration; you must use Windows PowerShell and you need to configure the DNS to send all requests for http://*.adventure-works.com to a web application.
· This web application must be extended with SharePoint and should not be bound to any specific host headers so that it handles all requests.
Self-Service Site Collection Creation
· As with SharePoint 2010, you can enable Self-Service Site Collection Creation (SSC) in SharePoint 2013 with which you can do the following:
· Allow users to create site collections by using the site collection signup page, scsignup.aspx.
· Provide users with a shortcut to create new Team sites at a defined location.
· When you select to prompt users to create either a Team site or a site collection, you can configure Site Classification Settings to be hidden from users, to be an optional choice, or to be a required choice.