Microsoft Sharepoint 2013 Authentication (part 2) - Configuring a Claims Web Application - Creating a New CBA Application, Configuring an Existing CBA Web Application

Creating a New CBA Application

The following set of steps demonstrates how to create a new Claims-Based-Authentication aware web application in SharePoint 2013. The steps below demonstrate creating our application via Central Administration.

1. Open Central Administration.
2. Click the Manage web application link.
3. Click the New button in the ribbon.
4. Under the IIS Web Site section, give the web application a name, port number, host header (optional), and path (default is fine).
5. Under the Security Configuration, check Allow Anonymous if you intend to make your application available to anonymous users.
6. Click User Secure Sockets Layer (SSL) if you have a certificate ready for your application.
7. Skip the Claims Authentication Types and Sign In Page URL sections (we’ll come back to these in a moment).
8. Leave the public URL as default, unless you need to change it.
9. Create a new application pool (unless you wish to reuse one of the existing ones). It is generally good practice to give each web application its own application pool, so you can recycle it without affecting other applications.
10. In the Database Name and Authentication section, provide a name for the database, and credentials for application to access the content database—I usually leave the credentials blank and SharePoint uses the farm account.
11. If you have a mirrored failover database server, you may specify it in the Failover Server section.
12. Select the associated service applications in the Service Application Connections section.
13. Finally, choose to opt in or out for the Customer Experience Improvement Program.
14. At this point, we are ready to look closer at the Claims Authentication Types and Sign In URL sections—scroll back up until you see the dialog like in Figure 1.

    

    Figure 1. Claims authentication types

15. Out of the box, SharePoint supports Windows and Membership Provider authentication types.
16. Windows Authentication comes in two flavors: NTLM and Kerberos, with NTLM being most typical. Kerberos is a ticket-based authentication system and recommended by SharePoint. However, using Kerberos requires that you configure the application pool account as NETWORK SERVICE or a domain account configured for Kerberos. In most all scenarios I have come across, administrators use NTLM.
17. You should not allow Basic Windows Authentication unless you have a good reason to do so—this option passes passwords in plain text and was the only way to allow Netscape and early non-Microsoft browsers to authenticate with SharePoint. Most modern browsers, including Firefox, support NTLM.
18. Forms-Based-Authentication (FBA) uses the traditional Membership and Role Provider model to incorporate custom, SQL, or AD authentication with a forms login page.

     Note  Developers should note that custom Membership and Role Provider code now runs under the STS Web Service Application Pool, so SPContext and HttpContext objects may return null.

19. Check Enable ASP.NET membership and specify either or both Membership and Role providers. Membership providers concern themselves with authentication and users, whereas Role providers expose custom groups.

    The last option in the Claims Authentication Types section is for Trusted Identity Providers. SharePoint allows you to specify an IPSTS as trusted provider. An IPSTS forwards users to separate login pages to authenticate users, before returning SAML tokens containing claims. I discuss use of Trusted Identity Providers (specifically ADFS) in the section titled “Federated Authentication.”

20. The Sign In URL section includes a toggle option to use the default SharePoint sign in page or a custom sign in page you specify.
21. If you have multiple authentication types selected the default sign in page shows a drop-down option when you attempt to authenticate (see Figure 2).

    

    Figure 2. Default Sign In Page, with multiple authentication types

Configuring an Existing CBA Web Application

In this section, we shall configure an existing CBA web application to use claims-aware providers.

1. Open Central Administration.
2. Click the Manage web application link.
3. Select an existing web application in the list shown.
4. Click the Authentication Providers icon in the ribbon, and SharePoint will display a dialog like that in Figure 3.

   

   Figure 3. Authentication providers for a web application

5. The dialog in Figure 3 shows the authentication type assigned to each web application zone in use. In my case I only have one—the default zone. In SharePoint 2010, you had the option of using classic mode or CBA. SharePoint 2013 now insists on CBA, so this is all you should ever see in this dialog.
6. Click the zone you wish to configure CBA.
7. SharePoint shows a dialog, similar to that which we saw when creating an application (Figure 1), only now with sections to configure the Claims Authentication Types, Anonymous Access, Sign In Page URL, Client Integration, and an option specific to this dialog for Client Object Model Permissions Requirement.