While SSO remains a crucial part of our daily multiple application access, we need to decide which type of SSO Implementation is best suited for our company. Depending on whether your Organization is a Call Center (where agents need to pull all Customer Information including last bill payment, government information to authorize the party, maintain conversation history), Finance Industry (Enterprise Business Suite, Quotes need to be integrated yet loosely coupled with CRM On Demand) to get the forecasts, accurate and timely opportunity details, leads and contacts, we can implement SSO using different Implementation strategies. SSO can be implemented for various industries including medical for concurrent access of critical applications.
Snapshot of SSO Implementation
SAML when implemented in conjunction with any of the Integration KITs will allow Single-Sign On between applications including CRM On Demand. How the integration takes place for Single-Sign On is, the security token on the network is passed between the clouds to allow only authorized users to enter between applications and to redirect the unauthorized users to a custom redirect page.
Multiple levels of security can be provided to ensure critical organization details and applications cannot be accessed from any other means except authorized users using required credentials. It is much easier to access multiple applications using SSO. The need to maintain different userids and passwords along with the constant hassle of losing and regenerating password consumes time and is frustrating. These are all reasons SSO is needed in fast paced organizations.
How I set up Single-Sign On from CRM On Demand to E-Business Suite
The following three step process helps you to connect any system to CRM On Demand and authenticate via LDAP
You could prioritize what you want to configure as per your requirements. Since, I already had all information in hand, I followed these steps to configure CRM on Demand with an external application, which in my case was Oracle E-Business Suite.
Configure the Service Provider in Ping Federate. Download and install Ping Federate from Ping Identity if you’ve not done so already, start the server and visit the Admin Console page to modify Service Provider on the right corner.
Next, configure IWA (Windows Active Directory) for authentication mechanism. If you have not done so already, download the IWA Windows Authentication KIT from Ping Identity and configure your LDAP to work with IWA by following the manuals. It’s free and relatively easy to use.
Hostname(s) - Hostname will be the IP address of the computer (local or remote computer) where the active directory is hosted.
LDAP Type - LDAP type in my case was Microsoft Active Directory, residing on remote computer. If you want to just try it out on local computer, you can do so and use OpenDS or other Sun Active Directories which are free for trial.
Bind Anonmously - Should not be checked. The idea is to authenticate with a parameter/ credentials.
User DN - User DN is the Domain\user name. Do not type the username alone and try connecting. The system will not let you through until you include entire userid how it was created in LDAP. Log into LDAP independently and verify the userID and password.
Use SSL - Initially I did not check SSL option. Verify your login without SSL and later you can try SSL
After you’ve configured the Data Store, follow the steps to integrate with Windows Active Directory. I’ve used Microsoft Active Directory residing on a remote machine.
We have configured the Service Provider, now it’s a matter of providing your IWA details and fill the GAPs in the SP SAML Connections section to enable Single-Sign On. Make sure you run the scripts to configure IWA with the keystore internal to the Ping Identity or this won’t work.
What happens in this three step process is that you first configure the SP Connection using SAML. Make sure that your application is configured and is SAML -enabled*. If not enable SAML on your application side. Then configure an authentication provider like Windows Active Directory to work provide Credentials. Once the user is authenticated, the Token is passed automatically within Ping Federate to enable the Service Provider to access their application. The SP could be your timesheet from the E-Business Suite to any Quotes or data you have in your EBS system. You can add as many SP as you want to integrate with CRM On Demand.
Now you know how to integrate from a Single point and access all of your applications including EBS.
Blog author: Aarthi Sitaraman
Aarthi is a contributing blog author on the Web Technical Services Practice Team at Biztech.