web services and pki
Post on 10-Apr-2015
162 Views
Preview:
DESCRIPTION
TRANSCRIPT
W h i t e P a p e r
Web Services and PKIThe How and Why
L a y e r 7 T e c h n o l o g i e s
W h i t e P a p e r
Web Services and PKI
L a y e r 7 T e c h n o l o g i e s
W h i t e P a p e r
Web Services and PKI
Copyright © 2010 Layer 7 Technologies Inc. All rights reserved.
trademarks of Layer 7 Technologies Inc.
Contents
Introduction ................................................................
Channel vs. Message Security ................................
The Challenge with Message Security
Web Services Security Requires PKI
An Example of PKI in Web Services
Conclusion ................................................................
About Layer 7 Technologies ................................
Contact Layer 7 Technologies ................................
Legal Information ................................
ogies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective
................................................................................................
................................................................................................
e Security ................................................................................................
................................................................................................
An Example of PKI in Web Services ................................................................................................
................................................................................................
................................................................................................
................................................................................................
................................................................................................................................
SecureSpan and the Layer 7 Technologies design mark are
yrights are the property of their respective owners. 2
.................................................. 3
....................................................... 3
.......................................... 4
.............................................. 4
........................................... 4
..................................................... 6
.......................................................... 7
....................................................... 7
.......................................... 7
Web Services and PKI
Copyright © 2010 Layer 7 Technologies Inc. All rights reserved.
trademarks of Layer 7 Technologies Inc.
Introduction Enterprise Public Key Infrastructure (PKI) has a bad name. Considered complex, costly, and difficult to deploy and
maintain, the technology has been plagued with criticism since it first appeared. To the dismay of many CIOs, few
applications have attempted to effectively use PKI. This may soon change.
that demands the flexibility that only an enterprise PKI deployment can offer.
Channel vs. Message SecurityIf one were to lump all of the existing production
security models, some interesting trends would arise. First, many do not address security at all. This is probably
due to the relative immaturity of the Web services technology rather than a developer over
of the remaining applications delegate security entirely to Secure Sockets Layer (SSL) or a Virtual Private Network
(VPN) connection.
SSL provides confidentiality and integrity. Automatic sequence numbering protects against replay
a server-side certificate that binds the server’s Domain Name Server (DNS) name to a subject, ensuring server
authentication and protecting against impersonators and most man
rely on the integrity of the DNS system, it
side certificate authentication that, though powerful, is rarely implemented.
Channel continuity is probably the most unheralded quality of SSL. Once a session is set
up, and the client and server mutually authenticate (with the client using a certificate
under SSL, or via HTTP authentication, or an
level of trust is established on the open socket so that it is available for multiple
transactions without requiring re
maintained security context is easy to take
Of course, one of the reasons behind SSL’s success on the Web was that, although it
utilizes public key cryptography, it does not need full
servers use certificates issued by the “browser cartel”. Those
fortunate enough to have their root cer
store of the most popular browsers. With the exception of a few early consumer banking products that have now
been abandoned, almost nobody provides the baroque logistics of client
to delegate PKI to a third-party greatly simplified Web security. This was one of the reasons SSL became good
enough for most online transactions, even when initially c
solutions like Secure Electronic Transaction (SET).
SSL’s greatest weakness, however, is that it is oriented toward synchronous transactions that require a direct
connection between participants. Both parti
secure context, and all information in the transaction is en
makes SSL an insufficient security model for Web services. Despite the nam
Web services uses existing Web infrastructure (including HTTP transport, Web application servers, etc.), but it is
fundamentally a one-way messaging paradigm for computer communications composed around a simple XML
message structure with an extensible header model.
Web service messages may not piggyback on HTTP at all. They might flow across a Message
(MOM) such as IBM’s MQSeries or be carried asynchronously by Simple Mail Transfer Protocol (SMTP).
packets being passed between routers, Simple Object Access Protocol (SOAP) messages are designed to flow
through a network of intermediates. Intermediates may be required to view header information to make
processing decisions based on application
and requires synchronous responses from a receiver is not appropriate in a Web services architecture.
SSL requires a direct connection
between participants, which is not
always possible with Web services
ogies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective
Enterprise Public Key Infrastructure (PKI) has a bad name. Considered complex, costly, and difficult to deploy and
maintain, the technology has been plagued with criticism since it first appeared. To the dismay of many CIOs, few
to effectively use PKI. This may soon change. Web services promote
that demands the flexibility that only an enterprise PKI deployment can offer.
Message Security If one were to lump all of the existing production-level Web services applications together and categorize their
security models, some interesting trends would arise. First, many do not address security at all. This is probably
due to the relative immaturity of the Web services technology rather than a developer oversight. Second, the bulk
of the remaining applications delegate security entirely to Secure Sockets Layer (SSL) or a Virtual Private Network
SSL provides confidentiality and integrity. Automatic sequence numbering protects against replay
side certificate that binds the server’s Domain Name Server (DNS) name to a subject, ensuring server
authentication and protecting against impersonators and most man-in-the-middle attacks. While t
tem, it is often considered an acceptable risk. SSL even offers optional client
cate authentication that, though powerful, is rarely implemented.
Channel continuity is probably the most unheralded quality of SSL. Once a session is set
up, and the client and server mutually authenticate (with the client using a certificate
under SSL, or via HTTP authentication, or an application-level means such as forms), a
level of trust is established on the open socket so that it is available for multiple
transactions without requiring re-authentication. The value in such a transparently
maintained security context is easy to take for granted.
Of course, one of the reasons behind SSL’s success on the Web was that, although it
utilizes public key cryptography, it does not need full-blown PKI. Most SSL
servers use certificates issued by the “browser cartel”. Those certification authorities are
fortunate enough to have their root certificates automatically installed within the trust
store of the most popular browsers. With the exception of a few early consumer banking products that have now
body provides the baroque logistics of client-side certificates on the Web. The ability
party greatly simplified Web security. This was one of the reasons SSL became good
enough for most online transactions, even when initially challenged by technically elegant though complex
solutions like Secure Electronic Transaction (SET).
SSL’s greatest weakness, however, is that it is oriented toward synchronous transactions that require a direct
connection between participants. Both parties need to be available, multiple passes are necessary to set up a
secure context, and all information in the transaction is encrypted (a costly processor burden). This requirement
makes SSL an insufficient security model for Web services. Despite the name, Web services is not about the Web.
Web services uses existing Web infrastructure (including HTTP transport, Web application servers, etc.), but it is
way messaging paradigm for computer communications composed around a simple XML
sage structure with an extensible header model.
Web service messages may not piggyback on HTTP at all. They might flow across a Message-Oriented Middleware
Series or be carried asynchronously by Simple Mail Transfer Protocol (SMTP).
packets being passed between routers, Simple Object Access Protocol (SOAP) messages are designed to flow
through a network of intermediates. Intermediates may be required to view header information to make
cation-level protocol. A channel-based security model that encrypts everything
and requires synchronous responses from a receiver is not appropriate in a Web services architecture.
SecureSpan and the Layer 7 Technologies design mark are
yrights are the property of their respective owners. 3
Enterprise Public Key Infrastructure (PKI) has a bad name. Considered complex, costly, and difficult to deploy and
maintain, the technology has been plagued with criticism since it first appeared. To the dismay of many CIOs, few
Web services promotes a security model
ervices applications together and categorize their
security models, some interesting trends would arise. First, many do not address security at all. This is probably
sight. Second, the bulk
of the remaining applications delegate security entirely to Secure Sockets Layer (SSL) or a Virtual Private Network
SSL provides confidentiality and integrity. Automatic sequence numbering protects against replay attacks. SSL uses
side certificate that binds the server’s Domain Name Server (DNS) name to a subject, ensuring server
While this feature does
is often considered an acceptable risk. SSL even offers optional client-
Channel continuity is probably the most unheralded quality of SSL. Once a session is set
up, and the client and server mutually authenticate (with the client using a certificate
level means such as forms), a
level of trust is established on the open socket so that it is available for multiple
authentication. The value in such a transparently
Of course, one of the reasons behind SSL’s success on the Web was that, although it
blown PKI. Most SSL-enabled Web
certification authorities are
tificates automatically installed within the trust
store of the most popular browsers. With the exception of a few early consumer banking products that have now
side certificates on the Web. The ability
party greatly simplified Web security. This was one of the reasons SSL became good
cally elegant though complex
SSL’s greatest weakness, however, is that it is oriented toward synchronous transactions that require a direct
es need to be available, multiple passes are necessary to set up a
crypted (a costly processor burden). This requirement
e, Web services is not about the Web.
Web services uses existing Web infrastructure (including HTTP transport, Web application servers, etc.), but it is
way messaging paradigm for computer communications composed around a simple XML
Oriented Middleware
Series or be carried asynchronously by Simple Mail Transfer Protocol (SMTP). Similar to IP
packets being passed between routers, Simple Object Access Protocol (SOAP) messages are designed to flow
through a network of intermediates. Intermediates may be required to view header information to make
based security model that encrypts everything
and requires synchronous responses from a receiver is not appropriate in a Web services architecture.
Web Services and PKI
Copyright © 2010 Layer 7 Technologies Inc. All rights reserved.
trademarks of Layer 7 Technologies Inc.
The Challenge with Message SecurityAccording to the Organization for the Advancement of Structured Information Standards (OA
Wide Web Consortium (W3C) standards, the solution to the Web
into the message itself. That is, provide a means of authentication, integrity, and
confidentiality that is integral to the message and completely decoupled from
transport channels. This ensures message secur
whether it flows over regular HTTP, across a Peer
prietary protocols, is persisted to a file, or printed onto a piece of paper. A security
model like this that supports asynchronous mes
advantages.
In the Oasis Web Services Security (WSS) standard, each SOAP message stands alone
and can have uniquely applied security. The standard includes mechanisms for
encrypting any content in the message at a very fine
than applying a cipher to the entire message, only those parts that are deemed
necessary to cryptographically secure are encrypted. The public parts of a message (such as the header fields that
might be relevant to an intermediate in making a routing decision) can be left in the clear.
Since any part of a SOAP message is subject to modification by an at
networks, WSS provides a mechanism for signing message content with a granul
encryption. For example, not only can a message author encrypt the credit card element, but they can also sign it
to ensure that no substitution in transit goes undetected. The same protection can be extended to unencrypted
public elements, such as timestamps inserted into the header.
Web Services Security Requires PKIWSS goes to great lengths to remain flexible with potential encryption/signing technologies. But even though it is
possible to build a WSS-compliant system based on
specification, this disqualifies a transaction from any claims to non
list of potential security flaws. As a result, it’s difficult to find a vendor’
PKI. Furthermore, most organizations are building systems predicated on having key pairs on both sides of a
transaction: at the message producer (client) and the message consumer (server) sides, necessitating PKI.
An Example of PKI in Web Services
Because Web service messages
may flow asynchronously
across the network, security must be
implemented within each message
ogies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective
The Challenge with Message Security According to the Organization for the Advancement of Structured Information Standards (OASIS) and the World
Wide Web Consortium (W3C) standards, the solution to the Web services security problem is to absorb security
into the message itself. That is, provide a means of authentication, integrity, and
confidentiality that is integral to the message and completely decoupled from
transport channels. This ensures message security remains consistent and trustworthy
whether it flows over regular HTTP, across a Peer-to-Peer (P2P) network using pro
prietary protocols, is persisted to a file, or printed onto a piece of paper. A security
model like this that supports asynchronous messaging has great architectural
advantages.
In the Oasis Web Services Security (WSS) standard, each SOAP message stands alone
and can have uniquely applied security. The standard includes mechanisms for
encrypting any content in the message at a very fine-grain level. For example, rather
plying a cipher to the entire message, only those parts that are deemed
necessary to cryptographically secure are encrypted. The public parts of a message (such as the header fields that
ermediate in making a routing decision) can be left in the clear.
Since any part of a SOAP message is subject to modification by an attacker as it traverses potentially hostile
anism for signing message content with a granularity that is identical to
encryption. For example, not only can a message author encrypt the credit card element, but they can also sign it
to ensure that no substitution in transit goes undetected. The same protection can be extended to unencrypted
c elements, such as timestamps inserted into the header.
Web Services Security Requires PKI WSS goes to great lengths to remain flexible with potential encryption/signing technologies. But even though it is
compliant system based on shared secrets that are exchanged out-of-band of the WSS
specification, this disqualifies a transaction from any claims to non-repudiation, as well as subjecting it to a toxic
list of potential security flaws. As a result, it’s difficult to find a vendor’s WSS implementation that is not based on
more, most organizations are building systems predicated on having key pairs on both sides of a
transaction: at the message producer (client) and the message consumer (server) sides, necessitating PKI.
An Example of PKI in Web Services
SecureSpan and the Layer 7 Technologies design mark are
yrights are the property of their respective owners. 4
SIS) and the World
services security problem is to absorb security
into the message itself. That is, provide a means of authentication, integrity, and
confidentiality that is integral to the message and completely decoupled from
ity remains consistent and trustworthy
Peer (P2P) network using pro-
prietary protocols, is persisted to a file, or printed onto a piece of paper. A security
saging has great architectural
In the Oasis Web Services Security (WSS) standard, each SOAP message stands alone
and can have uniquely applied security. The standard includes mechanisms for
grain level. For example, rather
plying a cipher to the entire message, only those parts that are deemed
necessary to cryptographically secure are encrypted. The public parts of a message (such as the header fields that
tacker as it traverses potentially hostile
arity that is identical to
encryption. For example, not only can a message author encrypt the credit card element, but they can also sign it
to ensure that no substitution in transit goes undetected. The same protection can be extended to unencrypted
WSS goes to great lengths to remain flexible with potential encryption/signing technologies. But even though it is
band of the WSS
repudiation, as well as subjecting it to a toxic
s WSS implementation that is not based on
more, most organizations are building systems predicated on having key pairs on both sides of a
transaction: at the message producer (client) and the message consumer (server) sides, necessitating PKI.
Web Services and PKI
Copyright © 2010 Layer 7 Technologies Inc. All rights reserved.
trademarks of Layer 7 Technologies Inc.
PKI is essential to a typical WSS implementation. In the session
message is secured for transmission between two parties that do not share a pre
token. Therefore, there is no shared secret, such as a key used for symmetric encryption and Hashed Message
Authentication Code (HMAC) signing between the producer and the consumer. Emerging standards, such as WS
Secure Conversation and WS-Trust, provide for negotiated security tokens and define well
mechanisms similar to SSL’s session key scheme. In the current scenario, however, a message can be secured
directly using only the key pair and certificate held by the producer and t
In the second scenario illustrated in Figure 2, a simplified message is exchanged between the producer and the
consumer. The message body has been encrypted using a two
generates a random symmetric key with which the body content is encrypted using a symmetric algorithm like
triple-DES or AES. A specialized security header describes the exact algorithm and key length. Contrast this
approach with SSL, which supports negotiation of cipher suites and key lengths in order to accommodate a
diversity of clients, any of whom may be subject to cryptography export restrictions. Here, we assume a prior out
of-band agreement on cipher capabilities.
ogies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective
PKI is essential to a typical WSS implementation. In the session-less scenario illustrated in Figure 1, a single
message is secured for transmission between two parties that do not share a pre-negotiated, temporary secu
token. Therefore, there is no shared secret, such as a key used for symmetric encryption and Hashed Message
ing between the producer and the consumer. Emerging standards, such as WS
ovide for negotiated security tokens and define well-known key derivation
mechanisms similar to SSL’s session key scheme. In the current scenario, however, a message can be secured
directly using only the key pair and certificate held by the producer and the certificate for the consumer.
In the second scenario illustrated in Figure 2, a simplified message is exchanged between the producer and the
consumer. The message body has been encrypted using a two-step process described in WSS. First, the
generates a random symmetric key with which the body content is encrypted using a symmetric algorithm like
DES or AES. A specialized security header describes the exact algorithm and key length. Contrast this
ts negotiation of cipher suites and key lengths in order to accommodate a
diversity of clients, any of whom may be subject to cryptography export restrictions. Here, we assume a prior out
band agreement on cipher capabilities.
SecureSpan and the Layer 7 Technologies design mark are
yrights are the property of their respective owners. 5
less scenario illustrated in Figure 1, a single
negotiated, temporary security
token. Therefore, there is no shared secret, such as a key used for symmetric encryption and Hashed Message
ing between the producer and the consumer. Emerging standards, such as WS-
known key derivation
mechanisms similar to SSL’s session key scheme. In the current scenario, however, a message can be secured
he certificate for the consumer.
In the second scenario illustrated in Figure 2, a simplified message is exchanged between the producer and the
cess described in WSS. First, the producer
generates a random symmetric key with which the body content is encrypted using a symmetric algorithm like
DES or AES. A specialized security header describes the exact algorithm and key length. Contrast this
ts negotiation of cipher suites and key lengths in order to accommodate a
diversity of clients, any of whom may be subject to cryptography export restrictions. Here, we assume a prior out-
Web Services and PKI
Copyright © 2010 Layer 7 Technologies Inc. All rights reserved.
trademarks of Layer 7 Technologies Inc.
How does this shared secret become shared? The producer encrypts the symmetric key with
key, ensuring only that party can decrypt the message. This encrypted key is embedded in the security header with
a reference to the key pair needed to unlock it (often th
the receiver’s certificate). In the security header, anyone can read the encrypted key, but only the designat
receiver can decrypt it and use it to decipher the message content. Thus, no comp
required to negotiate a security session key. Each message stands alone.
Encryption, however, is only a component of the security story, albeit an important
one. As it stands, the encrypted message body is subject to substitution by a
malicious party, as are critical header field
necessary for servers to uniquely identify messages and apply an effective replay
defense. Furthermore, the consumer has no means to authenticate the message
producer because encryption for a particular receiver does not i
To address this shortcoming, the message producer takes the encrypted message
body and critical header fields and places these into yet an
security header. It signs this block, aggregating the components into a singl
simultaneous integrity/origin authentication statement. The producer includes its
certificate (or a reference to it) in the security header so that the receiver can
validate the signature and follow any certificate chain in the certificate to a trust
anchor. Now, the consumer can have confidence that a specific producer authored
the message, that it was not altered in transit, and most importantly, that it was designated specifically for this
consumer.
What is important to recognize here is that all par
Without PKI, the model does not work.
Conclusion Web services is a great opportunity for PKI and a great challenge. Most vendors’ toolkits have a deliberately vague
coupling to commercial PKI systems. As always, it is what the standards loosely describe that becomes the source
of problems. Interfacing to a particular key store type or location and coercing servers to check Certificate
Revocation Lists (CRLs) or use Online Certificate Status
proactively, rolling out your PKI system before its services are demanded by a Web services application. The
demand will come because, while SSL is sufficient for synchronous client
depends on asynchronous messaging, which is where PKI will shine.
With PKI, the encrypted key and reference to its key pair is embedded in
each Web service message’s security
header, allowing each message to be
validated individually by a new class of XML
firewalls
ogies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective
et become shared? The producer encrypts the symmetric key with the consumer’s public
key, ensuring only that party can decrypt the message. This encrypted key is embedded in the security header with
a reference to the key pair needed to unlock it (often this is implemented using the subject key identifier field from
the receiver’s certificate). In the security header, anyone can read the encrypted key, but only the designat
receiver can decrypt it and use it to decipher the message content. Thus, no complex multi-pass protocol is
required to negotiate a security session key. Each message stands alone.
Encryption, however, is only a component of the security story, albeit an important
one. As it stands, the encrypted message body is subject to substitution by a
malicious party, as are critical header fields such as the timestamp, which is
necessary for servers to uniquely identify messages and apply an effective replay
defense. Furthermore, the consumer has no means to authenticate the message
producer because encryption for a particular receiver does not i
To address this shortcoming, the message producer takes the encrypted message
body and critical header fields and places these into yet another block in the
security header. It signs this block, aggregating the components into a singl
simultaneous integrity/origin authentication statement. The producer includes its
certificate (or a reference to it) in the security header so that the receiver can
validate the signature and follow any certificate chain in the certificate to a trust
chor. Now, the consumer can have confidence that a specific producer authored
the message, that it was not altered in transit, and most importantly, that it was designated specifically for this
What is important to recognize here is that all parties in the transaction scenario have key pairs and certificates.
Without PKI, the model does not work.
Web services is a great opportunity for PKI and a great challenge. Most vendors’ toolkits have a deliberately vague
KI systems. As always, it is what the standards loosely describe that becomes the source
of problems. Interfacing to a particular key store type or location and coercing servers to check Certificate
Revocation Lists (CRLs) or use Online Certificate Status Protocol (OCSP) can be troublesome. It is best to start
proactively, rolling out your PKI system before its services are demanded by a Web services application. The
demand will come because, while SSL is sufficient for synchronous client-server applications, Web services
on asynchronous messaging, which is where PKI will shine.
SecureSpan and the Layer 7 Technologies design mark are
yrights are the property of their respective owners. 6
the consumer’s public
key, ensuring only that party can decrypt the message. This encrypted key is embedded in the security header with
is is implemented using the subject key identifier field from
the receiver’s certificate). In the security header, anyone can read the encrypted key, but only the designated
pass protocol is
Encryption, however, is only a component of the security story, albeit an important
one. As it stands, the encrypted message body is subject to substitution by a
s such as the timestamp, which is
necessary for servers to uniquely identify messages and apply an effective replay
defense. Furthermore, the consumer has no means to authenticate the message
producer because encryption for a particular receiver does not identify the author.
To address this shortcoming, the message producer takes the encrypted message
other block in the
security header. It signs this block, aggregating the components into a single,
simultaneous integrity/origin authentication statement. The producer includes its
certificate (or a reference to it) in the security header so that the receiver can
validate the signature and follow any certificate chain in the certificate to a trust
chor. Now, the consumer can have confidence that a specific producer authored
the message, that it was not altered in transit, and most importantly, that it was designated specifically for this
ties in the transaction scenario have key pairs and certificates.
Web services is a great opportunity for PKI and a great challenge. Most vendors’ toolkits have a deliberately vague
KI systems. As always, it is what the standards loosely describe that becomes the source
of problems. Interfacing to a particular key store type or location and coercing servers to check Certificate
Protocol (OCSP) can be troublesome. It is best to start
proactively, rolling out your PKI system before its services are demanded by a Web services application. The
s, Web services
Web Services and PKI
Copyright © 2010 Layer 7 Technologies Inc. All rights reserved.
trademarks of Layer 7 Technologies Inc.
About Layer 7 TechnologiesWith offices in San Mateo, California; New York, New York; and Vancouver, British Columbia, Canada; Layer 7
Technologies helps enterprises accomplish secure and cost
services. Layer 7 Technologies’ SecureSpan™ Solution is the first technology that addresses security and
governance across a Web services integration without expensive and inflexib
SecureSpan™ Solution, customers realize lowered integration costs, increased security reliability, and the ability to
future-proof their Web services investments. Contact Layer 7 Technologies or visit www.layer7tech.com for more
information.
Contact Layer 7 TechnologiesLayer 7 Technologies welcomes your questions, comments, and general feedback.
Email: info@layer7tech.com
Web Site: www.layer7tech.com
Phone: 604-681-9377
1-800-681-9377 (toll free)
Fax: 604-681-9387
Address: US Office
1200 G Street, NW, Suite 800
Washington, DC 20005
Canada Office
Suite 405-1100 Melville Street
Vancouver, BC
V6E 4A6 Canada
Legal Information Copyright © 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.
SecureSpan™ is a registered trademark of Layer 7 Technologies, Inc. All other mentioned trade names and/or
trademarks are the property of their respective owne
ogies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective
About Layer 7 Technologies With offices in San Mateo, California; New York, New York; and Vancouver, British Columbia, Canada; Layer 7
accomplish secure and cost-effective business integration using XML and Web
services. Layer 7 Technologies’ SecureSpan™ Solution is the first technology that addresses security and
governance across a Web services integration without expensive and inflexible programming. With the
SecureSpan™ Solution, customers realize lowered integration costs, increased security reliability, and the ability to
proof their Web services investments. Contact Layer 7 Technologies or visit www.layer7tech.com for more
Contact Layer 7 Technologies Layer 7 Technologies welcomes your questions, comments, and general feedback.
by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.
SecureSpan™ is a registered trademark of Layer 7 Technologies, Inc. All other mentioned trade names and/or
trademarks are the property of their respective owners.
SecureSpan and the Layer 7 Technologies design mark are
yrights are the property of their respective owners. 7
With offices in San Mateo, California; New York, New York; and Vancouver, British Columbia, Canada; Layer 7
effective business integration using XML and Web
services. Layer 7 Technologies’ SecureSpan™ Solution is the first technology that addresses security and
le programming. With the
SecureSpan™ Solution, customers realize lowered integration costs, increased security reliability, and the ability to
proof their Web services investments. Contact Layer 7 Technologies or visit www.layer7tech.com for more
by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.
SecureSpan™ is a registered trademark of Layer 7 Technologies, Inc. All other mentioned trade names and/or
top related