Credential Management

This is an important part of IT security compliance, whether it’s ISO 27001, government security standards, or requirements from the credit card industry (such as PCI DSS).

You have to have credentials secured, so that you can be sure of who uses them, especially if those accounts have high privileges. If a malicious user gets hold of them, he/she could access a database directly, ignoring the security safeguards in the application that communicates with the database.

Access control

Many people think that access control simply relates to the authentication of the user, and which groups they belong to. However, it’s likely that your application accesses other services, which require authentication.

An example is a database. Often, your application will call the database under the context of the application service account. You simply grant the application service account access to the SQL Server as a Windows login. Then grant this login the correct access to the database. Very secure, as no credentials are passed, even during authentication if the web site is internal and using NTLM or kerberos.

Problem: Managing credentials across applications within the enterprise

This is where I start writing recommendations documents, for securing these credentials. Obviously, since .Net 2.0, we’ve been able to encrypt sections of the configuration file using the command line utility aspnet_regiis.

For example, the following command encrypts the section of the Web.config file for an application named SecureApplication.

aspnet_regiis -pe "connectionStrings" -app "/SecureApplication"

But what about more complex scenarios? How about when the database model provides the granularity of access? There might be different accounts within each MySQL instance for each user! Now you have credential management for each user that logs on to the system.

Encryption of these credentials is now not possible via web.config and aspnet_regiis, as you may have many credentials to manage (perhaps one for each user?). Your web.config would end up being huge and unmanageable.

Solution: Microsoft SSO

An enterprise application in this instance is an application that will be accessed by the user, requiring different credentials. This can be a non-Microsoft application, on another operating system. For instance, the credentials for accessing a SAP system can be mapped to a specific Windows user.

Within Microsoft SSO, the enterprise application definition defines the mapping from either a group or a user to an enterprise application account.

The Microsoft Single Sign On Service integrates seamlessly with SharePoint 2007, as demonstrated in the following diagram.

The SSO encryption key server manages the key used to encrypt and decrypt the credentials, which are stored in the SSO database server.

Here's an example where the system accesses a SAP system via a BizTalk server. Here is the process:

• a call to the SSO service retrieves an SSO ticket. This ticket does not contain credentials, but rather the ability to retrieve credentials when passed to another server
• a custom SharePoint web part passes the SSO ticket to the BizTalk server
• the BizTalk server redeems the credentials from the Microsoft Single Sign on service, and uses them to access the SAP server

The credentials, secured within the SSO database, have been used by BizTalk to access another application, possibly on a non-Windows platform. The credentials have been stored securely, and have not had to be passed from application to application.

Credential management has been entirely via configuration through the Microsoft Single Sign On service.

Problem: Working across organisations

For instance, organisation A may use a web application developed and hosted by organisation B. Managing users across these organisations requires a good deal of process and monitoring, as many of the technical controls managing user access within the application are outside the influence of organisation A.

Once again, credentials need to be managed. Having different credentials for each application leads to 'post-it note' syndrome, where little yellow password reminders are pasted to every computer screen.

If only users could authenticate once, instead of for every aplication.....

Solution: SharePoint 2007 and Web SSO

With Active Directory Federation Services (ADFS), people in one company can access servers hosted by a different company by using their existing Active Directory accounts. ADFS establishes a trust relationship between the two companies without having to re-enter credentials when browsing from one web site to another.

The SharePoint 2007 tool which utilises this trust is called Web SSO.

A user can thus be authenticated to multiple Web applications during a single online session. Users are issued an authentication token (cookie) after they are authenticated. This token is then presented to the web site at the other organisation to authenticate.

By configuring the necessary trust between organisations (A and B in the section ‘Working across organisations’) via Active Directory, access to the application hosted by organisation B can be managed at an organisational level, rather than managing credentials for each user. More detail on configuring ADFS within Windows 2008 can be found here

The steps needed to configure Web SSO for a Sharepoint 2007 application are:

• enable forms based authentication

  <system.web>
    <!-mode=[Windows|Forms|Passport|None]>
    <authentication mode="Forms" />
  </system.web>

• register the SingleSignOnMembershipProvider

  <membership defaultProvider="SingleSignOnMembershipProvider">
    <providers>
     <add
      name="SingleSignOnMembershipProvider"
      type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
      fs="https://FEDERATIONSERVER/adfs/fs/federationserverservice.asmx"
     />
    </providers>
  </membership>

• Register the SingleSignOnRoleProvider

  <roleManager enabled="true" defaultProvider="SingleSignOnRoleProvider">
    <providers>
    <add
      name="SingleSignOnRoleProvider"
      type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
      fs="https://FEDERATIONSERVER/adfs/fs/federationserverservice.asmx"
      />
    </providers>
  </roleManager>

• Register the System.Web.Security.SingleSignOn.WebSsoAuthenticationModule HTTPModule

  <httpModules>
  <add name="Identity Federation Services Application Authentication Module" type="System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null" />
  </httpModules>

This is all enabled within web.config

The benefit here is that a trust relationship between two organisations can be integrated into the authentication model for SharePoint applications via configuration, rather than development work.

Summary

For further detail on these technologies, this document gives all of the necessary configuration information for using both flavours of SSO within SharePoint 2007: