The art of the possible
When a technology is difficult to implement, there are generally two options. The first option is to try to find an implementation of the technology which is more simple to deploy and manage. The second option is to seek an alternative technology. In the case of security, both options carry caveats. Taking the option of simpler implementation may lead to security trade-offs. An alternative technology will almost always mean a change in the degree of security in the solution.
To put this into context, think about client-side digital certificates. This article by Jon Udell in Infoworld discusses the difficulties of using client-side digital certificates, and refers to a suggestion by Jamie Lewis (CEO of Burton Group) that PKI's sweet spot is for trust between enterprises. A few years ago - the two options for deploying client-side certificates were playing out as follows: either make client-side certificates simpler, or throw them out and use userid/password for access management instead. The first option was largely played out in Windows. Some of the choices which make certificates more practical on the client, e.g. optionally allowing private keys to be exportable to files, lessened the security. An alternative, much derided by PKI companies, was to avoid entirely the use of certificates on the client and instead use userid/password. This was often called "less secure". But the question is - "less secure for what?". Client-side certificates most obviously lend themselves to digital signatures and encryption. But for access control, they are rarely the ideal solution.
Over the past 3 years, Web extranet/portal access control products have provided a neat alternative to PKI - user enrollment without Registration Authorities, user entitlements without Attribute Certificates, and of course, user authentication without digital certificates. The SAML initiative came out of the Web access control industry. When bound to WS-Security, it will allow a SOAP message to be sent on behalf of an end-user who may have authenticated using a userid/password. When the SOAP message is digitally signed, or send in the context of a WS-SecureConversation session, the trust relationship is between the sender of the SOAP message (i.e. not the end-user) and the recipient system (possibly in another organization).
By looking into the SOAP message, the recipient system can see information about the ultimate end-user - e.g. how they were authenticated, their authentication context (in the case of Liberty), and (optionally) identity information (e.g. an email address). In the case of .NET, an end-user authenticating via userid/password may be mapped to a Kerberos ticket-granting ticket. The security technology may change, but there is a "golden thread" to map back to the end-user. This is "transitive trust".
The oft-cited issue with userid/password authentication is that digital signatures and encryption cannot be performed on the client. But is this really a problem? If a brokerage is trusting signed SOAP messages from a certain bank, should the trust relationship be with the bank, or with individual traders at the bank? The question seems academic until you consider the case of a trader who is fired from the bank and then attempts to trade. What if the bank hasn't notified the brokerage about the trader's changed status? Would the trade still go through and the brokerage would have nobody to sue?
At this stage, we in a situation which doesn't match reality. That is because, since the legal agreements are between the bank and the brokerage, the trust relationship must also be between the bank and the brokerage. The bank manages its own authentication and entitlements, and SAML offers a way for the bank to assert that "Joe Trader was authenticated by userid and password at 9.00am today". The brokerage trusts the issuer of the assertion - if it turns out that Joe Trader is actually Jane Imposter using a stolen password, then that is the bank's problem. This matches the real-world trust relationship. In this case, PKI (by signing SOAP messages) matches the real-world trust.
Userid/password authentication, leading to "transitive trust" using SAML and Kerberos tokens embedded in SOAP messages represents a more practical deployment of identity-based security - based on success in the real world - one which is sharp contrast to client-side digital certificates. It also maps more easily to real-world trust relationships. What started out being being seen as "low-grade security" option may be, ironically, the best option we have.
|
|
