Ping Federate is a third party vendor that 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 these 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 an SP-initiated SSO works with Ping Federate.
SSO with Ping Federate-
Create an SP connection in Ping Federate –
Firstly, 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 an SP connection in Ping Federate.
You will need to specify a protocol for this connection. For our post purposes, we are using SAML 2.0. What binding to use? 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 a way of authentication – how do you want a 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 post on the protocol endpoint URL from the 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">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
urn:mace:bloodycoders.com:services:abc.bloodycoders.com
</saml:Issuer>
<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">
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
Ping Federate will verify the request based on entity id and where it needs to send the response. If the request is valid, it will send a response. On the SP side, you then verify the response if it is coming from an authentic source.
(I have not included a response back from Ping Federate for post purposes).
If you enjoyed this post, send me a response here.
