Identity Providers

The following section details information for some common Identity Providers.

Important: If your Identity Provider is not listed, please contact Philanthropy Cloud Support to schedule an appointment to configure your SSO connection.

Note: You can select in the toolbar to access documentation, support, and release information. You can also provide feedback for Philanthropy Cloud.

SSO Using Okta as the Identity Provider

In Okta, start by creating a SAML application. Complete the following information:

• Platform = Web

• Sign on Method = SAML 2.0

• Enter an app name that will be clear to your users

• Upload a logo (Optional)

• Single Sign-on URL (temporary) = https://temporary.com

• Audience URL = https://www.philanthropycloud.com

• Name ID format = Unspecified

• In the Attributes Statements, add the following

  • Name = FederationID

  • Value = user.email

Once created, download the metadata XML file from Okta and send the file to your Philanthropy Cloud support representative. Your representative will create the SSO connection in Philanthropy Cloud and then send you the SSO URL, which you can then update in your application in Okta. You can then assign users in your application in Okta that you wish to enable SSO access for Philanthropy Cloud.

Important: To enable SSO for your organization, please contact Philanthropy Cloud Support. You will be assigned a representative to coordinate the process.

Note: You can select in the toolbar to access documentation, support, and release information. You can also provide feedback for Philanthropy Cloud.

SSO Using Ping as the Identity Provider

In Ping, start by creating a new SAML application. Complete the following information:

• Applications → Add Application → New SAML Application

• Select your certificate

• Download SAML Metadata for Ping and provide this file to your Philanthropy Cloud representative

• Select SAML 2.0 for the Protocol Version

• ACS URL (temporary) = https://temporary.com

• Entity ID = https://www.philanthropycloud.com

• Add a new attribute mapping

• Name it FederationID and give it a value of the user email

• Save & Publish

Your representative will create the SSO connection in Philanthropy Cloud and then send you the ACS URL, which you can then update in your application in Ping. You can then assign users in your application in Ping that you wish to enable SSO access for Philanthropy Cloud.

Important: To enable SSO for your organization, please contact Philanthropy Cloud Support. You will be assigned a representative to coordinate the process.

Note: You can select in the toolbar to access documentation, support, and release information. You can also provide feedback for Philanthropy Cloud.

SSO Using Azure as the Identity Provider

Basic Edition Implementation

Azure AD Free and Basic editions do not support an Identity Provider-initiated single sign-on flow, only a Service Provider-initiated single sign-on flow.

In Azure AD, start by creating a SAML application.

Complete the following information by editing the Basic SAML Configuration with the following:

• Identifier (Entity Id): https://www.philanthropycloud.com

• Reply URL (Assertion Consumer Service URL): https://login.philanthropycloud.com/login?so=00D1I000000lJqw

• Sign On URL: https://login.philanthropycloud.com

To customize the claims, refer to this document.

Once created, download the metadata XML file from Azure AD and send the file to your Philanthropy Cloud Support representative. Your representative will create the SSO connection in Philanthropy Cloud.

You can then assign users in your application in Azure AD that you wish to enable SSO access for in Philanthropy Cloud. You can also set a default Standard User Role to the user.

Premium Edition Implementation

Azure AD Premium edition supports both Identity Provider and Service Provider-initiated single sign on flows.

In Azure AD, start by creating a SAML application.

Complete the following information by editing the Basic SAML Configuration with the following:

• Identifier (Entity Id): https://www.philanthropycloud.com

• Reply URL (Assertion Consumer Service URL): https://login.philanthropycloud.com/login?so=00D1I000000lJqw

To customize the claims, refer to this document.

Once created, download the metadata XML file from Azure AD and send the file to your Philanthropy Cloud Support representative. Your representative will create the SSO connection in Philanthropy Cloud.

You can then assign users in your application in Azure AD that you wish to enable SSO access for in Philanthropy Cloud. You can also set a default Standard User Role to the user.

Important: To enable SSO for your organization, please contact Philanthropy Cloud Support. You will be assigned a representative to coordinate the process.

Note: You can select in the toolbar to access documentation, support, and release information. You can also provide feedback for Philanthropy Cloud.

Active Directory Federation Services

Active Directory Federation Services (ADFS) is a SSO solution created by Microsoft. As a component of Windows Server operating systems, it provides users with authenticated access to applications that are not capable of using Integrated Windows Authentication (IWA) through Active Directory (AD). ADFS allows organizations to control their employees’ accounts and enables employees to only have to remember a single set of credentials to access multiple applications through SSO.

Before You Get Started

• Have a place to take notes and jot down URLs and key information.

• Place the SAML metadata file that you received from Salesforce.org Customer Support in a place that you can retrieve it from your ADFS server during your SSO configuration.

ADFS Identity Provider Configuration

1. From Windows Administrative Tools, open the ADFS Management Console.

2. Record your SAML endpoints to provide to Salesforce.org Customer Support. Items in bold should be recorded in your notes and provided to your Salesforce.org Customer Service Representative.

   • Navigate to Service > Endpoints and locate the Endpoint with Type equal to SAML 2.0/WS-Federation (e.g., /adfs/ls). Combine this with your Federation Service Name to create your SAML Identity Login URL (e.g., https://corp.yourcompany.com/adfs/ls).

   • Right click the root ADFS directory and Edit Federation Properties to see your Federation Service Name, which is your root URL (e.g., corp.yourcompany.com).

   • Also on the Endpoints page, find your Federation Metadata URL. Combined with your Federation Service Name, this is your Federation Metadata URL (e.g., https://corp.yourcompany.com/FederationMetadata/2007-06/Federation Metadata.xml).

3. Download a copy of your Token-signing Certificate.

   • In the Certificate Export Wizard, choose DER encoded binary x.509 format.

   • Select the Details tab and click Copy to File. This is a certificate export.

   • Right click the certificate and select View Certificate.

     • In the ADFS Management Console, navigate to Service > Certificates and locate the Token-signing Certificate marked as Primary.

     • Select a location where you can retrieve the primary Token-signing Certificate to email to your Salesforce.org Customer Support Representative.

4. Create a Relying Party Trust.

   • Select the users you wish to access Philanthropy Cloud via SSO. Note: If you choose not to Permit Everyone, you will have to maintain user access in your Active Directory.

   • Choose a Display Name for your users (e.g., Philanthropy Cloud) and click Next.

   • From the Select Data Source step, choose to Import data about the relying party from a file. Locate the file location and choose the metadata file provided by Salesforce.org Customer Support. Click Next.

   • In the ADFS Management Console, click the Relying Party Trusts folder and in the Actions pane, select the action to Add Relying Party Trust. This will start a step-through wizard.

   • Click Next from the Ready to Add Trust, select the option to add claims, and click Finish.

5. Add Claims Provider Trusts.

   • From the table, select E-Mail-Addresses as an LDAP Attribute and Name ID as Outgoing Claim Type and click Finish. Click Apply and OK from the Claims Issuance Policy screen.

   • Choose Active Directory as an Attribute Store.

   • Name your Claim Rule (e.g., Email as Name ID in Subject).

   • From the Claim Rule Wizard, choose to add a Transform Claim Rule. Select the Claim rule template of Send LDAP Attributes as Claims and click Next.

   • If you weren't taken directly to adding Claims from Step 4, navigate to your newly created Philanthropy Cloud Relying Party Trust and right click to Edit Claim Issuance Policy.

   • From the Relying Party Trusts folder, right click your newly created Philanthropy Cloud and select Properties. Ensure that the certificate in the Signature tab matches your primary Token-signing Certificate from Step 3 above.

6. Send the document where you recorded your SAML Identity Login URL, Federation Metadata URL and attach the Token-signing Certificate to your Salesforce.org Customer Support Representative by email.

7. Next step - Testing! Your Salesforce.org Customer Support Representative will be in touch to setup a workshop call to test.

Important: To enable SSO for your organization, please contact Philanthropy Cloud Support. You will be assigned a representative to coordinate the process.

Note: You can select in the toolbar to access documentation, support, and release information. You can also provide feedback for Philanthropy Cloud.