Strong Authentication and Risk-Based Access Control Would Reduce OpenID Worries
By Mark Wilcox - CTO - Oracle Consulting Security-Oracle on Aug 08, 2008
Many of you may have read this post from Gerry Beuchelt of Sun talking about how to protect Sun employees using their OpenID R&D project.
Among the advice - make sure systems are patched, verify the DNS of your ISP is working properly and to double-check the hostname of their OpenID provider.
That is a tall order even for the most technical people. I mean I'm a geek among geeks and I don't think I could accomplish those steps.
But it does give me an opportunity to write about how strong authentication and risk-based access control could help here. Currently we have a product (Oracle Adaptive Access Manager) that provides both functions.
OAAM allows you to use a virtual keypad to enter username and password credentials. This virtual keypad includes such features such as using a background image that you chose (or perhaps chosen for you in an internal environment). It also has other features such as a timestamp, showing a key phrase in the image and the image moves every time it is refreshed. Also the keypad can be virtualized (e.g. driven by your mouse) so that it makes it darn near impossible for a keyboard logger to capture your password.
If more OpenID providers used something like OAAM then it would be much harder for a rogue OpenID provider to be configured.
Additionally risk-based access control (another OAAM feature) would help OpenID relying parties make better access control decisions for a linked OpenID. For example based on prior activity it could assign risk factors (e.g. normally you accessed from an IP in Dallas, but now we're seeing IP access from Outer Elbonia, maybe we should alert a customer care rep to call you before moving that money).
These same principals could also be applied to any other federation scenario including SAML or Liberty based federation like we provide via Oracle Identity Federation.
Of course OAAM has benefits within enterprises who are not using OpenID or SAML but I just wanted to point out some tangible steps people could do to help secure OpenID beyond training people to become DNS engineers.