SOA security solution

ArticleDirectory

• SOAP message monitoring
• SAML and Federated identity verification
• Application proxy
• Contract Management
• Certificates, keys, and encryption
• XML Encryption
• Digital Signature
• Protection and audit of replay attacks
• The advice provided by wise managers: do not let security scare you
• Conclusion

Article from: http://dev2dev.bea.com.cn/techdoc/20060720848.html

This article describes the security solution in a loosely coupled SOA environment.

Since we have talked about the security issues in SOA in that article, and everyone needs this information, it is time to consider some solutions to these problems. Simply put, for SOA security issues, you need to purchase or develop a security solution for your SOA. In details, it depends on the specific situation and is very complicated. However, a well-designed SOA security solution can solve most security problems in SOA. The solution itself can contain multiple sub-solutions that specifically address a specific aspect of SOA security. Different enterprises need different solutions based on their specific needs and existing security infrastructure.

Let me repeat it again: My goal is to provide a way to evaluate how security affects SOA planning. I am a SOA security product provider. In addition, you will feel some of my preferences for the solution. At the same time, you should be aware that I am competing with many other companies that implement SOA security in the same way. In fact, the market has proved that some SOA security solutions are better than other similar products.

SOAP message monitoring

SOA message monitoring based on soap listening is a basic means to build an efficient SOA security solution. Soap listening

Figure 1 A soap Interceptor Used to monitor soap messages serves as the security basis in this SOA. The soap interceptor analyzes the user identity contained in the header of the SOAP message it monitors and compares it with the name saved in the existing security infrastructure. The result is that the sender and receiver of the SOAP message are authenticated and authorized.

A special software block called "Soap Interceptor" is placed in the path of the SOAP message transmitted back and forth between the Web service consumer and the web service. Because of its ability to classify, monitor, copy, and forward soap messages containing large amounts of data, the soap interceptor can play a major role in SOA security. As shown in figure 7, an SOA security solution "monitors" Soap call messages arriving at web services and responses to these service calls. When it "sees" a message, the SOA security solution checks to ensure that the requested entity is authenticated and authorized to use the web service. The SOA security solution implements this by checking the data contained in the SOAP message header.

In most cases, the SOA security solution extends the existing security solution, and the existing security solution is deployed to protect the entire enterprise before it is migrated to SOA. Therefore, the SOA security solution may have to connect and communicate with the existing security infrastructure. 7. As shown in, user authentication and authorization in SOA occur when the enterprise-based authorized user database checks the user certificate. Listen to soap messages and compare the users listed in the message header with those saved in the existing security infrastructure to implement authentication and authorization.

SAML and Federated identity verification

What happens when you need to authenticate and authorize SOA users outside the enterprise? The openness of SOA makes the above situation more likely than ever before. You may face the challenge of figuring out the identity of each user in a group of users not recorded in the existing security infrastructure. To address security issues inherent in the protection of third-party processes, SOA security solutions can use federal authentication. Federated identity authentication is a process in which multiple parties can reach an agreement that uses a set of given standards to authenticate a group of specified users. Federated identity management system (Federated identity management system) can be created by users of Federated identity authentication methods. This is a database of authenticated users. SOA security solutions can verify the identity of a user by checking the federal identity management system. In other words, the "Federated" of some communication systems can agree that a user is legal.

In some cases, the authentication process may cause Security Assertion Markup Language (SAML) Assertions to be created in the SOA security solution, it is used to express the authenticity of a user in a way that can be accepted by a Web service called by the user. SAML is an XML-based standard that provides a framework for describing security information in a standard way. WS-Security is a general term for a set of security standards that have been recognized so far. Many SOA security solutions use these emerging security standards. As shown in figure 8, the SOA security solution can listen to soap messages and then perform authentication on users. Next, the SOA security solution transmits the SOAP message to the target Web service, but attaches a SAML assertion. Note: SAML assertions do not depend on the federal authentication process.

Figure 2 to use federal authentication in SOA security, the soap interceptor must forward incoming soap messages to the security solution, this security solution then matches the user identities contained in the SOAP message header with those listed in the federal Authentication database. If the matching succeeds, the SOA security solution creates a security "assertion" that the user has passed the authentication in the Security Assertion Markup Language document, this document is attached to the SOAP message when the SOAP message arrives at the Web service to be called.

Application Program Proxy

A very effective way to protect the core system is to prevent anyone from accessing the services hosted on the platform. You can do this by deploying a proxy for the Web service in SOA. 9. A protected proxy can receive and respond to all web service requests on behalf of the actual web service, thus protecting the Web service from malicious attacks. Another benefit of the proxy method is that it can reduce the burden on the enterprise security infrastructure. The proxy can reduce network traffic by centrally managing and caching the authentication and authorization of Web Service requests, instead of every time a user wants to call a web service, the user is authenticated and authorized by using a large number of messages on the network. The proxy also inserts authentication and authorization SAML assertions in the message, eliminating the need for the actual web service to directly query the security system.

Contract Management

In the next chapter, we will spend a lot of time talking about this topic. However, as one of the main SOA management problems, contract management also plays an important role in SOA security. A contract is a set of rules used to manage Web service usage. For example, a contract may stipulate that a specific user has the right to call a specific web service ten times a day. In addition, the service level must meet specific parameters during the call process, such as the response time in one second.

In terms of security, the contract helps determine whether SOA is operating normally or misuse due to violation of security rules. As shown in figure 10, the SOA interceptor sends web service request and response data to the SOA security solution, and then the SOA security solution determines whether the contract is satisfied. If a security problem (such as DoS attack) lowers the speed of web services to the level of services stipulated in the contract, the SOA security solution will warn the Administrator that the problem exists. Of course, a serious enough attack can cause the entire network to crash, but the security solution can at least issue a Notification of the problem.

Figure 3 reduces the burden on enterprise security infrastructure by processing SOAP message traffic and protects web services from misuse. Web Service proxy helps protect SOA.

Figure 4 SOA security solution monitors service levels and issues a warning when security issues cause web services to fall below the service levels specified in the contract.

Certificates, keys, and encryption

Over the years, many message-level security technologies have emerged in the IT field, including cryptography. Now, you can also apply these technologies to SOA. These processes, including digital signatures, certificates, keys, and encryption, can be used to protect SOA. Here I declare that each of the four security technologies can write one or even several books. This section is an overview of encryption-based security related to SOA.

If you want SOA to have robust security and ensure that all web service users can obtain appropriate authentication, unauthenticated users cannot read the round-trip information between Web services and applications that call them, therefore, it is undoubtedly necessary to apply a powerful public/private key encryption tool to the SOA security solution. A key is a large number (hundreds of digits) with some special mathematical characteristics ). Although the form and size are different, the key has a basic attribute, that is, it can be uniquely associated with another key. That is to say, when a key encounters its only matching key, both parties will say, "Oh, it's you, my only match... There will be no more people ."

The unique key pair has the following basic functions:

• Because they are unique, they are very powerful authentication tools.
• Due to their mathematical characteristics, they can be used to create unique messages encrypted during an unknown process. These messages can only be read by users with unique matching key pairs.

The following describes how two users want to exchange encrypted information: User A creates a unique key pair. Then, he hides a key ("Private Key") in his system, but sends another key ("Public Key") to somewhere on the network that user B can access. Then, user B uses the public key to encrypt the information he wants to send to user. The actual process involves a lot of mathematical knowledge that makes it a headache for me to think about, but basically, the public key and message data are encryptedAlgorithmThe encryption algorithm generates an encrypted file that cannot be opened without a private key. Next, user B sends the encrypted message to user A, and user a uses the hidden private key to decrypt the encrypted data. As a result, user a is the only person in the world who can decrypt the encrypted data, because (only) he owns the only private key that Matches User B's public key.

Now, if you like me, you may think, but how does user a know that user B is actually user B? What if a hacker intrude into user B's system and finds the public key he uses? To answer this validity question, people use a large number of entities to ensure the authenticity of specific users and grant them digital certificates to prove their authenticity. These entities are called Certificate Authority (CA ). A famous example of CA is Verisign, which provides certificates for e-commerce transactions.

SOA security solution 11 that uses keys, encryption, and certificates for confidentiality and identity authentication is shown in. In our manufacturer's example, the supplier system wants to send a SOAP message to the manufacturer's web service. To do this, the manufacturer must first send a public key to the CA. Then, the supplier system requests a certificate from the CA. The certificate received by the supplier contains the public key that matches the private key in the manufacturer's system. Then, the supplier uses the public key of the certificate to encrypt the message, and then sends the message to the manufacturer. However, as in the previous example, the SOA security solution listens to messages and uses CA to check the certificate validity. This can verify the identity of the supplier. The encrypted SOAP message can be sent to the manufacturer only after authentication is passed. After a SOAP message arrives, the manufacturer uses its private key to decrypt and process the message.

If you think it sounds more like sending messages, you're right. Just like in other IT fields, security in SOA brings a lot of "overhead ". Before arriving at the destination, each message must go through several places. The certificate file may be large, causing a great burden on the network, and the entire process may often reduce performance. But unfortunately, it is still essential.

XML Encryption

Figure 5 step-by-step process of using public/private key encryption and certificates in security SOA

Graph word:

1. The manufacturer sends the public key to the certification authority and hides the private key in its own domain.
2. The supplier requests from the certification authority a certificate containing the manufacturer's public key
3. The supplier sends a message to the manufacturer that uses the public key for encryption and contains the certificate.
4. The SOA security solution sends a certificate to the certification authority to authenticate the supplier.
5. SOA security solution sends a SOAP Message encrypted using the private key to the manufacturer

To keep SOA open and develop strict message-level security standards, you may want to use XML for encryption. When the SOA security solution uses a key to encrypt a message, it converts the message to an encrypted XML. The message is in XML format, but the content is invisible because the encryption algorithm is used to hide the message. The advantage of this is that the system that receives a message can use it as XML to receive, decrypt, and process the message, instead of relying on custom or proprietary message passing standards. In this way, we have gained security while the system is still based on open standards.

Digital Signature

Digital signature is another form of message-level security. It is a variant of security methods such as certificates, keys, and encryption. A digital signature is a mathematical statement attached to a SOAP message to prove authenticity. A digital signature is a key-based number (also a very large number) that uniquely processes your identity and message content, the specific method is to run a special algorithm for the two groups of data (keys and messages. For example, if your message is "hello" and the key is 12345, the algorithm processes the two inputs-the value of the word "hello" and the number of keys 12345-and generates a third number, which is a digital signature. When the receiving system obtains the message and the attached digital signature, it can use the key to verify the following content:

• You are the real creator of the message (authentication ),
• Soap messages are not changed during transmission.

If the message is changed, the unique digital signature will no longer match the key and the original message used to create the key. The difference between a digital signature and the previously described complete encryption process is that if you use a digital signature, you do not have to encrypt the entire message. Therefore, the system performance has been improved. As long as you don't mind that others can see your messages in plain text format, digital signatures can provide SOA with high data security and integrity.

Signature can be a nonrepudiation component. This feature is an important aspect of security that needs to be addressed in the SOA environment. Non-Repudiation refers to the ability of an organization to verify that a specific process has occurred, and thus does not provide the sender with a chance to process the process. For example, if you place an electronic order for a product that is not verified in some way (such as using a digital signature, the other party may deny receiving the order. If the wholesaler's system provides non-repudiation, the wholesaler can be sure that the order has been delivered.

Protection and audit of replay attacks

Finally, the SOA security solution should provide a tool for tracking SOAP requests to reduce the possibility of DoS attacks causing damages. Generally, the tracing feature monitors the sender of a SOAP message and the Creation Time. In some cases, the SOA security solution uses a unique identifier to mark soap messages. If the solution is set to block message replication, the same message cannot be sent twice. Eliminating this possibility helps reduce the possibility that hackers can use replication requests to overwhelm SOA, a common method in DoS attacks.

Audit is a further development of the SOAP message tracking function. If the SOA security solution is configured as a tracing message, it should be able to generate the use Log and audit report of SOA message traffic in a specific period of time. Audit has many purposes, but in the security field, it is used to record what happens, so as to study Security Issues and diagnose potential security vulnerabilities. Such logs have become indispensable for achieving management goals (for example, obeying the Sarbanes-Oxley Act.

The advice provided by wise managers: do not let security scare you

SOA security is a big topic. I can write a book on this topic. (In fact, this is a good idea ...) In this chapter, I aim to provide an overview so that you can evaluate your information on this topic. If you are an Enterprise Supervisor, I suggest you avoid being intimidated by security issues. People are easily intimidated by security, and security personnel are no exception, which prevents them from doing some practical work to eliminate the fear of security issues. In fact, I could have proposed an IT solution that you are considering, and let you know a lot of security nightmares around the solution, which are enough to keep you away from the solution.

On the contrary, I suggest you seek high-quality security advice and explore what has been implemented in your enterprise. If you do this, your enterprise may have a very robust security system. The difficulty of implementing SOA lies in how to extend existing security measures to Web Services composed of SOA. Many SOA security solutions are designed to effectively interconnect with existing security functions. If so, security risks may be slightly easier to manage, and you can continue to implement your plan.

Conclusion

Security is a focus of SOA, because SOA emphasizes the interaction between machines, and most IT security is based on the interaction between people and machines. Authentication and authorization have become more challenging in this environment. In unprotected SOA, it is impossible to prevent unauthorized use of web services; Unauthorized users can easily access web services. Web services do not have the inherent functionality to track who is using them or who is allowed to use them. Unnecessary listeners and message listening cannot be blocked. Unprotected SOA gives hackers the opportunity to listen to soap messages and view private information. In addition, in unprotected SOA, it is easier to listen to soap messages and resend messages or convert messages for the purpose of harm and deception.

Due to the open nature of SOA architecture, you cannot protect unknown third parties in SOA. Level 2 and Level 3 users (such as partners of your partners) can access unprotected SOA. Therefore, unprotected SOA is easily overloaded. Without access control, unprotected SOA is easily overwhelmed by a large number of soap messages from hackers ". As a result, DoS attacks may damage the system's normal functions. Finally, you have not processed the record. Unprotected SOA cannot track its users or messages. Therefore, no auditable use records can be used to study Security issues or diagnose security vulnerabilities.

There are some pre-packaged and customized SOA security solutions that can solve all these problems. When analyzing SOA security requirements, you can consider implementing an SOA security solution that supports SOAP message monitoring, Federal authentication, application proxy, contract management, certificates, keys and encryption, and audit records. This list seems very long, but in fact, all the advantages of SOA may be damaged without any of them.

SOAP message monitoring uses a soap interceptor model to listen and monitor soap messages when they are sent from the calling system to Web Services. SOAP message monitoring is the foundation of SOA security because it enables Security Solutions to stop and analyze each message for user authentication and authorization. To protect third parties, security solutions can use federal authentication. Users in the system should be authenticated through a federated authentication process. A saml assertion that provides trusted identity verification for Web service users will be obtained.

The Web service application proxy receives and processes SOAP requests in the actual web service, which is helpful for security. It can keep all users away from actual services. Proxy not only reduces network load, but also provides an additional security layer for SOA.

Contract management is another SOA management feature that helps security. The contract establishes who has the right to use the web service and when it can be used. By eliminating the use of non-contractors, the contract improves the security of SOA.

Certificates, keys, and encryption are also essential for a truly secure SOA. The most robust SOA security comes from the encrypted message transmission that uses the private key/public key from the certification authority for authentication. XML encryption allows web service users to send encrypted soap messages in XML format. Therefore, the system implements security, but it is still based on standards. Digital signature is a variant of the encryption model. It allows web service users to create a unique and confirmed digital "signature" for two purposes: verify the user identity and ensure the integrity of message data.

Finally, to track the use of SOA, it is necessary to adopt an SOA security solution that can save all SOAP message requests and responses to dynamically audit logs. Audit logs are required to study Security Issues in SOA, diagnose security vulnerabilities, and implement management rule compliance.