Adventures of an Eternal Optimist

As of very recently, I have had the pleasure of working on contract for Ping Identity – and I have been dying for today, because I can finally talk about what the combination of PingConnect and Google can accomplish.

Traditionally, the ability to integrate a disparate set of cloud applications for a userbase was predicated on the non-trivial task of first creating a Start of Authority.   As a bare minimum, you had to (a) create an authoritative user repository and (b) enable some kind of service to perform an initial authentication and leverage the resulting session to facilitate federation to various parts of the cloud.  After that, you still had to figure out who could consume what you had worked so hard to be able to establish.

Now, you can make Google your Start of Authority, and instantly get to a laundry list of 60 applications with PingConnect.  All without a Windows domain, a WAM server, or a federation server, and best of all, by utilizing an existing repository that is likely to be maintained regularly.  AND, there is actually useful stuff to get to.   This may not sound like a big deal to the companies who all have Windows domains anyway, but I believe that this could push back the need for a growing small business to get a Windows domain quite significantly.  To me, the start of authority problem was a massive barrier to adoption for federation, and that barrier has been obliterated, not just on the cost front but on the effort front too.  They say it takes a village?  Well now we actually have one worth hanging out in.

Interesting times.

Tell me what you think of the following series of events:

1. I receive an email with a link in it, promising money.
2. I click on the link and see a screen purporting to be my bank and asking for my username and password.
3. Not trusting the page to actually be my bank, I go independently to my bank site and authenticate.
4. Clicking again on the link from my email,   I hope to see that the bank authentication page is gone,  and that I am taken directly to the step where I answer the “security question” and get my money.   Instead, however, I find that even though I have an existing valid bank session set up in my browser,  I am still taken to a login page and forced to re-enter my credentials before the transaction will work.

I know what you’re saying! Don’t do it! It’s a phishing attack!   Sadly, this is actually what happens if you are the recipient of a Certapay INTERAC email money transfer in Canada.   It is a phisher’s wildest dream come true, don’t you think?  Even those familiar with the process will eventually stop looking at URLs and just click through the brightly colored screens to enter their banking credentials.

The whole setup is ripe for abuse.  Why, dear god, is there no way to accept a payment without typing in your banking credentials?  There certainly needs to be an authorization step, but forcing an authentication step to be bundled is both lazy and dangerous.  The worst part is that the banks are complicit in this.

The best irony of all is the email fraud section of their website security page, under the “How to Protect yourself” section says:

• Do not share or provide your personal information.

Oh, you mean like my usernames and passwords for my entire BANK ACCOUNT????

jeez.

In researching a few products for a client, I came across an e-book on Managing Linux & UNIX Servers by Dustin Peryear.  I managed to get access to a chapter without registering, and I liked what I saw so much that I had to have the whole book.
The thing that is remarkable about this book to me, is that it is NOT a book about technology, commands, program execution or coding.  It is a book about what to get done and why.   There are so few of these kinds of books – the ones that assume that once you have a comprehensive plan for getting things done,  finding out how is the easy part.  The books that get that the mapping works better from the top down than the bottom up: all the man pages in the world will not help you if you don’t have the context to know which of them you should be reading, and what the end result should be when you apply that knowledge.  It is the guidance that makes the difference.

I very badly want a book like this for information card Relying Parties, specifically the PKI functionality of an RP.   I have work to do on my RP:  right now I know I’m missing several critical checks to ensure integrity and non-repudiation for the messages I’m accepting and trusting.   But how do I know that I have covered all the bases?   I have this list of interoperability issues.  I have a set of api calls into security libraries like xmlseclib and openssl that could possibly solve my issues.    What I do not have is guidance.   I feel like I’m assembling an entertainment unit from IKEA, and I have detailed engineering information on every screw and every panel in the entire IKEA inventory:  thousands of weights, heights, screw thread pitches, you name it.  While I technically have access to everything I could possibly need to assemble my entertainment unit,  it is left up to me to figure out which and how many of the inventory items I need, how they fit together, and what order they must be assembled.

I suppose what I’m saying is we need to step above RTFM (Read the Fsking Manual) to KWFMTR (Know Which Fsking Manuals to Read).

(photo credit: http://www.flickr.com/photos/jonk/33283987/)