[
Lists Home |
Date Index |
Thread Index
]
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@ingr.com]
> Sent: Thursday, January 10, 2002 1:05 PM
> To: 'Michael Brennan'; 'Roger L. Costello'; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] 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
|
