No controversy here Farrukh. (01)
+1 (02)
John R. Weiland
Information Technology Specialist
GS 2210 (APPSW) Code 07 Navy Medicine OnLine
Chair, DoN CIO Business Standards Council (03)
Naval Medical Information Mngmt Cntr
Bldg 27
8901 Wisconsin Ave
Bethesda, Md. 20889-5605 (04)
301-319-1159
JRWeiland@xxxxxxxxxxxxxxx
http://navymedicine.med.navy.mil
"GIVE ME A PLACE TO STAND AND I WILL MOVE THE EARTH"
A remark of Archimedes quoted by Pappus of Alexandria (05)
-----Original Message-----
From: soa-forum-bounces@xxxxxxxxxxxxxx
[mailto:soa-forum-bounces@xxxxxxxxxxxxxx] On Behalf Of Farrukh Najmi
Sent: Friday, March 24, 2006 9:01 AM
To: Service-Oriented Architecture CoP
Subject: [soa-forum] Secure Web Service (06)
I am taking liberty (pub intended) to change the subject of thread to
reflect the focus on secure web services. (07)
I support Mark's comments below. I see Liberty, OASIS SAML and OASIS
Web Services Security (WSS) , OASIS XACML
as key specs to support in our work to demonstrate Secure Web Services
using established standards rather than proprietary
alternatives. This should be as non-controversial as motherhood and
apple pie I hope :-). (08)
This is the only way for multiple products to inter-operate and to avoid
vendor lock-in (09)
--
Regards,
Farrukh (010)
Mark O'Neill wrote:
> Just a short email just to add to some of the points in this email thread
>
> - Amazon should certainly be commended for making authenticated Web
Services
> live, but I wouldn't recommend copying their authentication model. They
have
> re-invented some items which are present in WS-Security, for example the
> UsernameToken. I spoke about this at the RSA conference - see slides 33 to
> 36 in this slide deck for some analysis of Amazon's authentication model
> (http://www.vordel.com/downloads/rsa_conf_2006.pdf) . Putting tokens into
> proprietary fields in the XML, and using these for authentication is, in
my
> view, a re-invention of the WS-Security wheel.
>
> - Vordel's products are being used for management and security of
> inter-departmental Web Services for a European govt. My lessons, from
> working on the implementation of this, were that: (1) A variety of
> authentication methods should be provided to the client: from HTTP-Auth
over
> SSL up to WS-Security token-based Auth. You can always give varying access
> depending on the authN that was used, but my lesson was that you can't
force
> one particular AuthN method on the client [unless your architecture
includes
> an "onramp" client-side device like they have in the UK with their "DIS
> box"]. (2) Following AuthN, you must insert tokens into the messages in
> order to persist the security context. This is where SAML and
WS-Federation
> come into play. In the case of some platforms, such as WebLogic, these
> tokens can be used to pass the user context (and/or Roles etc) to the
actual
> Web Service endpoint (3) PKI integration and, just as important, Web
Access
> Control policy server integration is vital.
>
> (011)
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP (012)
|