The boundary of interaction between communicating partners is expected to expand from intranets to the Internet. For example, businesses increasingly expect to perform some transactions over the Internet with their trading partners using Web services. Obviously, from a security perspective, Internet communication is much less protected than intranet communication.
Communicating partners are more likely to interact with each other without establishing a business or human relationship first. This means that all security requirements such as authentication, access control, nonrepudiation, data integrity, and privacy must be addressed by the underlying security technology.
More and more interactions are expected to occur from programs to programs rather than from humans to programs. Therefore, the interaction between communicating partners using Web services is anticipated to be more dynamic and instantaneous.
Finally, as more and more business functions are exposed as Web services, the sheer number of participants in a Web services environment will be larger than what we have seen in other environments.
Currently, the most common security scheme available for today's Web services is SSL (Secure Socket Layer), which is typically used with HTTP. Despite its popularity, SSL has some limitations when it comes to Web services. Thus, various XML-based security initiatives are in the works to address Web services' unique needs. This article examines those schemes.
SSL limitations
First, SSL is designed to provide point-to-point security, which falls short for Web services because we need end-to-end security, where multiple intermediary nodes could exist between the two endpoints. In a typical Web services environment where XML-based business documents rout through multiple intermediary nodes, it proves difficult for those intermediary nodes to participate in security operations in an integrated fashion.
Second, SSL secures communication at transport level rather than at message level. As a result, messages are protected only while in transit on the wire. For example, sensitive data on your hard disk drive is not generally protected unless you apply a proprietary encryption technology.
Third, HTTPS in its current form does not support nonrepudiation well. Nonrepudiation is critical for business Web services and, for that matter, any business transaction. What is nonrepudiation? Nonrepudiation means that a communicating partner can prove that the other party has performed a particular transaction. For example, if E-Trade received a stock transaction order from one of its clients and performed the transaction on behalf of that client, E-Trade wants to ensure it can prove it completed that transaction to an arbitration committee, for example, if a dispute arises. We need some level of nonrepudiation for Web services-based transactions.
Finally, SSL does not provide element-wise signing and encryption. For example, if you have a large purchase order XML document, yet you want to only sign or encrypt a credit card element, signing or encrypting only that element with SSL proves rather difficult. Again, that is due to the fact that SSL is a transport-level security scheme as opposed to a message-level scheme.
During the past few years, the technology industry has been working on various XML-based security schemes to provide comprehensive and unified security schemes for Web services. These schemes include:
XML digital signature
XML Encryption
XKMS (XML Key Management Specification)
XACML (Extensible Access Control Markup Language)
SAML (Secure Assertion Markup Language)
WS-Security (Web Services Security)
ebXML Message Service
The Liberty Alliance Project
In this article, I define each of these security initiatives, why each is important, and how they all can work together.
XML digital signature
XML digital signature, like any other digital signing technology, provides authentication, data integrity (tamper-proofing), and nonrepudiation. Of all the XML-based security initiatives, the XML digital signature effort is the furthest along. The W3C (World Wide Web Consortium) and the IETF (Internet Engineering Task Force) jointly coordinate this effort. The project aims to develop XML syntax for representing digital signatures over any data type. The XML digital signature specification also defines procedures for computing and verifying such signatures.
Another important area that XML digital signature addresses is the canonicalization of XML documents. Canonicalization enables the generation of the identical message digest and thus identical digital signatures for XML documents that are syntactically equivalent but different in appearance due to, for example, a different number of white spaces present in the documents.
So why XML digital signature? XML digital signature provides a flexible means of signing and supports diverse sets of Internet transaction models. For example, you can sign individual items or multiple items of an XML document. The document you sign can be local or even a remote object, as long as those objects can be referenced through a URI (Uniform Resource Identifier). You can sign not only XML data, but also non-XML data. A signature can be either enveloped or enveloping, which means the signature can be either embedded in a document being signed or reside outside the document.
XML digital signature also allows multiple signing levels for the same content, thus allowing flexible signing semantics. For example, the same content can be semantically signed, cosigned, witnessed, and notarized by different people.
What is XML Encryption?
The W3C is also coordinating XML Encryption. Its goal is to develop XML syntax for representing encrypted data and to establish procedures for encrypting and decrypting such data. Unlike SSL, with XML Encryption, you can encrypt only the data that needs to be encrypted, for example, only the credit card information in a purchase order XML document:
<purchaseOrder>
<name>Alice Smith</name>
<address> ... </address>
<EncryptedData xmlns='http://www.w3.org/2000/11/temp-xmlenc'>
<EncryptionMethod Algorithm="urn:nist-gov:tripledes-ede-cbc">
<s0:IV xmlns:s0='http://somens'>ABCD</s0:IV>
</EncryptionMethod>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>SharedKey</KeyName>
</KeyInfo>
<CipherData>A23B45C56</CipherData>
</EncryptedData>
<prodNumber>8a32gh19908</prodNumber>
<quantity>1</quantity>
</purchaseOrder>
XKMS
XKMS stands for the XML Key Management Specification and consists of two parts: XKISS (XML Key Information Service Specification) and XKRSS (XML Key Registration Service Specification). XKISS defines a protocol for resolving or validating public keys contained in signed and encrypted XML documents, while XKRSS defines a protocol for public key registration, revocation, and recovery. The key aspect of XKMS is that it serves as a protocol specification between an XKMS client and an XKMS server in which the XKMS server provides trust services to its clients (in the form of Web services) by performing various PKI (public key infrastructure) operations, such as public key validation, registration, recovery, and revocation on behalf of the clients.
Now let's talk about why we need XKMS. To explain it, I must discuss PKI first. PKI proves important for e-commerce and Web services. However, one of the obstacles to PKI's wide adoption is that PKI operations such as public key validation, registration, recovery, and revocation are complex and require large amounts of computing resources, which prevents some applications and small devices such as cell phones from participating in PKI-based e-commerce or Web services transactions.
XKMS enables an XKMS server to perform these PKI operations. In other words, applications and small devices, by sending XKMS messages over SOAP (Simple Object Access Protocol), can ask the XKMS server to perform the PKI operations. In this regard, the XKMS server provides trust services to its clients in the form of Web services.
XACML
XACML stands for Extensible Access Control Markup Language, and its primary goal is to standardize access control language in XML syntax. A standard access control language results in lower costs because there is no need to develop an application-specific access control language or write the access control policy in multiple languages. Plus, system administrators need to understand only one language. With XACML, it is also possible to compose access control policies from the ones created by different parties.
SAML
Next up is the Security Assertions Markup Language effort, or SAML, which is being defined by the OASIS (Organization for the Advancement of Structured Information) security services technical committee. The committee aims to outline a standard XML framework for exchanging authentication and authorization information.
In a nutshell, SAML is an XML-based framework for exchanging security information. As a framework, it deals with three things. First, it defines syntax and semantics of XML-encoded assertion messages. Second, it defines request and response protocols between requesting and asserting parties for exchanging security information. Third, it defines rules for using assertions with standard transport and message frameworks. For example, it defines how SAML assertion messages can transport using SOAP over HTTP.
SAML use-cases
The SAML specification developed three use-case scenarios to drive its requirements and design: single sign-on, distributed transaction, and an authorization service.
Figure 1 shows how SAML is used to enable single sign-on.
Figure 1. SAML single sign-on use-case
Suppose a user logs in to Smith.com and is authenticated. Later, the same user accesses Johns.com. Without single sign-on, the user would typically have to reenter his user identity information to Johns.com. Under the SAML scheme, by sending an SAML assertion request message, Johns.com can ask Smith.com if the user has already been authenticated. Smith.com then sends back an SAML assertion statement indicating that the user in fact has been authenticated. Once Johns.com receives the SAML assertion statement, it allows the user to access its resources without asking the user to reenter his identity information.
Figure 2 illustrates a distributed transaction use-case.
Figure 2. Distributed transaction use-case of SAML
In this case, let's say a user buys a car from Cars.com. The same user then decides to buy automobile insurance from Insurance.com. Now, when the user goes to Insurance.com to buy insurance, the user's profile such as name, address, and credit history, which Cars.com has already collected, can pass to Insurance.com. In this case, Insurance.com sends an SAML assertion request, such as, "Send me user profile information," to Cars.com, and Cars.com sends all the user profile information it knows to Insurance.com in SAML assertion statements.
Figure 3 shows a SAML use-case for an authorization service.
Figure 3. Authorization service use-case of SAML
Let's say a Works.com employee named Sang wants to order million worth of furniture from Office.com, Works.com's preferred furniture supplier. When Office.com receives the purchase order from Sang, obviously it wants to know if Sang is authorized to complete the order and, if so, the maximum dollar limit he can spend. So in this scenario, when Office.com receives a purchase order from Sang, it sends an SAML assertion request message to Works.com, which then sends back an SAML assertion indicating that Sang in fact is allowed to order the furniture, but the maximum amount he can spend is ,000.
SAML assertions
I already briefly touched on SAML assertions, which are XML documents containing security information. Formally, an SAML assertion is defined as someone's declaration of fact. SAML assertions include one or more of three kinds of statements about a subject, which can be either a human being or program entity. The three kinds of statements are:
Authentication statement
Attribute statement
Authorization statement
POPULAR ON JAVAWORLD
lightbulb
Git smart! 20 essential tips for Git and GitHub users
The wait is over: JDK 8 is here!
javascript words
Code in JavaScript the smart, modular way
Now let's look at each of the different kinds of SAML statements in more detail.
Authentication statement
An authentication statement basically says that an issuing authority (asserting party) asserts that a subject S was authenticated by M's authentication means at time T. As you probably guessed, the authentication statement is used to enable single sign-on.
Listing 1 shows an example of an SAML assertion containing an authentication statement:
Listing 1. SAML assertion containing an authentication statement
<saml:Assertion ...>
<saml:AuthenticationStatement
AuthenticationMethod="password" (By means M)
AuthenticationInstant="2001-12-03T10:02:00Z">(At time T)
<saml:Subject> (Subject S)
<saml:NameIdentifier
SecurityDomain="sun.com"
Name="Sang" />
<saml:ConfirmationMethod>
http://...core-25/sender-vouches
</saml:ConfirmationMethod>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
In Listing 1, the authentication statement says that a subject called Sang in security domain of sun.com has been authenticated at some time on December 3, 2001. The means of authentication is the entering of username and password.
Attribute statement
An attribute SAML statement indicates that an issuing author asserts that a subject S is associated with attributes A, B, and so on, with corresponding values a, b, and so on. An attribute statement is useful for distributed transactions and authorized services.
Listing 2 illustrates an SAML assertion that contains two attribute statements:
Listing 2. SAML statement with attribute statements
<saml:Assertion ...>
<saml:AttributeStatement>
<saml:Subject>..Sang..</saml:Subject>
<saml:Attribute
AttributeName="PaidStatus" (attribute A)
AttributeNamespace="http://smithco.com">
<saml:AttributeValue> (with value a)
PaidUp
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute
AttributeName="CreditLimit" (attribute B)
AttributeNamespace="http://smithco.com">
<saml:AttributeValue> (with value b)
<my:amount currency="USD">500.00
</my:amount>
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
Listing 2 contains two attribute statements for a subject Sang. The first attribute has the name PaidStatus, with corresponding value paidup. The second attribute has the name CreditLimit, with corresponding value of 500.00. This assertion could be used for the third use-case, where a Works.com employee tries to purchase million worth of chairs from Office.com.
Authorization statement
An authorization statement is the third kind of SAML assertion statement. This type of statement says that an issuing authority decides whether to grant the request by subject S for access type A to resource R, given evidence E presented by the requesting party. The resource can be a Web service or Webpage.
Listing 3 shows an SAML assertion containing an authorization statement:
Listing 3. Authorization statement in an SAML assertion
<saml:Assertion ...>
<saml:AuthorizationStatement
Decision="Permit" (Whether to grant request)
Resource="http://jonesco.com/rpt_12345.html"> (for res. R)
<saml:Subject>... Sang ...</saml:Subject> (by Subject S)
<saml:Actions
ActionNamespace="http://...core-25/rwedc">
<saml:Action>Read</saml:Action> (for access type A)
</saml:Actions>
</saml:AuthorizationStatement>
</saml:Assertion>
Listing 3's SAML assertion contains a single authorization statement. The resource is a Webpage whose address is http://jonesco.com/rpt_12345.html. In this example, after receiving an SAML assertion request message with some kind of evidence E, an asserting party grants the request, indicating that the subject Sang can read the Webpage.
SAML request/response protocol
Figure 4 shows the simple request and respond communication model between the relying and asserting parties.
Figure 4. SAML request/response protocol
The relying party is sometimes called the requesting party, while the asserting party is called the issuing party. The relying party sends SAML assertion request messages, and the asserting party, in response, sends back SAML assertion responses. The examples of SAML assertion statements you have seen in this article are in fact SAML assertion response messages.
WS-Security
The WS-Security (Web Services Security) specification defines a set of SOAP header extensions for end-to-end SOAP messaging security. It supports message integrity and confidentiality by allowing communicating partners to exchange signed and encrypted messages in a Web services environment. Because it is based on XML digital signature and XML Encryption standards, you can digitally sign and encrypt any combination of message parts. WS-Security supports multiple security models, such as username/password-based and certificate-based models.
It also supports multiple security technologies, including Kerberos, PKI, SAML, and so on. In addition, it supports multiple security tokens; for example, tokens that contain Kerberos tickets, X.509 certificates, or SAML assertions.
ebXML Message Service
The ebXML initiative is a set of next-generation XML-based standards enabling electronic business transactions via the Internet. One of the ebXML standards is ebXML Message Service, which defines how to securely and reliably send and receive SOAP messages. Figure 5 illustrates the ebXML Message Service security architecture.
Figure 5. ebXML Message Service security architecture
How the initiatives work together
Now let's talk about how these standards would work together. The SAML assertions can be digitally signed using XML digital signature. The same assertions can be encrypted using XML Encryption to ensure privacy. The public key used for digital signing and encryption can be validated and registered via XKMS. As for XACML, an SAML asserting party could use it to define an access control policy as a basis for handling SAML-based assertion requests.
Figure 6 illustrates how SAML works with other XML security standards.
Figure 6. How Web services security standards work together
On the left side of the diagram, Alice uses XML digital signature and encryption to digitally sign and encrypt the purchase order XML document. She then sends the document to her supplier, perhaps using SOAP, whose header structure is defined either in the WS-Security or ebXML Message Service standard. The document's receiver then could use XKMS to look up and validate Alice's public key. Once the key is determined trustworthy, the receiver then validates and decrypts the purchase order. Finally, the receiver checks a policy server for authorization by sending and receiving SAML requests and responses. The policy server might maintain the access control policy information in XACML.
FEATURED RESOURCE
Presented by Zero Turnaround
Coding with JRebel: Java Forever Changed
With JRebel, developers get to see their code changes immediately, fine-tune their code with
LEARN MORE
YOU MIGHT ALSO LIKE
Heroku joins other PaaS providers in supporting PHP
Open source Java projects: Spring Integration
on target
Which vendors will be on target in the era of New IT
Daily updates on enterprise Java news, tips and techniques
So far, I have focused this discussion on XML-based Web services standards. Next, I talk about identity and identity management architecture.
Why identity management architecture?
So what is identity? Identity is a set of attributes that describes a profile of an individual, business organization, or software entity. The set of attributes for an individual, for example, could include driver's license, social security number, travel preferences, medical history, financial data, and so on.
What is the consequence of lacking a well-integrated and interoperable identity management architecture? Silos of identity, which is the state of the consumer Web today. In this state, which I call a state of identity crisis, each site has its own authentication method, and its own method of maintaining identity information and user profiles. Each site has inconsistent schemes for accessing and editing identity information. And each site has unclear and/or differing policy and privacy statements. Few, if any, silo identity systems truly interoperate.
This situation is not limited to consumer Websites. The same can be said of an enterprise. Distinct identities and logins exist for building access, workstation login, application access, and remote access. Different applications require the user to reenter username and password, which don't interoperate. This makes managing Web properties, applications, identities, and policies nonscalable, and effectively prohibits the interaction (or even the association) of identities across applications or Web services.
Figure 7 shows two possible identity management architectures, one based on a centralized model and the other, on a federated model.
Figure 7. Two possible identity management architectures
In the centralized model, a single operator performs authentication and authorization by owning and controlling all the identity information. In the federated model, both authentication and authorization tasks are distributed among federated communities.
One advantage of the centralized model is that, because a single operator owns and controls everything, constructing and managing the identity network could be easier than with the federated model. However, the centralized model has serious downsides. The most serious one is the dangerous potential for the single operator becoming a tollgate for all transactions over the Internet. For example, the operator might charge a fee for every transaction you make. You might have to pay a few cents or dollars whenever you perform a transaction on eBay.
The centralized model has another serious problem: the single operator could represent a single point of security failure or hacker attack. One more reason why the centralized model has not garnered any support, especially from the business community, is because a single operator can take away the most important business asset—that is, customer identity and profile information—from an organization. That results in a serious threat to businesses such as banks and brokerage houses whose success depends on their customer information. This information represents one of the most critical assets to a business, one it is not willing to give up to a third party.
The federated model, driven by the Liberty Alliance Project, is designed to correct the centralized model's problems. The goal of the Liberty Alliance Project is to create an open standard for identity, authentication, and authorization, which will lower e-commerce costs and accelerate organizations' commercial opportunities, while at the same time increasing customer satisfaction. In a Liberty architecture, organizations can maintain their own customer/employee data while sharing identity data with partners based on their business objectives and customer preferences.
Figure 8. Roles in federated identity management architecture
As illustrated in Figure 8, in the federated identity management architecture scheme, three roles could exist. The first is the role of a consumer. As a consumer, you can have multiple identity profiles, and you can ask different identity providers to maintain these profiles. For example, you might want your HMO to manage your healthcare profile and your brokerage house to maintain your brokerage profile. In fact, as a consumer, you can pick and choose which identity provider to maintain your profile based on price, credibility, service, and so on. In this model, consumers have a final say in terms of who can access what information. Consumers can be a person, a business, or a software entity.
In this case, the HMO and brokerage house play the role of identity provider. Identity providers maintain user profile information and can interoperate among themselves as long as they have permission to do so from the profile's owner, the consumer. Identity providers are expected to compete for your business in the future in the same way HMOs, banks, and brokerage houses compete for your business today.
The third role is that of the service provider, the merchant who has services to offer consumers. Service providers can customize their services to each consumer by retrieving relevant identity profiles from the identity providers. For example, your travel agent might discover your travel and dining preferences from the identity provider you designated to maintain your travel preference.
Figure 9 shows how a federated identity network is expected to evolve.
Figure 9. Evolution of identity networks
In the first picture, a phase with no federation, a consumer must log in separately to each site. This phase will then evolve into an environment where multiple identity networks exist. Within a single identity network, single sign-on can be achieved. However, no network-to-network identity propagation is available at this stage.
Eventually, these individually constructed and operating identity networks will work together by exchanging their consumers' identity information, thus providing a truly seamless, global-scale identity network, the Liberty Alliance Project's ultimate goal.
Figure 10. Analogy to ATM networks
As illustrated in Figure 10, the ATM network serves as an analogy for the federated network. Initially, individual banks issued their own ATM cards, and different banks did not interoperate. At this stage, you could not use your ATM card in an ATM machine owned and operated by another bank. These days, you can use your credit card or ATM card in any ATM machine, as long as the bank that owns the machine and your bank are members of the same affiliation network. In the not too distant future, it is not a stretch to think about a single global network to which all banks directly or indirectly belong. The identity network should evolve similarly.
One possible challenge of the federated identity network model is that because there are many parties involved, the standard has to be defined in an unambiguous manner. The Liberty Alliance Project addresses that challenge.
Ensure secure transmissions
As more and more business organizations adopt Web services, ensuring secure communication between communicating partners is becoming even more important. In this article, I explained why SSL falls short when it comes to Web services and why the industry is actively defining XML-based Web services security schemes. I also discussed the importance of an identity network and how it can be implemented. Any developer interested in creating Web services should be aware of these standards.
Learn more about this topic
- Information on XML digital signature
http://www.w3.org/Signature - Information on XML Encryption
http://www.w3.org/Encryption - Information on XKMS
http://www.w3.org/TR/xkms/ - Information on SAML
http://oasis-open.org/committees/security - Information on XACML
http://www.oasis-open.org/committees/xacml/ - Information on WS-Security
http://www.oasis-open.org/committees/wss/ - Information on the Liberty Alliance Project
http://www.projectliberty.org - Sang Shin's Web services programming class
http://www.plurb.com/webservices - Sang Shin's XML class
http://groups.yahoo.com/group/xmlpdffiles/files/index.html - For detailed information on XML Encryption and XML digital signature, see "Yes, You Can Secure Your Web Services Documents," Ray Djajadinata (JavaWorld):
- For more articles on Web services, see the following JavaWorld resources
-
- The Java and Web Services section of JavaWorld's Topical Index
http://www.javaworld.com/channel_content/jw-webserv-index.shtml - Frank Sommers's Web Services column
http://www.javaworld.com/columns/jw-web-services-index.shtml
- The Java and Web Services section of JavaWorld's Topical Index
- Browse the Security section of JavaWorld's Topical Index
http://www.javaworld.com/channel_content/jw-security-index.shtml - Talk more about securing Web services in JavaWorld's Java Security discussion
http://forums.devworld.com/webx?50@@.ee6b80e - Sign up for JavaWorld's free weekly email newsletters
http://www.javaworld.com/subscribe - You'll find a wealth of IT-related articles from our sister publications at IDG.net
4660
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
