PingFederate (PF) is an enterprise class web SSO solution that is built entirely on OSS (Java on Jetty) utilizing open standards (SAML 1.x and 2.0, and WS-Federation). It follows fairly closely with the Liberty Alliance model, and is partially certified for interoperability. The basic model is as follows: a user is given an SSO token by an identity provider (IDP) which is then passed to the target application and verified via a service provider (SP). Once the SP has successfully verified the token, the user gains access to the remote resource. In PF, the process is initiated by clicking on a regular old hyperlink, and is completely transparent to the end user (assuming everything goes as planned).
PF is a server solution, but development is still required. The server introduces the concept of "adapters" that act as the interface to each application. Each app that is to be made SSO aware must expose some interface (e.g. web page, .NET HttpHandler, etc.) that its adapter can communicate with via query string parameters or a cookie (configurable per adapter). The adapter's main functions are user authentication, attribute retrieval (for the security token), and session termination (for single log out). Adapters are then associated with one or more "connections" in the PF server config that act as contracts with SSO partners.
Ping promised us up front to provide integration kits and/or code samples that would ease the integration process, and once they arrived on site for the proof-of-concept, they promptly shared their .NET sample code (all of our apps are .NET based). While it certainly shed light on the overall SSO process, it was far from production worthy. All said, it took me about 75 development hours to get a stable API in place that we could reuse across all of our apps. I ended up writing a couple of providers and a few custom config sections that I think Ping was remiss for not providing themselves. However, I won't fault them completely for not doing so since their lack of exposure to .NET was obvious (their .NET sample code had comments that made references to Java, indicating that it had been literally cut and pasted).
As is required with virtually any modern server product, PF comes with a web-based administration console to handle all of the required server configurations. However it quickly proved to have a very high learning curve. I'm not sure how much of its complexity is due to the inherent complexity of SSO, but I can honestly say that I don't see any obvious ways to make it more user-friendly (but then again, that is not my area of expertise). With that said, there are more than a couple of my coworkers who still get lost in the console, even after having worked with it on several occasions.
So it's been a week since we've moved the product to production and so far so good. We had to make a few support calls along the way, and we only had one bad experience. It was at 3:00AM and the tech sounded like he was as annoyed that we called as we were at having to call. I'll give them a pass on that incident since we got our problem solved and our main support contact is exceptionally helpful (thanks Gary!).
I'll post a follow-up once we get some more distance. For now, here's the obligatory pros and cons list.
Pros:
- Standards based
- Certified by Liberty Alliance
- Generally good support
Cons:
- Sample code is not production quality
- Requires a sizable development effort
- Admin console has a steep learning curve
2 comments:
I concur with your experience.
Steep learning curve, indeed.
The whole thing humbles me, and I've been developing for years.
It doesn't bode well for them that 4+ years later, it's still every bit as frustrating to use as it was the day I wrote this post.
I feel your pain.
Post a Comment