Single Sign-On with Salesforce and Microsoft Active Directory FederationServices

IDP Overview

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

MY Domain

The Force.com 'My Domain' feature allows you to select a custom domain name for your application. A 'My Domain' URL looks likehttps://customer.my.salesforce.com/ (for a production org) or https://customer-developer-edition.my.salesforce.com/ (for a Developer Edition).

A benefit of configuring 'My Domain' is that it enables support for SP-initiated single sign-on, improving the user experience, and allowing users to access 'deep links' into their environment via SSO.

Configure 'My Domain' in Setup | Company Profile | My Domain. You will need to complete the process of configuring, testing and deploying 'My Domain' for SP-initiated SSO to work correctly.

SP Overview

In this scenario, the SP sends an HTTP redirect message to the IdP containing an authentication request. The IdP returns a SAML response with an assertion to the SP via HTTP POST.

1. A user requests access to a protected SP resource. The user is not logged on to the site. The request is redirected to the federation server to handle authentication.


2. The SP returns an HTTP redirect (code 302 or 303) containing a SAML request for authentication through the user’s browser to the IdP’s SSO service.


3. If the user is not already logged on to the IdP site or if re-authentication is required, the IdP asks for credentials (e.g., ID and password) and the user logs on.


4. Additional information about the user may be retrieved from the user data store for inclusion in the SAML response. (These attributes are predetermined as part of the federation agreement between the IdP and the SP.


5. The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.


6. If the signature and assertion are valid, the SP establishes a session for the user and redirects the browser to the target resource.

Single Sign On Setup in Salesforce with OKTA as IDP

Introduction

Okta provides single sign-on (SSO) with Salesforce.com using the industry-standard SAML protocol. Users can enjoy one-click access to Salesforce.com and any other cloud application through a graphical home page.

1. Salesforce Federation ID

1.1 Why use Salesforce Federation ID

Using Salesforce Federated ID allows another unique identifier to be used in place of the Salesforce account ID.

2. Deploying Salesforce Federated ID App

Add the Salesforce app in OKTA



•  Navigate to the Okta Administrator, click the Applications tab -> Add Applications
•  Type in Salesforce in the search bar
•  Select the Salesforce.com (Federated ID) application
•  Click the Add button.

3  General Settings

Configure General Settings.
•  Provide an application label, if the default label is unsuitable
•  Select the instance type of Production or Sandbox, depending on the type of salesforce tenant
•  Optionally determine the number of seats and application visibility



Click NEXT to Continue

4  Sign-On Options

Select the SAML 2.0 radio button. Then click the View Setup Instructions button.



Configure Salesforce SAML.
•  Log into Salesforce
•  Navigate to: Setup -> Security Controls -> Single Sign-On Settings



• From the Single Sign-On Settings
Click Edit
Check SAML Enabled
• If you have Multiple End-points enabled, the configuration page will ask to setup
Name
API Name
• Copy and paste the following from the Okta Setup Instructions.
Issuer field
Identity Provider Login URL
Identity Provider Logout URL
• SAML Identity Type - select Assertion contains the Federation ID from the User object
• SAML Identity Location – select Identity is in the NameIdentifier element of the Subject Statement.
• The Entity ID must be configured based on the Salesforce configuration.
If the custom domain, eg companyname.salesforce.com, has been configured, use the domain. EG: https://companyname.mysalesforce.com.
If a custom domain has not been configured, use https://saml.salesforce.com.
• The Service Provider Initiated Request Binding, is set to HTTP Post.
• Once configured, click Save.
After saving, copy and paste the Salesforce Login URL.



Return to OKTA Application



•  In the Federated ID SAML Parameter, set the value after ?so=. In this example it is 00d34dfg0000Tz.
•  If multiple configs have been enabled in Salesforce, select Yes in the Multiple SAML Config section.
•  If a custom Salesforce domain is used, provide that value in the Custom Salesforce domain textbox.
•  Once done, click Next.

5  USER Management

User Management must be enabled for the Salesforce.com Federated ID to work.



To enable User Management:
•  Check the Enable user management for Salesforce.com (Federated ID) checkbox
•  Provide a Salesforce user with access to the Salesforce API and the password+token for that user
•  Do not include the + between password and token, simply append the token to the password
Click the Test API Credentials.
•  If the credentials are correct, a green check mark will appear or if they are incorrect a red x will appear.
•  Once the credentials for the Salesforce API user are correct, click Next.

6  Assign To people

At this point individual assignments can be provisioned or click Next and assign to groups. Then click Done

SAML 2.0 Single Sign On Integration with ADFS and ServiceNow

Table of Contents

1. Introduction


2. SAML


3. Benefits of SAML


4. Flow Diagram


5. Prerequisites for SSO Configuration for ServiceNow


6. Request SAML 2.0 plug-in


7. Servicenow SAML 2.0 Configuration for SSO


8. ADFS Relying Party Trusts Configuration


9. ADFS Claim Rules Configuration


10. Adding User in Active Directory Users and Computers


11. Adding User in ServiceNow Instance


12. Testing


13. Workaround for login to the Servicenow instance directly

Introduction

Single Sign On (SSO)?

Is a property of access control of multiple related, but independent software  systems With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them.

• Single password used across multiple systems.


• Ability to log in once, then access many systems.


• One secure store of credentials to administer

Salesforce and ServiceNow uses industry standard SSO, i.e. SAML (Security assertion markup language)

SAML 2.0

• 
  

  SAML

Security Assertion Markup Language?

• Is a secured XML based communication mechanism for communicating the identities between the organizations.


• SAML is an acronym from Security Assertion Markup Language.


• The key thing of SAML is to eliminate the need of maintaining the multiple authentication credentials, such as passwords in multiple locations.

Key Features:

1. Security
   It increases the security by eliminating the additional credentials and number of authentications.


2. Admin
   SAML eliminates the administrative time and cost, duplicate passwords, reset of password and forget    passwords.

SAML ROLES

• Identity provider (IDP) /Asserting Party  (Authentication Mechanism)


• Service Provider (SP) / Relying Party (Target Application that provide service)


• User ( Will access the service using IDP)
  

  Benefits of SAML

• User passwords never cross the firewall, since user authentication occurs inside of the firewall and multiple Web application passwords are no longer required


• Web applications with no passwords are virtually impossible to hack, as the user must authenticate against an enterprise-class IdM first, which can include strong authentication mechanisms


• Centralized federation provides a single point of Web application access, control and auditing, which has security, risk and compliance benefits

• 
  

  Flow Diagram

• 
  

  Prerequisites for SSO Configuration for ServiceNow

• ServiceNow Instance


• SAML 2 Single sign on plugin


• Microsoft's active directory federation server (ADFS)

            Note: SAML 2 Single sign on plugin is an on demand service , we have to put a request via "                ServiceNow Hi"   portal to enable it.

• Issuer (Entity ID of IDP-ADFS), Which is also called as Federation Service Identifier.

Above highlighted Federation Service Identifier is used in SAML 2.0 Identity Provider Properties

• Token Signing Certificate from ADFS-IDP

We need to export the above token signature (PEM Cert), Which is required to import into Certificates in SAML 2.0 Configurations in Service-Now.

• 
  

  Request SAML 2.0 plug-in

Follow the below steps to configure SAML 2.0 in your setup to communicate with your Identity Provider (IdP).

1. Install the latest plug-in SAML 2 Single Sign-On.


2. After successful installation go to your ServiceNow instance and type SAML in the search bar in the navigation page.


3. All the SAML Single Sign-On modules are shown. Refer to the display below.

1. Go to the Properties module. The SAML Single Sign-On properties window is displayed

• 
  

  Servicenow SAML 2.0 Configuration for SSO

  
  

• To enable external authentication, We have check the box as shown in below, It’ll prompt us to use of ADFS user details

• Once we enable the above property, we can’t login to the servicenow directly, we have a workaround mentioned at last

IDENTITY PROVIDER PROPERTIES

• The below highlighted URL is issuer (Federation Service Identifier) from ADFS
  


• Identity provider Login URL
  


• No changes required for the below property (Leave Default)
  


• Identity Logout URL, Which is same as IDP login URL ( As per requirement, we can change this)


• HTTP Binding Option, By default it should be “Redirect”
  


• No changes required for the below 3 properties (Leave Default)
  

SERVICE PROVIDER (Service-Now) PROPERTIES

• Service provider Login URL ( Which is an Service-Now Login URL)
  


• Issuer from Service-Now ( which is an Service-Now Instance URI)
  


• Audience Token URI (which is an Service-Now Instance URI)
  


• This specifies the field in users table, that will be used to match the subject NameID in SAML assertion from IDP with ServiceNow user table
  


• No changes required for the below 7 properties (Leave Default)
  


• Click Save

Now Click on Certificates Properties as shown below:

• Service-now requires certificate to be in PEM format. You can convert the imported certificate (As mentioned in Prerequisites) using client tools or even online tools such as: SSL Shopper. Use the DER/Binary certificate we just created and export it to “Standard PEM” format.

SSL Shopper:

1.  Login to https://www.sslshopper.com/ssl-converter.html


2.  Choose DER encoded binary X.509 (.cer)
   


3. Select DER/Binary for Type of current certificate


4.  Select Standard PEM for Type To Convert To


5.  Copy the PEM to Text editor

Copy the PEM Cert from Text editor and paste in below PEM text box which is under certificate → SAML 2.0 ( Trust Store Cert as type)

• 
  

  ADFS Relying Party Trusts Configuration

• Login to ADFS and Click on Relying Party Trusts and right click and click on Add Relying Party Trusts as shown below
  
  
  
  
  
  
  
  
  

• 
  

  ADFS Claim Rules Configuration

1. Select the Relying Party and right click to edit claim rules


2. Click on Add rule button on Issuance Transform Rules tab


3. Select Claim Rule template as “Send LDAP Attributes as Claims”


4. Specify the “Claim Rule name” and select Active Directory as Attribute Store


5. Select Email-Address as LDAP Attribute and NAME ID as Outgoing Claim Type


6. Click Finish, Apply and OK

Please check the below snap shots of each step mentioned above

• 
  

  Adding User in Active Directory Users and Computers

1. Click start and Select Active Directory Users and Computers


2. Navigate to Users tab and Right click-->New-->User


3. Input FirstName and LastName and User Logon Name(salugu@domain.com)


4. Click Next and Input Password and Select Password never expires


5. Copy the user logon address


6. Click finish and Double click on User


7. Past the copied Login email address in email field


8. Apply and Click OK

• 
  

  Adding User in ServiceNow Instance

1. Log on to your ServiceNow instance


2. Application Navigation->Systems and Security->Click Users


3. Click on New button and Create a new user and Input email address copied earlier(salugu@domain.com)


4. Save

• 
  

  Testing

  
  IDP Initiated Authentication:

1. Hit ADFS logon URL(https://your adfs domain/adfs/ls/idpinitiatedsignon.aspx)


2. Select your Relying party and Proceed


3. Input ADFS user credentials and Proceed


4. You should be able to logon to ServiceNow

• SP Initiated Authentication:

1. Hit ServiceNow Instance logon URL(https//<Your Instance>.service-now.com/navpage.do)


2. Select your Relying party and Proceed


3. Input ADFS user credentials and Proceed


4. You should be able to logon to ServiceNow

• 
  

  Workaround for login to the Servicenow instance directly

• Bypassing external authentication-ADFS

Once we Enable External Authentication  and Configuration of  SAML 2 Single sign on plugin as shown above, Users will not be able to login to the ServiceNow instance by usual login URL(https://demo.service-now.com). Single sign on settings prevent users from logging into ServiceNow instance instance directly without ADFS login.

To overcome from the above issue, we have a below workaround.We have to use the below mentioned URL:

http://.service-now.com/side_door.do

Administrators can use the following URL to bypass external authentication and log in with a local ServiceNow user