AD/SSO Authentication in Salesforce
Abstract:
As resources move to the cloud, users experience a proliferation of credentials - the usernames, passwords and, sometimes, devices they use to log in (or authenticate) to cloud-based services. Single sign-on technologies come to the rescue, allowing users to authenticate at a single location and access a range of services without re-authenticating.
SAML 2(Security Assertion Markup Language).configure single sign-on for SalesForce using ADFS 2.0. This is a really nice solution because it’s easy to set up and doesn’t cost you anything except the Windows 2008 OS license
ADFS 2.0 is Microsoft’s answer to federation – it includes their own implementation of SAML 2.0. It runs on Windows Server 2008 and is installed from a separate downloadable package.
1.SSO Authentication:
Single sign-on (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications.
The service authenticates the end user for all the applications the user has been given rights to and eliminates further prompts when the user switches applications during the same session.
Single Sign-On is a process that allows network users to access all authorized network resources without having to separately log into each resource. Single Sign-On also enables your organisation to integrate with an external identity management system or perform web-based single sign-on to Force.com. Single Sign-On enables multiple types of authentication integration, but the most common are:
- Use an existing directory of user names and passwords, such as Active Directory or LDAP, for Salesforce users
- Allow seamless sign-on to Force.com applications, eliminating the need for explicit user log on actions
1.1.How Single Sign-On Works
- When a user tries to log in—either online or using the API—Salesforce validates the username and checks the user’s profile settings.
- If the user’s profile has the "Uses Single Sign-on" user permission, then Salesforce does not authenticate the username with the password. Instead, a Web Services call is made to the user’s single sign-on service, asking it to validate the username and password.
- The Web Services call passes the username, password, and sourceIp to a Web Service defined for your organization. (sourceIp is the IP address that originated the login request). You must create and deploy an implementation of the Web Service that can be accessed by Salesforce.com servers.
- Your implementation of the Web Service validates the passed information and returns either "true" or "false."
- If the response is "true," then the login process continues, a new session is generated, and the user proceeds to the application. If "false" is returned, then the user is informed that his or her username and password combination was invalid.
1.2.Options for Implementing SSO on Force.com:
Delegated authentication
Using delegated authentication, Force.com does not validate passwords but instead uses an external Web service to validate user credentials. When a user attempts to log in, the platform checks the user's profile to see if they are enabled for SSO. If so, it makes Web services call to the endpoint specified by the organisation (environment), asking it to validate the username and password.
Federated Authentication
As with delegated authentication, federated authentication does not validate the user's actual password on the Force.com platform either. Instead, the platform receives a SAML assertion in an HTTP POST request. The SAML assertion has a limited validity period, contains a unique identifier, and is digitally signed. If the assertion is still within its validity period, has an identifier that has not been used before, and has a valid signature from a trusted identity provider, the user is granted access to the application.
1.3.Open-source software project that provides SAML
- Shibboleth
- etc...
1.4.Benefits of Implementing SSO
- Improved productivity - Not having to enter a password each time a user needs to access a resource saves time and makes users more productive
- Increased adoption -SSO reduces the barriers to use for resources. Since it is easier to access applications, users will start using them more.
- Centralized user access control -
- Improved reporting and monitoring - A single repository for auditing and logging access to resources provides streamlined regulatory compliance.
- Increased security - secure, enterprise-wide infrastructure with common password and security policies that can be centrally managed and secured
- Uniform security layer -SAML is platform agnostic allowing enterprise architects to implement a uniform security layer with existing assets.
- Reduced helpdesk costs -.
2.Active Directory
Active Directory (AD) is a directory service that Microsoft developed for Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services.
3.AD/SSO Authentication
Now it is possible to configure a seamless single sign-on experience from a Microsoft environment to Force.com (and hence other salesforce.com products) without a third-party federation product. Starting with Windows Server 2008, however, Active Directory became an umbrella title for a broad range of directory-based identity-related services.
salesforce.com introducing support in the Winter '09 release (October 2008) and Microsoft in Active Directory Federation Services (AD FS) version 2.0
3.1.Overview
SAML 2.0 defines several roles for parties involved in single sign-on:
The user authenticates (logs in) to the identity provider (or IdP) - in our case, this will be AD FS 2.0. The user is then able to access a resource at one or more service providers (abbreviated as SP, and also known as relying parties) without needing to log in at each service provider.
The diagram below shows the process for an IdP-initiated login into SalesForce – later we’ll look at SP-initiated login.
- The user authenticates to the ADFS server using Kerberos and requests login to SalesForce
- ADFS returns a SAML assertion to the user’s browser
- The browser automatically submits the assertion to SalesForce who logs the user in
Configuration
To build a federation between two parties we need to establish a trust by exchanging some metadata. The metadata for our ADFS 2.0 instance is entered manually into the SalesForce configuration. SalesForce metadata is downloaded as an XML file which ADFS 2.0 can consume.
Summary
Applications running on the Force.com platform have access to SAML 2.0 cross-domain Web single sign-on, as does Microsoft Active Directory Federation Services 2.0. We can configure the two systems to enable seamless SSO from the Windows desktop to Force.com without the need for any additional third-party products.
