Mogull on adaptative Auth and AuthZ

Richard Mogull mentions on his blog today the concepts of adaptative Authentication and Authorization. In short, from his post:

• "User: This is an area I intend to talk about in much greater depth later on. Basically, right now we rely on static authentication (a single set of credentials to provide access) and I think we need to move more towards adaptive authentication (where we provide an authentication rating based on how strongly we trust that user at that time in that situation, and can thus then adjust the kinds of allowed transactions). This actually exists today- for example, my bank uses a username/password to let me in, but then requires an additional credential for transactions vs. basic access.


• Transaction: As with user, this is an area we’ve underexplored in traditional applications, but I think will be incredibly valuable in cloud services. We build something called adaptive authorization into our applications and enforce more controls around approving transactions. For example, if a user with a low authentication rating tries to transfer a large sum out of their bank account, a text message with a code will be send to their cell phone with a code. If they have a higher authentication rating, the value amount before that back channel is required goes up. We build policies on a transaction basis, linking in environmental, user, and situational measurements to approve or deny transactions. This is program logic, not something you can add on."

I'll keep out from this post the ideas about cloud computing, layers and the real meat of his post, but I want to stress how nice the adaptative authentication and authorization concepts are. Richard is right when he says that banks are already doing that, I remember including the concept in the online banking of a Bank I worked for almost 4 years ago. The thing, however, would be trying to bring that to other authentication and authorization actions that exist inside (and outside, in the cloud, whatever) the organization. It could be used to further protection on privileged IDs, to enforce higher controls over remote access from potentially malicious networks, specific time ranges, and a lot of other things that could be used to indicate a higher threat level. In fact, it could even be deployed by transparent proxies in front of the applications without a need to change code or hard to deploy integrations.Definitely, something that should be better explored by security vendors.