Web Service Security
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (550.19 KB, 47 trang )
Web Service Security:
Theory and Practice
Andy Gordon (
Microsoft Research
)
Software and Web Engineering in the Microsoft .NET Environment
Microsoft Research Fourth Crash Course for Faculty and PhDs
Saint John's College, Cambridge, March 25–28, 2003
2
What’s a Web Service?
“A web service is a web site intended for use by
computer programs instead of human beings.”
(Barclay et al, MSR-TR-2002-53)
Internet examples: (bye bye, screen-scraping!)
/>
/>
Within intranet: vendor-neutral middleware to
interconnect existing systems
Between intranets: inter-institution workflow (e-
business, e-science); eg Globus OGSA based on WS
3
Example: A Google Client
Create a local proxy class, instantiate, and invoke
The proxy class GoogleSearchService generated from
a WSDL file, an XML-encoded service description
GoogleSearchService s = new GoogleSearchService();
foreach (string q in queries)
{
GoogleSearchResult r = s.doGoogleSearch(myKey, q);
int estResults = r.estimatedTotalResultsCount;
w.WriteLine("\t{0}\t{1}", q, estResults);
}
4
Outline Architecture
SOAP
SOAP
Request
Request
Implementation via
proxy class and
HTTP transport
My Desktop
Windows
Google.com/apis
Unix/Linux?
GoogleSearchService s =
new GoogleSearchService();
foreach (string q in queries)
{… s.doGoogleSearch(myKey, q); …}
Implementation via
WebService classes
in Web Server
SOAP
SOAP
Response
Response
[WebMethod]
… doGoogleSearch(myKey, q) …
database
Vendor-neutral
XML-encoding
over HTTP
The Internet
TCP/IP
5
Web Services: What’s New?
Though their core is roughly SOAP-encoded RPC, what’s
new about web services is the combination of:
Vendor-neutral interoperability
Internet-scale
Toolsets for “mere mortals” (Barclay et al)
Signs of fervour,
Wide support from commercial & OSS suppliers
Weekly news of progress at OASIS and W3C
yet reasons for caution,
Cost of SOAP encoding?
Lack of SOAP security?
6
The 2002 Security Story
The 2002 best practice was to build secure web
services using an SSL (as in https) transport
SSL encrypts all traffic between client and web server,
so opaque to intermediaries:
Messages cannot be monitored by firewalls
Messages cannot be forwarded by routers
Messages not encrypted in files or databases
Moreover, SSL has scalability problems
Party line: security within SOAP envelopes is better:
Avoids problems with SSL
Avoids dependency on HTTP transport
And is the subject of this talk…
7
Parts I-II: The Official Version
Theory: IBM/MS/VeriSign/… WS specs
Security Roadmap, Apr 2002
WS-Security, Apr 2002
Practice: MS WSE (Web Service Enhancements)
RTW Dec 2002, plugin for VS.NET
Product implementing WS-Security, WS-Routing,
and DIME attachments
Signature, encryption based on passwords,
certificates
8
Parts III-V: The Research Version
Theory: MSRC/DePaul Cryptyc type system, etc
Tool for specifying/verifying crypto protocols, such
as the broad family expressible with WS-Security
Practice: MSRC DS V1 (Declarative Security V1)
ACM
XML Security 2002
paper; MSR-TR-2002-108
Research prototype using VS.NET
Declarations for signature, encryption; formal
model of programming abstraction, and verification
of protocol
Part I:
A Bottom-Up View of a
WSE Message
To understand what WSE delivers,
either you read the specs, docs,
samples, etc; or you snoop at what’s
going on the wire…
Fellow snoopers: Karthik Bhargavan
adnd Cédric Fournet, MSRC
10
A Sample SOAP Request
<soap:Envelope xmlns:soap=" /> xmlns:xsi=" /> xmlns:xsd=" /> <soap:Body>
<AddInt xmlns=" /> <a>20</a>
<b>40</b>
</AddInt>
</soap:Body>
</soap:Envelope>
Says: “please compute 20+40”
XML not meant to be read by humans, so we’ll omit
namespace info, and trailing brackets…
11
A Sample SOAP Request
<Envelope>
<Body>
<AddInt>
<a>20</>
<b>40</>
Says: “please compute 20+40”
XML not meant to be read by humans, so we’ll omit
namespace info, and trailing brackets…that’s better
12
A Sample SOAP Response
<Envelope>
<Header>
<Timestamp>
<Created>2003-03-11T23:36:06Z</>
<Expires>2003-03-11T23:41:06Z</>
<Body>
<AddIntResponse>
<AddIntResult>60</>
Unlike the client making the request, the server has
included a timestamp in the optional Header
Next, the client-side architecture in more detail…
A SOAP header; WSE filters
out messages with invalid
timestamps
13
Client Sends a Message…
User Code
WSE Runtime
SOAP
Context
SOAP
Custom filters
DIME
Security
Routing
14
Client Receives a Message…
User Code
WSE Runtime
SOAP
Context
SOAP
Custom filters
DIME
Security
Routing
15
An Aside: WS-Routing
Client requests a service from server A, which in fact routes it
on to server B
Routing determined by a
referral cache
at A
If B needs to be taken offline, we can update the cache to point
at C, transparently to the client
Aside to an aside: DIME enables non-XML, binary attachments
16
An Encrypted Request
<Envelope>
<Header>
<path actor="next">
<action> /> <to>http://
mydomain
/symmetricencryption.asmx</>
<id>uuid:ced7a259…</id>
<Timestamp>
<Created>2003-03-13T18:24:43Z</>
<Expires>2003-03-13T18:25:43Z</>
<Security>
<ReferenceList>
<DataReference URI="#EncryptedContent-90853130…" />
<Body>
<EncryptedData Id="EncryptedContent-90853130…“
<EncryptionMethod Algorithm="tripledes-cbc" />
<KeyInfo><KeyName>WSE Sample Symmetric Key</></>
<CipherData><CipherValue>fnNQgEFqOes5+g…</></>
WS-Routing header
WS-Timestamp header
WS-Security header
ReferenceList element:
list of pointers to
EncryptedData elements
Encrypted SOAP body
17
Processing Security Headers…
Security layer processes each header in order, to
transform and validate the SOAP message
Each EncryptedData element referred to by a
ReferenceList is decrypted in turn
Customisable DecryptionKeyProvider class
invoked with the KeyInfo, to get suitable
decryption key
WSE supports messages encrypted using (1) shared
symmetric keys, or (2) X509-based public-key crypto
WSE supports messages signed using (1), (2), and (3)
keys derived from username/password combos, as in
the next slide
A Signed Request
<Envelope>
<Header>
<path actor="next">
<action> /> <to>http://
mydomain
/usernamesigning.asmx</>
<id>uuid:5ba86b04-3c0f-428b-8dd6-17804286fe40</>
<Timestamp>
<Created>2003-02-04T16:49:45Z</>
<Expires>2003-02-04T16:50:45Z</>
<Security>
<UsernameToken>
<Username>adg</>
<Password>Ouywn2V6ikNNtWYL29gl9R3CPBk=</>
<Nonce>cGxr8w2AnBUzuhLzDYDoVw==</>
<Created>2003-02-04T16:49:45Z</>
<Signature>
<SignedInfo>
<Reference URI="#..."><DigestValue>Ego0...</>
<Reference URI="#..."><DigestValue>5GHl...</>
<Reference URI="#..."><DigestValue>efb0...</>
<Reference URI="#..."><DigestValue>dFGb...</>
<Reference URI="#..."><DigestValue>23io...</>
<Reference URI="#..."><DigestValue>E4G0...</>
<SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</>
<KeyInfo><SecurityTokenReference><Reference URI="#..."/>
<Body>
<AddInt>
<a>20</>
<b>6</>
Routing and timestamp
headers as before
UsernameToken assumes
both parties know adg’s
secret password
pw
Password digest =
sha1(
nonce
+
time
+
pw
)
proves knowledge of
pw
Nonce to prevent replays;
receiver needs to cache
recently seen nonces
hmacsha1
(
key
, Signature) where
key
=psha1(
pw
+
nonce
+
time
)
Each DigestValue is the
sha1 hash of the URI target
URI arrows implemented
using GUID Id attributes
Hence, signature can
prove this is a fresh
message from adg
![[Tài liệu cũ] XML Web Services Security](https://media.store123doc.com/images/document/13/ly/lm/medium_lmc1367978862.jpg)
