Security Capabilities

The capabilities defined in this section help provide security to your application integration environment.


As a user or system attempts to connect to another system, the user or system generally presents a set of credentials. The process of verifying those credentials is known as authentication.

Authentication is one of the most fundamental aspects of IT security, because it verifies the identity used to connect, and the security context of the connection. There are many possible methods of authentication, but the most commonly used today is a name and password combination. This method is popular because it is quite quick to implement; however, because this type of authentication is generally custom implemented, the level of security and interoperability really depends on the design and implementation.

To increase the security of authentication itself, it is necessary to encrypt the credentials through a network authentication protocol. The Kerberos authentication protocol is commonly used because it is supported by both UNIX and the Microsoft Windows operating system (Windows 2000 and later). Kerberos is a network authentication protocol, defined by the Internet Engineering Task Force (IETF), that relies on public key cryptography. However, the use of Kerberos for authentication with third parties requires trust relationships to be established and access to the Kerberos key distribution center. The Kerberos key distribution center is where the private keys of principals (users or systems) are kept for encrypting information.

For more information about the Kerberos protocol, see RFC1510 (


Authorization is the process of determining whether a particular connection attempt should be allowed. It occurs after authentication, and uses the identity confirmed in authentication to determine if a connection attempt should be permitted.

Authorization can be used to restrict the systems that can request integration capabilities. Such restriction is useful if your organization requires strict control on which systems can use its capabilities. A number of existing authentication protocols, including Kerberos, also provide authorization capabilities. Kerberos relies on a ticketing mechanism; after authentication, the principal is provided with a unique ticket. This ticket can have an access control list (ACL) attached to it. The ACL is used to determine the resources that the principal can access.

Identity Management

It is quite common for a single user or system to have multiple sets of credentials that are used to access different systems. The Identity Management capability allows you to manage these credentials and map them to the correct user or system.

Identity Management is particularly important for effective application integration, because it allows single sign-on (SSO). This means that if a user needs to be authenticated, the sign-on should be required only once per session, with the appropriate credentials being used to authenticate the user in other environments.

Single sign-on for user authentication is an important convenience for users and can also save time in application integration scenarios by reducing the amount of human interaction. Identity Management is equally important when applications are making the requests, because it ensures that the correct credentials are passed to the capability. Without an identity management system, this programming logic would need to be built into each application.

The two common identity storage implementations for a single system rely either on a Directory capability application or on custom application logic, which in turn relies on a relational database system.


Identity management functionality can be provided out of the box with an identity management product. Custom implementation of this technique requires proper security threat analysis to prevent security holes through which unauthorized users or applications can access a capability by assuming the identity of an authorized user or application.

Security Context Management

Authentication and authorization allow a user or application to communicate with an integration capability. However, when that capability accesses the underlying applications, it must in turn provide credentials to those applications. This management of credentials is achieved by the Security Context Management capability.

Security Context Management provides credentials to applications through two methods:

  • Impersonation. The integration capability impersonates, or assumes the identity of, the original requester when accessing the underlying applications. The actual credential used for authentication with the back-end applications can be the original credentials provided, or the Security Context Management capability can obtain the appropriate credentials from the Identity Management capability.

  • Consolidation. The integration capability uses a single identity to access the underlying application. Consolidation grants the same permissions to all requesters that can enter the capability. Consolidation is commonly used for composed applications because it provides simple user management to the existing systems and a better opportunity to pool connections. Connection pooling can improve system performance and is commonly implemented for database access. The benefit of connection pooling is minimal when the request is quite small, compared to the overhead of setting up a connection to the existing application to initiate the communication. However, when you need to transmit a significant amount of data across a network, pooling connections can improve performance dramatically.

Profile Management

Profile Management manages principal profiles. Generally, applications use principal profiles to provide customization that is specific to the principal accessing the system. The profile management system can store and manage information such as user roles. Given that the Identity Management capability keeps track of the principal identity, the system commonly stores additional information, such as profiles for the principal. This allows the profile information to be extracted at the time of authentication and authorization, which in turn allows efficient use of resources.

Information Protection

There are essentially three ways that systems can protect information:

  • Encryption

  • Hashing

  • Obfuscation

The following paragraphs discuss each of these information protection methods in turn.


Data is encrypted to prevent unauthorized users from easily viewing or tampering with it. A common encryption technique relies on a secret key system, in which the sender uses a secret key to encrypt the data, and the recipient must provide a corresponding key to decrypt the data. In the context of application integration, secret key encryption is probably the most commonly used form of encryption.

One of the biggest issues with secret key encryption is the requirement for the sender and recipient of the data to know the same secret key. The more parties involved in the communication chain, the more places to which the secret key must be distributed and the greater the risk that the key may become tainted. The encrypted data is usually tied to the exact key used to encrypt the information. If the key is changed, existing encrypted data must be decrypted and reencypted with the new key.

Another method of encrypting data is known as the public key system. A public key system uses two types of keys: private and public. The private key is kept by the owner of the key, whereas the public key can be widely distributed. Data is encrypted using the public key, and the same information can only be decrypted using the private key. Parties wanting to use public key encryption must have the recipient's public key to be able to encrypt the data. Another important feature of this system is the ability to sign data. Signed data can be viewable during transmission, so it is not encrypted. The idea behind signing is to ensure that the actual data has not been altered. Signing essentially uses the hashing technique on the data.

Public key encryption relies on digital certificates, which are files containing a unique (cryptographically generated) sequence of letters and numbers. Public key encryption uses a public certificate and a private certificate representing the public and private keys, respectively. The use of and access to the private keys usually requires a password, so in effect there are two layers of protection. The downside of public key encryption is that it requires additional infrastructure support. This infrastructure, commonly referred as public key infrastructure (PKI), consists of the following protection mechanisms:

  • Hashing. Hashing, also known as one-way hash, generates a hash value for data. This hash value provides a unique identification for the information, similar to fingerprints. Hashed information cannot be retrieved from the hash value, because the hash value does not carry the original information. Identity management systems commonly store the hash values of passwords so that the actual user password is never stored and so that no one other than the user knows the real password value. The system simply hashes the password given during authentication; if the hashed value matches the hash value stored, then the user must have provided the same password value because hash algorithms provide statistically unique hash values.

  • Obfuscation. Obfuscation describes a protection mechanism using a simple algorithm that does not rely on user-defined keys. In effect, the information is encrypted, however, if the algorithm is known, any user can decrypt the information. Obfuscation is normally used to protect program codes. Higher-level languages such as C++, the Microsoft Visual Basic development system, Java, and C# ultimately compile to machine code. Java and Microsoft .NET compile to a more user-friendly code that makes reverse engineering slightly simpler. Obfuscation attempts to make it difficult for reverse-engineered programs to be easily understood.


For key based encryptions and hashing, the algorithm used can be well known. However, the data is still protected because it relies on unique keys to protect the data. Obfuscation, on the other hand, does not rely on keys; it relies on the obfuscator algorithm to secure the data, which means that when the algorithm is known, the information can usually be easily decoded.


Nonrepudiation describes the ability for a party to be identified without ambiguity through digital signatures. The idea behind nonrepudiation is similar to the use of signatures on credit cards. Credit card signatures are meant to allow the authorized user to verify his or her identity and, more importantly, to prove that the user authorized the charge.

Credit card fraud is common because thieves can forge the cardholder's signature. In the digital world, nonrepudiation currently relies on public key encryption, although it has been suggested that a combination of public key encryption and biometrics would enhance security. It is important to stress that for public key encryption the level of security increases with the size of the key or the number of certificates. Currently, the most common key size is 128 bits. It is estimated that to decode 128-bit encrypted information using the most powerful computer today would take 1 trillion years. Obviously as computers become more powerful, the key size will need to be increased to provide additional protection.

Technologies such as Digital Rights Management essentially use the public key encryption mechanism of data protection to provide nonrepudiation. Digital Rights Management controls the access and distribution of digital information. However, no consistent and universal system currently exists that allows particular information to be restricted to certain users for certain periods of time. For example, when an e-mail message is sent, the information it contains is outside the sender's control. The recipients can copy or forward the message to anyone. Digital Rights Management can help by allowing the sender to restrict copying or forwarding to other people who have not been given explicit rights to view the message.

Microsoft Corporation - Guidelines for Application Integration
Microsoft Corporation - Guidelines for Application Integration
Year: 2003
Pages: 50 © 2008-2017.
If you may any questions please contact us: