The dilemma in understanding technology has always been considering the various options that we have. In considering SSO (Single Sign On) for our organization we had to understand the two allowed methods in Salesforce which are Delegated Authentication and Federation ID. Having considered both options we found that there are pros and cons for both systems of implementing Single Sign On which is worth discussing. I hope this will be helpful for those who wish to implement SSO for their organizations.
Delegated Authentication
We created a Google App that runs on Google App Engine. The Google App is a link to host SSO login and authentication. Like all other Google Apps, it requires for the users to login to Google using their email and password. Once the user is authenticated, Google App Home page will display the landing page to start the authentication process. This page will have a link to Salesforce. This link is an auto form submit link to your salesforce login page. Clicking on the link will submit the form that contains your Gmail username as your username for Salesforce and a dynamic token will be generated as your Salesforce password. After submitting the form to Salesforce, Salesforce Delegated Authentication takes over. If the user is "Is Single Sign On" enabled, delegated authentication will send a soap type request from Salesforce to your Google App link specified in the delegated authentication gateway.
Once the request has been received, Google App will check the username and password if it is the correct username and password that was submitted in the automatic link. The password is a dynamically generated token from the login link page. This whole process should be completed in less than 2 minutes. Once the token is checked againts the the secret format the response is sent to salesforce.
The response to Salesforce is soap type response with the Authenticated value set as true or false. If the response is false the user will get a message indicating that the Authentication Provider is down or not responding. If the response is true, a new session is created and the user logs into Salesforce.
Advantages of Google App Delegated Authentication
1. The link to login is secured. It is not open to the Internet. Therefore there is no threat from hackers. Furthermore, it is managed by Google's internal security. (I guess we can be rest assured!)
2. The is no possbility for Phishing attacks.
3. No need for any on premise server or hardware maintenance. Basic advantage of cloud computing.
4. The Google App Engine hosting limits are very generous at the moment. This may be considered as an advantage now but in time it may be a disadvantage. Please the section below for more information.
5. Central location to manage all other cloud application that support delegated authentication.
Disadvantages of Google App Delegated Authentication
1. Google currently has limits on the number of accesses, bandwidth and etc. It is impportant to note the limits as it may be become a show stopper. Please follow this link for more information.
2. There is no option to dynamically manage users. It requires users to be managed in 2 locations. Each time a user is created or information is updated, it has to be manually maintained in both locations.
3. The response is limited to true or false only. It would be advantageous to have multiple responses that cater for more options such as SSOstart loginURL and logoutURL specifications.
Additionally, this service can be easily accomplished using an on premise service. However, for the purpose of discussion we have chosen to use the Google App Engine to deliver this requirement.
Delegated Authentication Implementation
Please follow this link to see the Salesforce example of how to create a Google App on Google App Engine to manage the Identity Service provisioning.
Federation ID
Federation ID is the unique name that used to identify the user in both systems. It is stored in the User object of Salesforce along with the Salesforce username. The use of Federation Id requires an on premise implementation of a Web server that is exposed to the web. The Web server must have the SSL signature so that the communication between Salesforce (Service Provider) and the SSO web server (Identity Provider) is secured. The reason why Federation Id cannot be implemented on Google App Engine is because of the use of Certificate Authority. Google provides a generic HTTPS URL for all Google Apps. In the SAML (Security Assertion Markup Language) requirements is clearly requires a CA public key to be uploaded to Salesforce.
Unless there is a solution for SSL Certificates to be installed for each Google App for Domain separately it wont be possible.
Advantages of an on premise Identity Server
1. The user can login directly on Salesforce login page. The user authentication will be sent to the Identity Provider and seamlessly login to the Service Provider.
2. The user information and creation can be managed in one location. In the SAML service, JIT (Just In Time) response and requests allows for updating and managing users in one single location.
Disadvantages of an on premise Identity Server
1. On premise implementation, requires maintenance and uptime reliability.
2. Open to hack attacks. The on premise web server must be made available on the internet for Salesforce to connect, that creates a potential avenue for attack.
Federation ID Implementation
Any web server application can implement Federation ID. There are many samples of Java Portals and PHP apps serving as Identity Providers. Microsoft AD server with ADFS 2.0 can act as the Identity Provider too. This link has a very comprehensive description of how to implement SSO with MS AD.
Conclusion
Our primary focus is cloud solutions. Therefore it is clear that Delegated Authentication was most suited. However, we are very much in-favor of the features available in SAML such as; JIT and direct login on the service provider. We are hoping to have some solution soon so that the user adoption rates would be much more encouraging. Please post your comments or corrections.
Kana Sabaratnam
Technical Director
Lava Protocols
