From Realty IDP to Google Apps for Business (via Ping Federate and PingOne)


Let’s create a modern Google Apps for business account – similar in concept to our recent Office 365 tenants.

image

So, just as we have Administrator@pingtest2.onmicrosoft.com (accessible via https://office.microsoft.com launch point) in the Office365 world, we also now have Administrator@pingtest2.mygbiz.com (accessible via http://www.google.com/enterprise/apps/business/) in the Google world.

In parallel, set up an even-longer frog-hopping IDP chain. We configured the forward hops from our Realty IDP to a local PingFederate gateway to a PingOne cloud instance.

One authenticates (via websso of course) to ones personal cloud desktop (currently provisioned with no SP places to do.) But, the Google Apps domain noted above will shortly be added!

image

access via https://desktop.connect.pingidentity.com/clouddesktop/rapattoni.com/

image

One notes just how much “Google analytics” (the nice word for spying) PingONE is doing on the transactions – from where to where, by who – which may upset quite a few Realty boards – who don’t want such tracking properties given to commercial tracking partners. For Realtors, working there social network is what gives them an edge. Offering free SSO or reporting is not going to fly – if the expectation is that the tracking/reporting can be resold to others (as is usual in the US). Sigh! (When will American corporations get it!! Spying is NOT ok, no matter how you pitch it!)

Anyways, to add Google as place to go in this “Federation Gateway”, we go back to PingONE Administrator mode (which is not itself not websso-powered, which is annoying).

image

Via the apps catalog (of SSO-enabled “SAAS” vendors), we select Google, for which above we pre-prepared our tenant:

image

In a rather frightening page we see the hookup instructions and the double-ended invocation URL with which to talk sp-initiated wbesso upstream to the IDP to mint a local session in the “desktop app” before doing a trial landing on the Google App, which will duly do sp-initiated websso against the session in the app. (We do lots of this in Realty, too!)

image

(SSO) URL is  https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=ce63276c-6cf6-4454-aae0-7c62097302fb&idpid=9038ea7f-9b46-4d81-8f1a-010a6dbc6826&appurl=https%3A%2F%2Fdocs.google.com%2Fa%2F%24%7BGoogle+Apps+Domain%7D

We save the pingone “signing” certificate for use later (and to be honest, I don’t actually know what this is for, yet). But, obviously it’s important for something!

image

Now, having JUST created a (working) Google Apps domain or this test, I’m faced with some horrifying text (since I don’t know as a mere dumb administrator….which of its conditions are true). All I know is I just finished signing up with Google Apps!

In order to allow your users to Single Sign-on to Google Apps, you must enable your Google Apps domain to support Single Sign-on. To do so, log into your Google Apps domain and then follow the instructions below.
P

lease note that if you are using Google Apps for Business as your Identity Provider (and NOT using AD Connect, PingFederate, or a SAML solution), then you should not add the Google Docs application from the PingOne Application Catalog. Instead, to add Google Docs to your PingOne account, you should go to the “My Applications” page, click “Add New Application”, and select “Manually Add New Application”. You can then create a link to Google Docs, using the following URL format: https://docs.google.com/a/${YourGoogleAppsDomain}

So what do I do!!?

Going back to Google, the company forces me to reveal my phone number as an administrator(for some security pretext). I feel lied to (whats new! About Google …and is USG relationship).

image

Using my intuition on how this all use to work a couple of years ago (when I last fiddled with anything Google’ish) we can presume that we need to focus on SSO setup:

image

we fill this in thus (eventually figuring that the “idpid” value comes from a parameter buried deep in the pingone URL for our instance of the federation Gateway)

image

Then upload the PingOne federation-signing cert (whose function I can now understand). In some absolutely crappy design, this act destroys all the other form inputs (so carefully input). Google is not the tech-firm it once was! So, we do it all again. This is the last time, before I abandon this.

image

After I consent to use SSO screen, we add a non-administrator user (much as we might license a user in Office365 land):

image

we get

image

image

http://www.google.com/a/pingtest2.mygbiz.com

SO, expecting websso (to my IDP, via the PingONe Gateway), I get a google signin screen, strangely. SO I enter the temp name/password, and get:

image

which leads to the usual google apps applications. But no websso! So lets try the double-initiator URL from PingOne:

 

https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=ce63276c-6cf6-4454-aae0-7c62097302fb&idpid=9038ea7f-9b46-4d81-8f1a-010a6dbc6826&appurl=https%3A%2F%2Fdocs.google.com%2Fa%2F%24%7BGoogle+Apps+Domain%7D

image

Now, we have evidently lost the PingOne configuration! (probably because we failed to resume config back at PingONe, after doing all the Google SSO config).

Do I have the heart to try all this again, using values from (SSO) URL ? https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=ce63276c-6cf6-4454-aae0-7c62097302fb&idpid=759a92dd-fa1c-4085-8a2c-bcbd38334d5d&appurl=https%3A%2F%2Fdocs.google.com%2Fa%2F%24%7BGoogle+Apps+Domain%7D

well yes, since there is stuff to do (that makes sense):

image

image

giving us something that MAY be important ( logically for pure SAML2 SPs that could do all this manual work rather better than google does it)

image

image

we now see more what we would expect (with the sp-init flow back to the Realty IDP) creating a federation gateway session, than from there trying to handoff to google ACS:

image

What is sent to Google’s ACS is this:

image

So if we now ensure that we release an emailName in the namespace Google expects,

image

we get….at the policy middleman (sigh, at the desire to exercise control concept)

image

if we arm the “group” (and this took multiple tries)

image

we eventually get to SP behavior (which is still a yet more of a pain):

image

if we log out of the persistent Admin session, we eventually get the experience we should have had 2 hours ago:

image

It works. But I don’t know how many people would be THIS persistent!

Advertisements

About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in pingfederate. Bookmark the permalink.