Anthony Nadalin, IBM Austin

Securing Web Services

In today’s world of e-business and information technology, companies realize that to stay financially competitive they have to make their products and services available over the Internet. Web services have the potential to enable application integration at a higher level in the protocol stack. The key to reaching this level is definition of a de-facto program-to-program communication model, built on standards such as HTTP, XML, SOAP, WSDL, and UDDI. While SOAP and HTTP are sufficient for interoperable XML messaging, and WSDL is sufficient to communicate what messages are required between service requestor and service provider, more is needed to cover the full range of requirements for e-business. To fully support e-business, extensions are needed for security, reliable messaging, quality of service, and management for each layer of the web services stack.

The Web Service Security challenge is to understand and assess the risk involved in securing a Web based service today, and at the same time to track emerging standards and understand how they will be deployed to offset the risk in the future. Any security model must illustrate how data can flow through an application and network topology to meet the requirements defined by the business without exposing the data to undue risk. A Web Service Security model must support definition of business roles and policies as well as provide for the secure administration of the business policies at appropriate policy enforcement points.

Is a Web services security layer really required? The industry already has a set of existing and widely accepted transport layer security mechanisms for message-based architectures such as SSL and IPSec, why add another? To answer these questions we will examine various components that constitute Web services, and also explore several scenarios and some possible approaches to secure Web services

Federated Identity Management, the Real Story

There’s a lot of talk about Federated Identity Management in the technology industry today. Depending on who you listen to, Federated Identity Management sounds like a directory, or like single sign-on, or like user administration. Here at IBM we thought you might be interested in what we think Federated Identity Management capabilities are, what are plans are around Federated Identity Management, and why we think it matters to your business.

You can’t talk sensibly about Federated Identity Management unless you understand identity. The technology industry has muddied the waters here recently by referring to public-key certificates and other authentication artifacts as “digital identities”. Certificates, of course, aren’t identities any more than a picture of you is you. Certificates are identifiers (like drivers’ licenses). A person’s real identity has two parts: who the person is, and what the person is. Who a person is doesn’t change over time. Businesses use information about who a person is when they need to distinguish one person from other people and when they need to contact a particular person (for example, when they need to send an offer, or a bill, to the right person).

You need to manage identity information to run your business. But managing identity information is hard work, even with good tools. While many people think of identity as something fixed and unchanging (probably because they’re only thinking about who a person is, and not about what a person is), in fact peoples’ identities are changing all the time. Children become adults and then senior citizens. Employees become retirees. Singles become marrieds become parents become widows. Miss Piggy becomes Mrs. Frog. A non-citizen becomes a citizen. An employee becomes a competitor. The apartment on Vine Street becomes the house on Sunset.

Federated identity management, put simply, allows a user to authenticate at one entity (an issuing party) and then access secured resources at a second, disparate entity (the relying party), without having to explicitly re-authenticate. A federated identity management system establishes a foundation in which loosely coupled authentication, user enrollment, user profile management and possibly authorization services, collaborate across security domains. The goal of federated identity management is to give individuals control over their own identities and to cover the user’s “session lifecycle” (logon through to logout). Ultimately, federated identity management will allow services residing in disparate security domains to interoperate and collaborate securely irrespective of the differences in the underlying security mechanisms, management systems, and operating system platforms. This “single-sign-on” experience is established once a user establishes their participation in a federation.

What you need to do, and what Federated Identity Management helps you do, is to manage these peoples’ identities at a lower cost per person. How does Federated Identity Management help you do this? To answer these questions this session examines various components that constitute Federated Identity Management, and also explores several scenarios in which we will examine some possible approaches to Federated Identity Management.

Picture of Anthony Nadalin

Anthony Nadalin is IBM’s chief security architect. As Distinguished Engineer, he is responsible for security infra-structure design and development across IBM, Tivoli and Lotus. He serves as the primary security liaison to Sun Microsystems’ JavaSoft Division for Java security design and development collaboration, and to Microsoft for Web Services security design and development collaboration. In his 21-year career with IBM, Anthony has covered the following positions: lead security architect for VM/SP, security architect for AS/400, and security architect for OS/2. Anthony has authored and co-authored over thirty technical journal and conference articles. Anthony has published two books on Java Security and the Internet. Anthony has been on the technical committee of three major scientific journals and one conference, and has reviewed extensively work published by peers in the field. He has given several presentations and invited speeches at numerous technical security conferences.

Email: drsecure@us.ibm.com


Back to...

David Moskowitz

On to...

Hermod Opstvedt