Ping Federate is a third party vendor which provides capabilities for Single Sign On (SSO) using either SAML or WS-Federation protocol. I recently worked on a project where we had to provide this capabilities to applications.
Here I document how I achieved this through SAML protocol.
SAML stands for Security Assertion Markup Language and it is an open-standard data format for exchanging information related to authentication and authorization (Source-Wikipedia – SAML ). SAML is used mostly for web browser SSO.
Ping Federate plays the role of an Identity Provider or Service Provider depending on what purpose you are using it for.
In this particular post, we will be seeing how a SP initiated SSO works with Ping Federate.
Here are the steps –
Create a SP connection in Ping Federate –
Create a unique connection for your SP service in Ping Federate, this unique connection will be identified by Ping Federate with Entity Id which you will create in Ping Federate. Provide an Assertion Consumer Service (ACS) URL in your connection in Ping Federate. Basically Ping will send a response back at ACS URL. There is a step by step process to create a SP connection in Ping Federate.
You will need to specify a protocol to be used for this connection. For our post purposes, we are using SAML 2.0. What kind of binding can be used? Post, Redirect, Artifact, SOAP. For this post, we will be using Post or Redirect.
During the process, you also provide an IdP adapter in the connection. IdP adapter is nothing but the way of authentication – how do you want an user to be authenticated? Through an HTML form or Windows Account? .
You will also need to provide a signing certificate if you are going to send a signed login request to Ping Federate.
Once you create a connection, you set that connection as ACTIVE in ping.
Changes on SP Side –
Now when you send a Login request to ping, it will be posted on the protocol endpoint URL from ping side. So Ping provides certain static endpoints for your connection. If Ping is installed on a server called abc.com , the endpoint for Ping will be abc.com/idp/SSO.saml2 and this is where you will post your login request. Here is a sample Login request looks like
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_bec424fa533dj2ff020502892fghjjf221" Version="2.0" IssueInstant="2016-02-10T11:39:34Z" ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://abc.bloodycoders.com/login/saml2/sp/AssertionConsumerService.php">
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" SPNameQualifier="abc.bloodycoders.com" AllowCreate="true" />
<samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact">
Ping Federate will verify the request based on entity id and where the response to be sent. If the request is valid, it will be send a response. On SP side, you then verify the response if it is coming from an authentic source.
(I have not included response back from Ping Federate for post purposes).