[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Web Services Best Practice (was: Interesting XML-DI ST-APP
I'm not a real expert on security technologies. I was trying to track the Security Services activity at OASIS [1] for awhile, but I found some of the discussions going over my head, so I unsubcribed from the mailing list and decided to just trust those involved to do the right thing (and hope that the end result could be used and implemented by mere mortals, such as myself). I'm inclined to believe, though, that the SAML standard they are developing will be key, given the broad vendor participation in the activity. SAML has dependencies on XML Signature [2] and XML Encryption [3]. Certainly, SSL or message encryption should be used when doing messaging over a public network. I've been surprised at how many developers don't even take this simple step. Beyond that, I think getting the leading vendors to agree on something and provide easy-to-use tools for the rest of us will be key. I know that Netegrity has released a free Java toolkit [4] that purports to implement SAML (which is interesting since SAML is still a moving target, AFAIK). That's probably worth a look by Java developers, though I haven't used it yet myself. Beyond that, I'm still waiting for some guidance myself from the vendors regarding what is going to get widespread adoption. For now, we (Allegis) just use simple username/password-based authentication to simplify implementation for our customers/partners (who have varying levels of IT sophistication). This is included in the header of the message envelope, which is always either encrypted before sending or transmitted over an SSL connection. We've had to push back a few times on partners that wanted to do integrations with us over the internet without any authentication. We, of course, have authorization mechanisms in our system that ensure a user account used for integrations can only do those things they are explicitly authorized to do. We also support a proprietary scheme for single sign-on that involves passing encrypted tokens back and forth between sites. In this scenario, instead of using a password, we rely upon a trusted third-party to vouch for the identity of a system sending us messages. There have been thoughts of using client SSL certificates or digital signatures for authentication. We have to be careful, though, not to adopt technologies for which our customers or partners may not have tools at hand (or which may simply be intimidating for their IT staff). Getting cheap (or free) and easy-to-use tools out there for supporting these security technologies is going to be key for adoption, and we are not in the business of providing such tools ourselves. [1] http://www.oasis-open.org/committees/security/ [2] http://www.w3.org/Signature/ [3] http://www.w3.org/Encryption/2001/ [4] http://www.netegrity.com/products/index.cfm?leveltwo=JSAML > -----Original Message----- > From: Bullard, Claude L (Len) [mailto:clbullar@i...] > Sent: Thursday, January 10, 2002 1:05 PM > To: 'Michael Brennan'; 'Roger L. Costello'; xml-dev@l... > Subject: RE: Web Services Best Practice (was: Interesting > XML-DI ST-APP thread) > > > A good article has appeared on XML.COM that takes all of the > web service specs one at a time and shows how they fit into > various vendor architectures. I note several xml languages > devoted to security issues. Are any of these good candidates > in your opinion and experience? One way to improve shoddy > practice is with a good standard. (oh... not that again..). > > len
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|