Category: Ping Identity

Moving on

I have started the new year with a new employer – Symantec. I’ll be part of Symantec’s new initiative around identity.

moving

Past four years with Ping Identity had been an extremely rewarding experience. But I’m looking forward to the ‘power of yellow’. symantec

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)

Digital ID World 2008

Next week is DIDW and you are all invited to Ping’s party on Tuesday night. As always, expect a lot of fun. And lot of drinking. Hopefully, you would recover by Wednesday 3 PM for our session on ‘Identity Enabling Web Services’. I am really excited to get a chance to co-present with Eric Sachs (Google) and Peter Dapkus (Salesforce) and discuss some real world use cases revolving around API/Web service access.

picture-2.png

SignOn.com as an Auto-Connect IdP

We have just enabled SignOn.com as an Auto-Connect IdP end point. What does this mean?

If you are an SP and are interested in evaluating Auto-Connect, you can now use SignOn.com as an IdP to validate your setup.

    The short version

A few months ago, Ping Identity announced the concept of Auto-Connect. Auto-Connect eliminates the need of manual configuration for SAML connections. It relies on SAML assertion to carry user’s information but follows an OpenID style IdP discovery process; thus allowing the SPs and IdPs to connect dynamically. As an example, a user can simply type in his email address at the SP application to initiate the process, which then allows the user to SSO to the SP application via the Identity provider. To see it in action:

  • Go to SignOn.com and create an account.
  • Enable Google Apps for your account via My Account (more details here. This will give you an email address e.g. joe@signon.com.
  • Go to http://autoconnect.pingidentity.com, type in your SignOn.com email address and click ‘Sign In’.

You will be redirected to SignOn.com for authentication and then SSO to autoconnect.pingidentity.com.

    The long version

What is Auto-Connect?
Majority of the SAML implementations today require a decent amount of configuration to setup a partner connection. This includes setting up the right bindings, profiles, certs etc. This model works for a limited number of partners but has trouble scaling as the number of partners increase. A few months ago, Ping Identity announced the concept of Auto-Connect. The objective being to avoid any manual configuration and setting up partner connections dynamically. The feature is especially useful to an entity who wants to provide SSO capability to a large number of partners. A Software-as-a-Service (SaaS) provider, for example, can provide SSO to innumerable clients without specifying redundant connection information for each one. Or an enterprise that has a need to SSO to multiple outsourced services. Once the initial setup is done, adding a new partner is simply adding the partner’s domain name in the white list.

How to try it out?
If you simply want to see it in action, we have setup a demo SP application at http://autoconnect.pingidentity.com. If you want to set it up for your enterprise, use the following steps:

  • Download PingFederate from here.
  • Run through the PingFederate ‘Getting Started’ guide.
  • Set up your SP application (you can use any of the bundled sample applications as a starting point).
  • Enable Auto-Connect (configuring your metadata endpoint etc).
  • Add SignOn.com to your Auto-Connect whitelist.
  • Access the SP application and enter user@signon.com.
  • User will be redirected to SignOn.com.
  • Authenticate using userid/password or Information card.
  • User will be redirected to the SP application.
  • SP application will display the user’s attributes as specified in SignOn.com.

What happens behind the scene?

autoconnect

  • User sends a logon request with an email address to the SP application. For example: joe@signon.com.
  • The application parses the email address and sends a request to PingFederate. For example: https://sp_host.com:9031/sp/ startSSO.ping/?Domain=signon.com.
  • The SP PingFederate server looks up the domain in the Auto-Connect white list.
  • If the domain is in the list, the SP retrieves connection metadata from the IdP’s public endpoint. By default, PingFederate looks for the metadata by prepending http://saml to the domain. In case of SignOn.com, the metadata is hosted at http://saml.signon.com.
  • After validating the metadata, the SP sends an authentication request to the IdP’s SSO service.
  • PingFederate IdP server at SignOn.com verifies the domain name of the requester.
  • The IdP retrieves the SP’s metadata via its public endpoint and verifies the metadata signature.
  • The IdP requests user authentication (SignOn.com supports username/password and Information Cards for authentication).
  • Once the user is authenticated, the IdP returns a signed SAML assertion to the SP’s Assertion Consumer Service (ACS) endpoint.
  • The SP logs the user on to the requested resource.

SignOn.com / Google Apps Integration

One of the reasons behind launching SignOn.com was to compare and contrast different identity protocols. There are things that you can learn by reading the specs. And then there are things that you can learn by deploying/implementing the specs.

We have had support for OpenID and Information Cards for a long time. With the latest release, we have added support for SAML by leveraging PingFederate.

Additionally, we have integrated with Google Apps. Google Apps is a service from Google that features applications for mail, calendaring, docs etc.

Google Apps

This allows SignOn.com users to

  • Add Google Apps services to their SignOn.com accounts (e.g. you can have an email address like joe@signon.com that’s hosted by Google Apps).
  • Single Sign-On to Google Apps via their SignOn.com credentials (username/password or Information cards).

Your username for Google Apps will be the same as your user name for SignOn.com. For example, if your SignOn.com username is joe, your email address will be joe@signon.com.

In order to enable your SignOn.com Google Apps Account, do the following:

  • Login to SignOn.com (register if you don’t have an existing account).
  • Go to My Profile tab and make sure that you have your firstname and lastname populated (we need this information to create your Google Apps Account).
  • Go to My Accounts Tab.
  • Scroll down and you will see ‘Partner Accounts’. Click Add. This will enable your account with Google Apps.
  • Go to the home page again. And you should see another link e.g.<username>@signon.com. Click on this and this will take you to your mailbox.
  • For the first time access, you will have to go through Google CAPTCHA to complete the registration process with Google Apps.

For future access, you can either go to your SignOn.com home page and click on Google Apps links (IdP initiated SSO).
Or you can access Google App services directly by going to the following URLs, and it will redirect you to SignOn.com for authentication (SP initiated SSO).

Appreciate any feedback.

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.

Ping Identity acquires Sxip Access

Today Ping announced the acquisition of Sxip Access business from Sxip. Chuck sent me the following picture on how he likes his coffee even more. Okay….so he didn’t exactly said that. Nor do I know if he is drinking coffee or vodka. However, I do believe that Identity for SaaS is an area that’s ready for prime time and I expect it getting a lot of traction this year. Hence I’m happy with the addition of Sxip Access to our portfolio.

chuck

MacBook Pro

I started my career writing RPG programs on AS/400. I spent majority of the past 14 years as a consultant and thus got to try a variety of platforms. Except One. Till now.

Ping Identity recently gave the option to the engineering team to pick between Windows and Mac.

In case you are wondering, the following image gives an idea on what we all opted for.

9489b70ab55692ffcac3ec776aa50a1f_img_6672s.jpg

BTW, this also means that Open letter to the Bandit team is coming :-)

Image | WordPress Themes