Category: federation

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 :-) .

Concordia Slides from RSA

SlideShare | View | Upload your own

Slideshare doesn’t handle animation very well. So here is a run-down on the final demo.

In addition to demonstrate inter-operability with other vendors, I was able to show how to login to Google Apps, using SAML IdP/Infocard RP from Ping, CardSpace from Microsoft and an information card from Sun. In terms of platforms, Sun’s server was running on OpenSolaris, Ping’s on Linux, CardSpace on Windows XP (which in-turn was running on Mac OS X) and Google’s on ‘whatever they run over there’.

Identity at RSA

I’ll be at RSA Conference next week participating in the following events.

Concordia
What: The current goal is to demonstrate that SAML, WS-Fed and Information cards can co-exist and some of use cases where it makes sense. For instance, if you already have a federation setup (using SAML or WS-Fed), you can leverage Information Cards as an authentication mechanism and tighten the security. Similarly if you are planning on authenticating using an Information Card, you can extend the reach (and hence get more value for your investment) by federating using SAML/WS-Fed.
Who: Fugen, Internet2, Microsoft, Oracle, Ping Identity, Sun, Symlabs.
When: April 7th, 9AM-12:30 PM
Where: Red Room 302, Moscone Center North/South, Esplanade level

OSIS
What: This is an interop event where you will get to see most (if not all) of Information Card as well as OpenID providers and consumers. What started off as an informal interop session at IIW, now has 57 participants. A lot of credit for this goes to Mike, Dale and Pam for continuing to encourage (read harass) other participants.
Who: 33 Companies. 24 Projects. 57 Participants.
When: April 8th, 9th. Working session 11AM-4PM. Demos: 4-6PM.
Where: Mezzanine Level Room 220, Moscone Center.

Mix-it-up
What: This has now established itself as a standard event at the main identity conferences. This is where we leave the vendor, customer, big enterprise, small company hats behind and just have a good time. Most end up getting wasted and missing out on their next day appointments.
Who: All available.
When: April 8th. 6-8 PM (it’s not really going to end at 8).
Where: 111 Minna Gallery (Tel: 415.974.1719).

See you there.

Love.Federation.Cello Tape.Collaboration…and Viagra

Borrowing from one of Dick’s presentation – federation needs to become a Viagra solution (i.e. giving more powers) and not just a painkiller (i.e. solving an immediate pain). More and more enterprises are accepting the SaaS model and outsourcing their key business data and functions. Security is an obvious concern for all of these SaaS vendors. However, there are hardly any SaaS vendors that support standard federation protocols. And I believe one of the reasons is that they consider federation as part of a security solution (i.e. painkiller) and not something that can add more value to their business proposition. I agree with Mark and Eric that federation needs to become a cello tape and an enabler.

One more thought on the love and trust linkage. One of the fellow identerati told me this:

Identity federation is like high school sex. Everyone is talking about it. But hardly anyone is doing it. And even the ones that are doing it, are not doing it right (and not for the right reasons either).

For federation to be long lasting, there should be love. And trust.

Words out of vocabulary

Note to self; Stop using the following words while discussing identity.

  • Federation
  • Trust
  • User Centric Identity
  • Identity Metasystem
  • Claims

Update: Got a comment from Hans and I realized I haven’t provided the context here. My ‘note to self’ is after reading this and this and this and this and this and this and this and this:-) At times, we get a bit hung up on the terminology.

Zen – A Cup of Tea / Dynamic Federation

Nan-in, a Japanese master during the Meiji era (1868-1912), received a university professor who came to inquire about Zen.

Nan-in served tea. He poured his visitor’s cup full, and then kept on pouring.

The professor watched the overflow until he no longer could restrain himself. “It is overfull. No more will go in!”

“Like this cup,” Nan-in said, “you are full of your own opinions and speculations. How can I show you Zen unless you first empty your cup?”

 SAML. Meet OpenID; OpenID. Meet SAML. Introducing dynamic federation.

 

Image | WordPress Themes