Software Requirement Specification Web Services Security

(1)

Software Requirement

Specification

Web Services Security

Federation Manager 7.5

Version 0.3 (Draft)

Please send comments to: [email protected]

(2)

(3)

1 Introduction

1.1 Document Status

Project Name Federation Manager 7.5 Document Title Web Services Security Date of Issue 03/09/2007

Current Version 0.3 (Draft)

Author Mrudul Uchil ([email protected]) Issuing Organization Sun Microsystems, Inc.

Feedback E-mail [email protected]

1.2 Revision History

Date Version Author Comments

03/02/2007 0.1 Mrudul Uchil First draft. Contributors :

Aravindan Ranganathan, Rajeev Angal 03/06/2007 0.2 Mrudul Uchil Incorporated comments from Ping

Luo.

03/09/2007 0.3 Mrudul Uchil Incorporated comments from Rajeev Angal, Aravindan Ranganathan and Pat Patterson.

1.3 Summary

This document describes all the requirements for supporting generic Web Services Security functionally as well as for enabling Federation Manager to host and run WS-Trust based Security Token Service in addition to be hosted as Discovery Service, based on ID-WSF.

(8)

Web Services Security, Version 0.3 (Draft) Introduction

1.4 Terminology

The words SHALL and MUST identify the mandatory (essential) requirements in this document. The words SHOULD and MAY identify optional (conditional) requirements. One is required for releasing the product - the other is desired, but not necessary.

The words METHOD and MEANS identify some kind of technique by which the feature will be

supported. They do not specifically imply either an API (programming language method or procedure) or a command.

1.5 Scope

The scope of this document is to cover complete story and support for Web Services ( Security, Identity Authority, etc.) in Federation Manager 7.5.

1.6 Context

Web service is an application that exposes some type of business or infrastructure functionality though a language-neutral and platform-independent callable interface. In particular, the service exposes its functionality using web services framework (WSF). It defines its interface using Web Service Description Language (WSDL), and it communicates using Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) messages.

Although web services enable open, flexible, and adaptive interfaces, its openness creates security risks. Without proper security protections, a web service can expose vulnerabilities that may cause dire consequences to any enterprise. Hence ensuring the integrity, confidentiality and security of Web Services through the application of a comprehensive security model is critical, for both enterprises and their consumers. Responding to these security concerns a number of initiatives have been started within the standards organizations. The Web Services Interoperability Organization (WS-I) has

produced an analysis of security threats associated with web services and standards organizations such as OASIS and Liberty have created a security model that addresses these security concerns.

Web Service Security Requirements

Web Services Framework (WSF)must support the following security requirements • Entity identification and authentication

• Authorization

• Data origin identification and authentication • Data integrity

• Data confidentiality • Auditing

• Management and administration • Trust management

(9)

Introduction Web Services Security, Version 0.3 (Draft)

1.7 Glossary

AM Sun Java System Access Manager FM Sun Java System Federation Manager WSIT Web Services Interoperability Technologies

SSO Single Sign On

WSC Web Services Client WSP Web Services Provider

API Application Programming Interface SPI Service Provider Interface

STS Security Token Service TA Trusted Authority AuthN Authentication AuthZ Authorization

ID-WSF Identity Web Services Framework JAX-WS Java API for XML Web Services WSDL Web Service Definition Language SOAP Simple Object Access Protocol XML Extensible Markup Language WSS Web Service Security

SOA Service Oriented Architecture

WSS Provider Plug-ins whose implementation is based on container's AuthN and AuthZ SPI, and which act as container plug-ins whose invocation is dome by container itself based on container's web services calls and its security framework.

(10)

Web Services Security, Version 0.3 (Draft) Introduction

1.8 References

[1] Aravindan Ranganathan, Web Services Architecture

[2] Rajeev Angal, Web Services Security Support in AM / FM

[3] WS-Trust Specifications

(11)

Overview Web Services Security, Version 0.3 (Draft)

2 Overview

The term “web service” is used to describe application components whose functionality and interfaces are exposed to other applications through the emerging web technology standards including XML, SOAP, WSDL and HTTP. In order to distinguish the server and client components of a web service interaction, this document uses the term Web Service Provider (WSP) to denote the applications that exposes the web service functionality, and Web Service Client (WSC) to denote the applications that consume these interfaces.

When a WSC makes a call to the WSP, it first connects with the TA to determine the security

(12)

(13)

3 General Description

3.1 Product Perspective

In Web Services security world, Identity Services delivery platform and SOA most recently, the Security Tokens plays a big role during services orchestration for trust, security, authentication and authorization purpose.

Hence there is a need to have centralized Security Token Service which truly acts as Identity Authority (TA). The Web Services Security is widely available via two major specifications - WS-Security and Liberty ID-WSF WS-Security.

WS-Security specification is developed by the OASIS Security Committee and it is developed along with other WS-* specifications such as WS-Trust, WS-Policy.

Web Services Trust Language (WS-Trust) uses the secure messaging mechanisms of WS-Security to define additional primitives and extensions for security token exchange to enable the

issuance and dissemination of credentials within different trust domains.

The interoperability basic security profiles(BSP) for the WS-Security are developed by the WS-I organization.

The Liberty Web Services Security is tightly integrated with the Identity Web Services Framework and interoperability is ensured by the Project Liberty Committee.

Web Services Security is enforced at Web / JavaEE container level via container provided security AuthN and AuthZ plugins. JSR 196 specification is one of the well known AuthN and AuthZ security SPI, currently supported by the Sun Application Server.

3.1.1 TA (STS)

This centralized TA (Security Token Service) should

-- be able to issue, renew, cancel, and validate Security Tokens

-- be able to allow customers to write their own Security Token providers (i.e. plug-in / SPI based framework to allow STS extension)

-- provide standards (WS Trust protocol) based APIs for clients and applications to access the STS -- provide more security tokens such as Kerberos, RACF etc.

3.1.2 Securing Web Service using generic WS-I BSP tokens

FM needs to provide Web services security providers which act as container plugins based on container's web services security framework / related SPI and which can secure and handle Web services using WS-Security (WS-I BSP) tokens, transparently to applications.

(14)

Web Services Security, Version 0.3 (Draft) General Description

3.1.3 Securing Web Service using Liberty tokens

FM needs to provide Web services security providers which act as container plugins based on container's web services security framework / related SPI and which can secure and handle Web services using Liberty ID-WSF 1.1, 2.0 tokens, transparently to applications.

These Web Services security providers, would need to register and configure these providers at Trusted Authority (STS or Discovery service), which would be FM.

3.1.4 Securing Web Services on other third party containers

The Web Services security providers, should be portable / executable in other third party containers such as WebSphere and WebLogic, in order to complete Web Services security functionality story across all FM 7.5 supported containers.

3.1.5 WSIT Integration

Project Tango develops and evolves the codebase for Web Services Interoperability

Technologies (WSIT) that enable interoperability between the Java platform and Windows Communication Foundation (WCF) (aka Indigo).

Project Tango uses JAX-WS and JAXB as a foundation upon which to build plugins to provide web services features such as bootstrapping communication, optimizing communication, reliable messaging, atomic transactions, security and trust.

FM needs to integrate / co-exist with WSIT for WS-* (including WS-Trust / WS-Policy) in JAX-WS. a) FM Web Services security providers need to co-exist with WSIT security providers (as their piped architecture implementing WS-Policy / WS-Trust) in JAX-WS.

b) FM Web Services security providers need to integrate into WSIT as plugins into WSIT's piped architecture as means for Web services security.

c) FM needs to be hosted as STS (TA) based on WSIT's WS-Trust implementation.

3.2 User Characteristics

FM's Web Services Security functionality along with being as STS (with current support of ID-WSF Discovery service), will be used in a variety of platforms and containers for varied

purposes. These range from providing the SSO and Federation support for web applications, to completely secure the web applications using container's AuthN / AuthZ SPI based providers (for e.g. JSR 196 based security providers) for specialized application server platforms such as Sun Java Systems Application Server as well as other third party containers. The focus and targeted user here is from JavaEE web developer to Production customer .

(15)

General Description Web Services Security, Version 0.3 (Draft)

3.4 Assumptions and Dependencies

3.4.1 Being STS, Federation Manager shall always be a trusted authority.

3.4.2 WSIT infrastructure for WS-* standards (including WS-Security) support

3.4.3 WSIT infrastructure support in all 4 containers (Sun Application Server,

IBM WebSphere, BEA WebLogic, Sun Web Server) supported by Federation

Manager 7.5.

3.5 Future Requirements

(16)

Web Services Security, Version 0.3 (Draft) Specific Requirements

4 Specific Requirements

(17)

Specific Requirements Web Services Security, Version 0.3 (Draft)

4.1.1.1 Able to host as TA (STS)

WS-Trust specification defines extensions to WS-Security for issuing and exchanging security tokens and ways to establish and access the presence of trust relationships.

4.1.1.1.1 FM shall be hosted as TA (STS) to issue, renew, cancel, and validate WS-* (WS-I BSP) security tokens (SAML, UserName, X509 and Kerberos).

FM STS shall leverage WSIT infrastructure for WS-Trust implementation in order to implement and host FM STS. One of the recommended way to do this is by extending base WSIT STS.

4.1.1.1.2 FM shall be hosted as TA to issue, renew, cancel, and validate Liberty ID-WSF security tokens (SAML, Bearer, X509).

Existing Liberty ID-WSF Discovery Service can be leveraged here.

4.1.1.1.3 TA (STS) shall be based on and shall be accessed by WS-Trust protocol implementations for generating WS-* (WS-I BSP) security tokens.

Existing Discovery service consumers can continue to use Discovery end point for their web services security Liberty tokens / mechanisms utilities as well as for retrieving resource offerings and WSP end points over “Liberty ID-WSF” protocol. There could be configuration at client side which can choose to use either “WS-Trust” protocol or standard “Liberty ID-WSF” protocol for Web services security tokens management. When the chosen configuration is “WS-Trust”, Discovery service client API can route the client calls via this STS client API for generic Web services security tokens management.

For new consumers , STS client API shall be made public and recommended to use as one single way for all and generic Web services security tokens management. When the chosen

(18)

4.1.1.1.4 TA may be (can be) accessed by ID-WSF protocol implementations for generating Liberty ID-WSF security tokens.

4.1.1.1.5 FM should be hosted as TA (STS) to issue, renew, cancel, and validate Encrypted SSOTOken and non-encrypted SSOToken as security tokens.

4.1.1.1.6 STS service shall have its own schema and configuration based on Federation Manager configuration schema.

4.1.1.1.7 STS service shall behave as any other Web Service Provider end point, which is secured using any generic security token that requires Web Service Client accessing this service to be authenticated.

4.1.1.2 FM shall provide unified TA client API

4.1.1.2.1 FM shall provide following Client API to access TA (STS) service.

getSecurityToken(); getTokenType(); getRequestType(); getTokenLifetime(); renewSecurityToken(); cancelSecurityToken(); validateSecurityToken(); isSecurityTokenForwardable(); isSecurityTokenDelegatable();

Note : These APIs are based on WS-Trust protocol and might change based on implementation route to leverage WSIT infrastructure for WS-Trust implementation / to host FM STS and Open issues [1].

4.1.1.3 FM shall provider unified TA SPI

4.1.1.3.1 FM shall provide SPI to facilitate any new Security token implementation plugin to TA.

SecurityTokenSpec - A transparent specification of the security token that constitutes a SecurityToken. Each security token specification must implement this interface.

SecurityToken - Interface representing generic security token that can be inserted into web services security header.

TokenProvider - The interface representing a security token provider for generating the security tokens.

(19)

4.1.1.3.2 FM should provide SPI to validate and convert the input generic Web services security token to any other general token format.

The default implementation could be to convert Web services token to AM/FM SSOToken.

This SPI and its implementation will be used by TA in order to validate the Web services token against AM/FM Policy or any Identity Authorization service.

Note : These SPIs might change based on implementation route to leverage WSIT infrastructure for WS-Trust implementation / to host FM STS and Open issues [1].

4.1.1.4 FM STS shall support broker trust across multiple security domains

There could be two different security domains as domain (A) and domain (B) and web services client in domain A want to invoke web service at web service provider in domain B.

• WSC(A) invokes Web service(WSDL) at WSP(B) - WSDL indicates that a token is needed from STS(B)

• WSC(A) invokes Web service(WSDL) for STS(B) - WSDL indicates that you can present a token from STS(A)

• WSC(A) does WS-Trust token request with STS(A) - submits X.509 signed request, gets token SAML(A)

• WSC(A) does WS-Trust token request with STS(B) - submits SAML(A), gets SAML(B)

• WSC(A) invokes Web services at WSP(B) with SAML(B)

In this scenario there is implicit trust relationship between STS(A) and STS(B). Also any WSP in domain B can trust any WSC in domain A.

WSC and WSP gets security token services using remote and WS-Trust based STS API. Here for better performance, if required, over the wire calls can be eliminated by including token generation, conversion and validation SPI, itself into remote SDK.

4.1.1.5 Inter-operability with Microsoft .net

TA (STS) shall be able to accept and serve request from Microsoft .net API talking WS-Trust protocol. Also TA (STS) client API shall be able to interact with Microsoft server implementing WS-Trust protocol.

4.1.2 Securing Web Service using generic WS-I BSP tokens

(20)

One of the solution here is to provide Web Services security providers based on JSR196 AuthN and AuthZ SPI, which act as container plugins based on container's web services security framework.

Another recommended solution is to integrate with and leverage WSIT infrastructure / web service security providers for securing and handling Web services using WS-Security (WS-*) tokens.

4.1.2.1 WSC : WSI – BSP SAML token profile

FM shall provide WSI – BSP compliant WS-Security SAML token profile in WSS provider for Web Service Clients.

4.1.2.2 WSP : WSI – BSP SAML token profile

FM shall provide WSI – BSP compliant WS-Security SAML token profile in WSS provider for Web Service Providers.

4.1.2.3 WSC : WSI – BSP UserName token profile

FM shall provide WSI – BSP compliant WS-Security UserName token profile in WSS provider for Web Service Clients.

4.1.2.4 WSP : WSI – BSP UserName token profile

FM shall provide WSI – BSP compliant WS-Security UserName token profile in WSS provider for Web Service Providers.

4.1.2.5 WSC : WSI – BSP X509 token profile

FM shall provide WSI – BSP compliant WS-Security X509 token profile in WSS provider for Web Service Clients.

4.1.2.6 WSP : WSI – BSP X509 token profile

FM shall provide WSI – BSP compliant WS-Security X509 token profile in WSS provider for Web Service Providers.

4.1.2.7 WSC : WSI – BSP Kerberos token profile

FM shall provide WSI – BSP compliant WS-Security Kerberos token profile in WSS provider for Web Service Clients.

4.1.2.8 WSP : WSI – BSP kerberos token profile

(21)

4.1.2.9 WSC : SSOToken token profile

FM may provide Encrypted SSOTOken and/or non-encrypted SSOToken token profile in WSS provider for Web Service Clients.

4.1.2.10 WSP : SSOToken token profile

FM may provide Encrypted SSOTOken and/or non-encrypted SSOToken token profile in WSS provider for Web Service Providers.

4.1.3 Securing Web Service using Liberty tokens

FM shall be able provider WSS providers, to secure Web Services using Liberty ID-WSF token profiles.

One of the solution here is to provide Web Services security providers based on JSR196 AuthN and AuthZ SPI, which act as container plugins based on container's web services security framework.

4.1.3.1 WSC : Liberty ID-WSF SAML token profile

FM shall provide Liberty ID-WSF SAML profile in WSS provider for Web Service Clients.

4.1.3.2 WSP : Liberty ID-WSF SAML token profile

FM shall provide Liberty ID-WSF SAML profile in WSS provider for Web Service Providers.

4.1.3.3 WSC : Liberty ID-WSF Bearer token profile

FM shall provide Liberty ID-WSF Bearer profile in WSS provider for Web Service Clients.

4.1.3.4 WSP : Liberty ID-WSF Bearer token profile

FM shall provide Liberty ID-WSF Bearer profile in WSS provider for Web Service Providers.

4.1.3.5 WSC : Liberty ID-WSF X-509 token profile

FM shall provide Liberty ID-WSF X-509 profile in WSS provider for Web Service Clients.

4.1.3.6 WSP : Liberty ID-WSF X-509 token profile

FM shall provide Liberty ID-WSF X-509 profile in WSS provider for Web Service Providers.

4.1.3.7 WSC : Liberty ID-WSF Kerberos token profile

(22)

4.1.3.8 WSP : Liberty ID-WSF Kerberos token profile

FM may provide Liberty ID-WSF Kerberos profile in WSS provider for Web Service Providers.

4.1.4 Containers to be supported

FM WSS providers, based on JSR 196 AuthN and AuthZ SPI, as standalone and / or “FM web services providers integrated into WSIT” for WS-* standards, work on Sun Application Server container.

4.1.4.1 FM shall be able to secure web services using WSI BSP token profiles and Liberty ID-WSF token profiles in Sun's Application Server container.

4.1.4.2 FM shall be able to secure web services using WSI BSP profiles in BEA's WebLogic container.

4.1.4.3 FM shall be able to secure web services using WSI BSP profiles in Sun's Web Server container.

4.1.4.4 FM shall be able to secure web services using WSI BSP profiles in Sun's Web Server container.

4.2 Security Requirements

4.2.1 WSS providers shall implement and support XML signing on Web

service request and response body.

(23)

4.3 Administration Requirements

4.3.1 STS service configuration (based on WS-Trust specifications)

management should be available via FM Administration Console as well as

via Administration CLI interfaces.

4.3.2 Administration console need to provide means to configure any new

WSP registration to STS service.

4.4 Performance Requirements

4.4.1 Software implementation shall not add significant overhead over

existing and new standard protocol message processing.

4.5 Scalability Requirements

4.5.1 FM TA Shall support high availability deployment through load

balancer.

4.6 Internationalization Requirements

4.6.1 STS configuration viewable via Administration Console should be

localized.

4.7 Auditing Requirements

(24)

4.8 Help Requirements

4.8.1 FM Shall provide online document for Administration console based

configuration of the STS service.

4.8.2 FM Shall provide product document about this feature and how things

work for this feature.

4.8.3 Shall provide product document about best practise on Web Services

Security setup.

4.9 Other Requirements

4.9.1 Deployment

4.9.1.1 WSC, WSP and FM TA shall be deployed in the same domain and same web container. WSC and WSP shall share same FM TA and shall talk to FM TA using FM client SDK.

4.9.1.2 WSC, WSP and FM TA shall be deployed in different domains and different web containers as distributed environment. WSC and WSP shall talk to different FM TA using FM client SDK.

4.9.1.3 WSC and WSP shall Either need local metadata / configuration information and they need to exchange their metadata / configuration information to each other OR remotely access their metadata / configuration information from FM instance.

4.9.1.4 Microsoft .net WSC and WSP ( Microsoft .net API) shall be able to talk to FM TA.

4.9.1.5 FM WSC and WSP ( FM WSS providers) shall be able to talk to Microsoft .net TA.

(25)

4.9.2.1 Sample to demonstrate how to use STS API to request, cancel, validate security tokens.

4.9.2.2 Sample to demonstrate how to write new security token generation extending STS SPI.

4.9.2.3 Sample (WSC and WSP) to demonstrate securing Web services using WS-Security tokens.

(26)

Web Services Security, Version 0.3 (Draft) Open Issues

5 Open Issues

1. Exact details on how to integrate with and leverage WSIT infrastructure / web service security providers for securing and handling Web services using WS-Security (WS-*) tokens.

2. Need to spell out details regarding relationship with ID-WSF 2.0

Software Requirement Specification Web Services Security