[ebxml-dev] Re: Authentication/Authorization with MSH?

[Andrzej Jan Taramina <andrzej@chaeron.com>]

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