[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-dev] Re: Authentication/Authorization with MSH?
Douglas bid hello to his wife with (I'm sure the topic will thrill her....): > The Thought Provokes > 1) Should we look at using Federated 3rd parties for authorization Possibly, but doing so raises a lot of issues in my mind that would have to be addressed. One of the key ones is who is the "trusted" 3rd party...and how much can you really trust them? Microsoft's Passport and new Palladium initiatives are good cases in point....no one will trust MSoft in such a scenario, especially in the B2C space. Consumers and/or SME's might be very loath to have a federated 3rd party involved, since there is so much potential (and it seems incentive) for abuse of privacy issues (eg. authentications can be captured and used to track usage patterns for individuals or organizations across too many boundaries). I would be more comfortable with a scenario where communities of companies (say an Automotive Supply Chain), would use nascent standards such as SAML and WS-Security to pass authorization/authentication between them on an as needed basis, where trust boundaries were negotiated between the sites ahead of time. For example, if you log into a Ford Supply Chain application, then if you get redirected to a Goodyear site for tires, then Ford would send the user credentials on to Goodyear (which could accept them...require more credentials, etc.). The beauty of such an approach is that only the parties involved exchange credentials, with no "master" database existing anywhere...thus being rather harder to abuse the privacy and tracking data. However, the downside is there needs to be a lot of point to point security negotiations to set this up, as opposed to a single central source that everyone can go to for credentials. It does need to be pointed out that the 800 lb gorillas in each market segment (eg. GM, Ford, Daimler/Chrysler in the domestic auto industry) are unlikely to outsource their authentication/authorization to a 3rd party very quickly, if at all, if history is any indication. > 2) Is this a valid scenario for B2C, B2B, A2A, Sure....but the privacy abuse (whether real or perceived) are more likely to be a stumbling block in the B2C scenario as discussed above. B2B might be doable if the heavyweight players in an industry vertical can co-operate and decide on a common 3rd party (eg. Covisint perhaps in Automotive). I doubt the big players will trust someone like MSoft or IBM....too much vested interest on the part of the IT firms....and most Fortune 1000's are unlikely to "trust" their crown jewels (authX2 credentials) to such a 3rd party. It's just not human nature. B2B might be easier to accomplish, within specific industry verticals...since this might go hand in hand with hub/intermediary responsibilities (eg. Covisint springs to mind). But it would still require a huge amount of political negotiations, so I don't expect to see it any time too soon. A2A has the most potential, since it is behind corporate firewalls by definition. However, the "trusted" 3rd party would be an internal organization, maybe the IT division within an Auto Manufacturer would set up a global registry/repository/directory of security credentials that all other divisions and applications could use. However, given that most Fortune 1000's have not yet managed to consolidtate all of their user login and other directories into one, despite the technologies having been available for quite some time (LDAP, X501, etc.), I wouldn't hold my breath. For this same reason I am sceptical on how fast reg/rep's such as UDDI will be fully implemented (to the point of single registry nirvana) withing large corporations. > 3) Will the use of Federated 3rd party be enough to relieve bottle necks > of authorization processes Likely not. For the simple reason that the 3rd party will be external, and thus the authX2 requests and credential/token passing will have to flow outside the corporate boundaries (through firewalls.....across slow/unreliable net links perhaps), and so response time will become non-deterministic, and at the least no where near as good as when the auth servers are hosted internally on the intranet of a company (where IT can optimize 'em to death). This situation will be exacerbated by the current security focus that is extant. There have been so many problems in the security area, that I think many companies will be very reluctant to federate/outsource their authX2 functions for some time to come. The only solution that comes to mind is that of an independent body such as OASIS, UN/CEFACT, etc. that might be able to walk the fine line of impartiality yet steer clear of typical governmental "Big Brother is watching" fears. > 4) Who "will or should" maintain definition of > terms to be shared between 3rd party authorizers WTFPIC, I would suggest that this problem is akin to the Core Components issues that have made that standard slower than all the other ebXML specs. It's a non-trivial, politically-fraught problem to create, maintain and garner agreement on such things. Maybe we need the 2nd coming of Christ (apologies to those not of the Christian death cult faith ;-) ) to stand a chance of accomplishing this. (WTFPIC = With tongue firmly planted in cheek). More seriously, I think what will happen is that the XML-based security specs (SAML, WS-Security, and others) will converge with the interests of large corporations that own captive business communities (eg. auto supply chains), and the big corporations will play a significant role in defining these terms and definitions on top of the specs, at least within their captive or industry communities. 5) Any other ideas that > should be talked about in this open thread. I think I've raised a few issues above. The whole federated, 3rd party approach to security is likely to slam into the wall of politics and human nature before it gets resolved in a global manner. That is not to say it won't eventually get resolved (as I believe it needs to), but that it will likely take a long time. Just my 2 cents worth (about 1.54 cents US based on Canuckian exchange rates today). Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
Powered by eList eXpress LLC