Securing your LDAP Membership Provider

There are situations where you want to have Forms based Authentication in SharePoint. That is when you will choose the Claims based Authentication on the Web Application.

We had a requirement where we need to classify two kinds of users Employees and Clients. For a certain reason we had to chose Active Directory as the user store for both kinds of users. We could not reuse the Active Directory of the Employees for the Client users. Hence, we ended creating another domain just for the client users.

When you are using a LdapProvider if the Application Pool account do not have the rights to perform an LDAP request on the Active Directory then you will need to specify two attributes connectionUsername & connectionPassword in the Ldap membership provider of the web.config. This is where you would not want to keep the connectionPassword in plain text. Below I have given a simple implementation to Encrypt and store the password and how you could use a method to retrieve the password at run time.

The web.config of the Web Application, Central Administration & Security Token Service will look something like this with a connectionPassword having the encrypted string.

<membership defaultProvider="CustomLdapProvider">

<providers>

<add name="ClientsADMembershipProvider" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="dc.clientsdomain.com" port="389" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" userContainer="CN=Users,DC=domain,DC=com" userObjectClass="person" userFilter="(|(ObjectCategory=group)(ObjectClass=person))" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" connectionUsername="clientsdomain\administrator" connectionPassword="SDJFSew98234DFJ889==" />

<add name="EmployeesADMembershipProvider" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="dc.employeesdomain.com" port="389" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" userContainer="CN=Users,DC=domain,DC=com" userObjectClass="person" userFilter="(|(ObjectCategory=group)(ObjectClass=person))" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" connectionUsername="employeesdomain\administrator" connectionPassword="SL43Sew982342KLSDF==" />

<add name="CustomLdapProvider" type="Project.CustomLdapProvider, Project, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8027a17523a78ae328" />

</providers>

</membership>


The partial implementation of CustomLdapProvider will be something like below:

public class CustomLdapProvider : MembershipProvider
    {
        private static LdapMembershipProvider _employeesProvider = null;
        private static LdapMembershipProvider _clientsProvider = null;
        private LdapMembershipProvider GetMembershipProvider(string providerName)
        {
            LdapMembershipProvider provider = new LdapMembershipProvider();

            // In SharePoint when your login page is coming from Layouts folder, HttpContext.Current is returning null. Hence the next line.
            //Configuration config = WebConfigurationManager.OpenWebConfiguration(HttpContext.Current.Request.ApplicationPath);

Configuration config = WebConfigurationManager.OpenWebConfiguration(@"~/web.config");
            MembershipSection section = (MembershipSection)config.GetSection("system.web/membership");
            ProviderSettings providerSettings = section.Providers[providerName];
            NameValueCollection param = providerSettings.Parameters;
            param["connectionPassword"] = Utility.Decryption(param["connectionPassword"], true);
            provider.Initialize(providerName, param);
            return provider;
        }
        private MembershipProvider EmployeesProvider
        {
            get
            {
                if (_employeeProvider == null)
                {
                    _employeeProvider = GetMembershipProvider("EmployeesADMembershipProvider");
                }
                return (MembershipProvider)_employeesProvider;
            }
        }
        private MembershipProvider ClientsProvider
        {
            get
            {
                if (_clientsProvider== null)
                {
                    _clientsProvider = GetMembershipProvider("ClientsADMembershipProvider");
                }
                return (MembershipProvider)_clientsProvider;
            }
        }
// Override all the membership provider and use the appropriate Membership provider to call the overloads.
public override bool ValidateUser(string name, string password)
        {
                 // name = loginid@clientsdomain.com / loginid@employeesdomain.com
                 // Extract the domain name and based on the domain connect to the appropriate Membership Provider (EmployeesProvider, ClientsProvider) and call the ValidateUser.
                // Ex: ClientsProvider.ValidateUser(name, password)
        }
}

I am sure this will be quite useful in implementing Forms Based Authentication in SharePoint when you have to work against an LDAP Provider and do not want to compromise on the connection string.

Claims based security model in SharePoint 2010

In this article I will try to touch base briefly on the Claims based Security Model support in SharePoint 2010.

 

SharePoint comes with two kinds of authentication when you are creating a new Web Application.

1. Classic Mode Authentication (default)
2. Claims Based Authentication

 

 

Classic Mode is just the Windows based authentication and is used for backward compatibility.
The new mode of authentication i.e Claims Based works around the concept of an Identity which is based on the standards of WS-Federation, WS-Trust and Protocols like SAML (Security Assertion Markup Language)
It provides a generic way for applications to acquire identity information from users in/across organizations and also on internet.
Identity information is contained in a security token, often simply called a token. A token contains one or more claims (trusted information) about the user. This information stays with them throughout their session.

 

This is developed on the Windows Identity framework (WIF). Features of claims-based identity include

• Authentication across users of Windows-based systems and systems that are not Windows-based.
• Multiple authentication types.
• Stronger real-time authentication.
• A wider set of principal types.
• Delegation of user identity between applications. (Can resolve Double Hop issues easily)

 

Out of the box, SharePoint supports authenticating using Windows & Forms (both supported in MOSS), LiveID/OpenID. However, integrating with custom Authentication providers is easily possible as long as the application can trust the Issuing Authority of the Security Tokens.

 

Definitions of some of the concepts that you need to be aware of are as follows:

• Identity: security principal used to configure security policy
• Claim: attribute of an identity (Login Name, AD Group, etc)
• Issuer: trusted party that creates claims
• Security Token: serialized set of claims in digitally signed by issuing authority (Windows security token or SAML)
• Issuing Authority: issues security tokens knowing claims desired by target application
• Security Token Service (STS): builds, signs and issues security tokens
• Relying Party: application that makes authorization decisions based on claims

 

There are two cases of Claims Incoming and an Outgoing. The scenarios are different in the way they get authenticated or validated. See the images below from the MSDN article.

 

 

Hope this gives you a start in understanding a very high level concepts of claims based Security Model in SharePoint 2010.