Category: Salesforce

SSO to Salesforce.com

James, my partner in crime had recently asked about features in federation products. I want to leave out the comparison part to analysts and customers since it’s very much depend on the end use case.

However (getting a bit specific), I was recently in a conversation on ‘why should the customer use PingFederate instead of a home grown solution to do SSO to Salesforce.com’ (SSO to Salesforce.com was the big focus for PingFederate’s latest release in September). Here are some of the reasons I came up with:

  • Multiple access methods for Salesforce.com
    • SP-Initiated SSO via Direct Logon: The user navigates directly to Salesforce.com, enters a corporate email address and password, and is authenticated via the PingFederate Authentication Service.
    • IdP-Initiated SSO: The user logs on to an Identity Provider (IdP) application integrated with PingFederate. By clicking a specific URL that goes through PingFederate, the user can SSO to salesforce.com. The admin can choose to deploy this use case using either Delegated Authentication or SAML.
    • SP-Initiated SSO via “Deep Linking”: The user clicks a link in an email to a Web page inside salesforce.com, which sees that this user has performed SSO previously and redirects the user to the IdP for authentication. After logging on, the user is redirected back to salesforce.com—to the “deep link”, rather than the default home page.
    • SP-Initiated Single Logout (SLO): The user is logged on to salesforce.com and wants to log out of both salesforce.com and the IdP application. Upon clicking the logout link, the user is also logged out of the IdP application.
  • Outlook Access via the Rich Client Proxy Service: The user is using the Microsoft Outlook plug-in that Salesforce develops and maintains. The plug-in stores the user’s corporate email and password, which are used to authenticate to the corporate LDAP directory via a Rich Client Proxy service. The user’s salesforce.com data synchronizes with Outlook; thus, by using PingFederate, the corporate credentials are not transmitted outside the firewall.
  • Works with existing infrastructure: PingFederate provides out-of-the-box integration with a number of authentication and enterprise identity systems including Integrated Windows Authentication (IWA), LDAP authentication, CA Siteminder, Oracle Access manager, BEA Weblogic etc. You can find the up-to-date list of supported systems here.
  • Automated account provisioning: Administrators create a group or filter to contain all Salesforce.com users in the existing corporate directory. As changes are made to user accounts in the corporate directory, PingFederate automatically replicates each change to Salesforce.com via the Salesforce.com provisioning API.
  • Proven architecture: Over 30 customers are using PingFederate for SSO to Salesforce.com including Cox Media, Rearden Commerce, Cognos, LandAmerica and many others.
  • Rapid Deployment: PingFederate can be setup for SSO to Salesforce in a matter of days. The latest release of PingFederate bundles a quick-connection template for Salesforce.com that automatically configures many of the settings required for Salesforce SSO as well as provisioning in the PingFederate administrative console.
  • Standard/Independent server to manage SSO: Adding another SSO partner (internal or external) is as simple as adding a connection within PingFederate console. Other than Salesforce.com Delegated Authentication Protocol, PingFederate supports SAML 1.0, 1.1, 2.0 and WS-Federation.

Expect a call from our sales team, James :-) .

DIDW 2008 Slides

Here are the slides from our DIDW presentation on ‘Identity enabling Web Services‘.The use cases revolving around browser-SSO are getting a lot more clear and straightforward. And hence the discussions around ‘API/Web Services’ access seems like the next logical step. Enterprises are slowly but steadily moving towards the ‘Service Oriented Architecture’. And more companies are entering the Consumer and/or SaaS space storing user’s data in the cloud; which brings the implicit requirement of enabling access to the data via an API.

Identity Enabling Web Services

View SlideShare presentation or Upload your own. (tags: google salesforce)

OAuth vs WS-Trust/WS*

I moderated a session at the recent SSO Summit titled “What is OAuth and WS-Trust, and where does it fit into your web services SSO initiatives“.

User-centric identity” is past-its-prime and “Identity as a Service‘ has already been beaten enough. And hence I was glad to get a chance to dig into the services/API use cases (some of the which are very complementary to the browser SSO use cases).

Here are some of the scenarios that we discussed:
(Eve was the scribe…so I’m hoping  she has better notes).

  • Server-2-Server mashup – User goes to travelsite.com and books his flight. And expects the travel site to make an API call and add an event to his Google Calendar.
  • Enterprise SOA  – An enterprise had a legacy/maiinframe system. An overpriced consultant convinced them to put an SOA layer in front and expose the functions via a web application. The user logs in the web application (SSO or otherwise), makes an API call to the SOA layer and the system requires the call to be ‘identity enabled’ for security as well as audit purposes.
  • SSO + Data (User present) – User login to flight.com. Books his flight. SSO to hotel.com. Hotel.com has the username but requires the flight information – dates etc (transient data) to auto-populate the reservation fields. Hotel.com makes an API call back to flight.com to retrieve the data.
  • Desktop Client – SaaS vendor (think Salesforce etc) has a web front, which the customer uses to access their data. The SaaS vendor also makes the data available via an API (which can then be leveraged via an Outlook or Eclipse plug-in or a mobile version). SAML handles the browser based SSO use cases but the it gets tricky for desktop based clients when there is no browser present. The consumer equivalent of this will be TurboTax or MS-Money, which currently ask the users to enter their FI credentials to allow them to retrieve data on user’s behalf.

The OAuth vs WS-Trust/WS* has many similarities to the OpenID vs SAML debate. Much like OpenID, OAuth was started in the consumer centric world. Both the protocols boasts to be light weight, focus on limited set of use cases and does it very well. SAML as well as WS-Trust/WS* have roots in the enterprise world, require an engineering degree to be able to understand the specs but they are much ahead in terms of maturity and have gone through many security reviews.

However, in the case of OpenID / SAML, there seems be to a resting state -  OpenID is the front-runner in the blog/consumer/social networking space (MySpace, Orange recently announced support for it) and SAML is the defacto in the enterprise as well as SaaS space (Google, and recently Salesforce announced support for SAML).

In the case of OAuth/WS-Trust, it’s a little less clear. OAuth seems to have a lot of traction in the consumer space (twitter, flickr, pownce etc). WS-Trust/WS* has better adoption in the conventional enterprise web services/ SOA space. However, the enterprise SaaS space is still open. The likes of Google Apps are trying to merge the lines between the consumer and the enterprise market. Google GData API recently announced support for OAuth (it supports SAML for browser SSO). And hence an enterprise with a traditional SAML/WS-Trust/WS-* infrastructure may be tempted/required to have OAuth support to access their data. Or they may ask their SaaS vendors to enable their APIs with WS*.

It’s getting Cloudy

Cloudy

  • Persistent Storage for Amazon EC2: This new feature provides reliable, persistent storage volumes, for use with Amazon EC2 instances. The volumes will be significantly more durable than the local disks within an Amazon EC2 instance. Additionally, our persistent storage feature will enable you to automatically create snapshots of your volumes and back them up to Amazon S3 for even greater reliability.
  • Google App Engine: Google App Engine lets you run your web applications on Google’s infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it’s ready to serve your users.
  • Arcot announced A-OK On-Demand Solution: Arcot Systems announced that its A-OK On-Demand solution is available for immediate use. This is a multi-factor authentication solution for Web-based, on-demand applications. The tool addresses the burning issue of stolen passwords with on-demand applications
  • Google, Salesforce link up for business apps: The companies on Monday announced that Salesforce.com’s customers now have the option of using versions of Google Apps, Gmail, Calendar, and Google Talk that are tightly linked to Salesforce.com. Google is in effect becoming Salesforce’s productivity suite. Google documents, spreadsheets, and presentation can be created from within Salesforce’s CRM application. GTalk works as the de facto instant messenger within Salesforce.
  • TriCipher Acquires Sxip User Manager: The AppExchange-certified solution, which will be re-named myOneLogin User Manager, is the only way Salesforce.com administrators can centrally enable and disable user access to both Salesforce.com and Google Apps from within the Salesforce.com application.

Image | WordPress Themes