SIGABA’S CHIEF SECURITY ARCHITECT WILL BE PRESENTING AT CSI’S SX SECURITY EXCHANGE CONFERENCE

Jahan Moreh, Chief Security Architect for Sigaba, the leading provider of secure information sharing solutions, will present "Building Strong Web Services Authentication Using SAML"

Location:
Mandalay Bay Convention Center, Las Vegas
April 27- May 2, 2008

Presentation Details:
Title: "Building Strong Web Services Authentication Using SAML"
Date: Thursday, March 13, 2008
Time: 9:45 am–12:00 pm
Location: Room E-F2

Description: A new wave of enterprise applications is being developed according to a Service- Oriented Architecture (SOA) using Web services. This session discusses how the Security Assertion Markup Language (SAML) can be used for authenticating Web services. The discussion is followed by a one hour practical session in which the attendees will get a chance to experiment with SAML assertions and how they are used in authenticating Web services. Attendees who bring their own laptops can load and use the demonstration software on their computer.

Background
Older generation security systems assume that authentication and access control are performed by systems that are under the control of the same administrative authority. For example, consider file-based access control system for older generation operating systems. The OS authenticates the user (via a user ID and a password). It also enforces access control rules on who can access which files and for what purpose (e.g., read, write, etc.). These older generation systems attempt to extend their model and apply the paradigm of encryption is enforcing access control rules to data in motion. The result is the assumption that the systems that perform authentication and encryption are also under the same administrative authority. This has resulted in implementations such as SSL/TLS, S/MIME and PKI-based encryption techniques. While all of these techniques are valuable and have their uses, they do not lend themselves well to a federated model in which a user is authenticated by one organization but wishes to communicate securely with an entity in another organization.

A new generation of security systems, such as Sigaba’s Authentication Server and Key Server, explicitly implements a model in which the authenticating entity could be separate from the entity that manages encryption keys. Figure 1 illustrates the flow between the Authentication Server and the Key Server. Note that the Key Server manages data keys not user keys. In other words, they keys are typically ephemeral and are associated with data objects such as emails, instant messages, etc.



Figure 1 Interaction between authentication and key servers

Benefits
The critical benefit of this model is that the key management system (i.e., the Key Server) becomes the server that can enforce access control rules based on the authenticated identity of entities, as vouched by trusted authentication systems. Because authentication is a prerequisite, the organization that owns the Key Server can enforce arbitrary rules regarding the freshness of authentication, practically eliminating the need for revocation checking . Other important benefits of this model include:

• Strength of Encryption — since the Key Server creates the encryption keys, it can apply a strong key generation algorithm that is commensurate with an organization’s data protection policy.
• Federated Authentication — enables an organization to accept authentication from its partners, thereby implementing business relationships quickly while at the same time it assigns accountability for authentication to the correct party.
• Dynamic trust— an organization can establish trusted relationships with its partner quickly and efficiently, independent of the number of users or communication protocols. For example, consider a situation in which a company needs to exchange secure information with a collaborating partner. Without a Sigaba-based solution the company must either:
• sacrifice security, for example, setting up a secure pipe that only encrypts data at the corporate boundaries as opposed to end-to-end, or;
• choose a difficult-to-deploy solution such as using digital certificates for each end user.
In contrast, the Sigaba solution enables implementation of a highly secure system that is also very easy to deploy and use. This in turn leads to quick end user adoption and reduction of total cost of ownership.
• Message Keys — the Key Server generates keys that are applicable to encrypting any kind of data. Thus, an organization can effectively manage its data protection policies irrespective of users and their forms of credentials. Consider a scenario in which a company desires to deploy a secure email system as well as secure instant messaging system. There may also be a need for other forms of secure communication in the future. Without a Sigaba-based solution the company will most likely need a different product for each class of secure messaging. In contrast, the Sigaba solution provides an infrastructure for any form of secure messaging, even those that a company has not planned to deploy yet. As a result, a Sigaba-based solution can reduce the total cost of ownership and significantly raise the level of compliance by securing all forms of communication.
• Auditability — the lifecycle of each encryption key can be audited independently. This provides the organization that owns the key server a tremendous amount of control over who, when, and what was done with the encryption/decryption key. Traditional secure messaging applications use a short-lived (temporary) key that is not traceable to a message. This inhibits the ability of an organization to adequately audit and report on when and if a message was read and by whom. In contrast, a Sigaba-based solution associates a long-lived key with every message. Because each key has a persistent record in a database, it can significantly aid a company’s requirements with respect to compliance and reporting regarding secure communication.
• Post-encryption control — the path of key exchange is separate from the path of data communication. Therefore, it is possible to manage authorization rules for a specific key even after the key is used to encrypt data. Traditional models use a receiver-owned model. In this model the sender has no control over the message after it has been send. In contrast, the Sigaba solution implements a sender-owned model. For example, consider a situation in which a sensitive email is sent to the wrong address. Without Sigaba, the sender can only hope and pray that the message receiver will not read or delete the message. In contrast, a Sigaba-based solution allows a sender to effectively shred the message by de-authorizing the receiver. This in turn leads to better security, increased customer satisfaction, and higher end-user adoption. Additional grain controls by the sender include:
• Grant/deny access to the decryption key,
• Limit the number of times a user is allowed to access the key,
• Specify a time before or after which a user is no longer allowed access to the key,
• Specify notification events based on who accesses (or doesn’t access) the key.

ABOUT SIGABA