Software Requirement Specification Web Services Security

Transcription

1 Software Requirement Specification Web Services Security Federation Manager 7.5 Version 0.3 (Draft) Please send comments to: This document is subject to the following license: COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0

2

3 Contents 1 Introduction Document Status Revision History Summary Terminology Scope Context Glossary References Overview General Description Product Perspective TA (STS) Securing Web Service using generic WS-I BSP tokens Securing Web Service using Liberty tokens Securing Web Services on other third party containers WSIT Integration User Characteristics Constraints Assumptions and Dependencies Being STS, Federation Manager shall always be a trusted authority WSIT infrastructure for WS-* standards (including WS-Security) support WSIT infrastructure support in all 4 containers (Sun Application Server, IBM WebSphere, BEA WebLogic, Sun Web Server) supported by Federation Manager Future Requirements WSIT infrastructure support for Web Services security using Liberty ID-WSF and Liberty Tokens Specific Requirements Marketing Requirements TA (Security Token Service) Able to host as TA (STS) 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 shall be hosted as TA to issue, renew, cancel, and validate Liberty ID-WSF security tokens (SAML, Bearer, X509) TA (STS) shall be based on and shall be accessed by WS-Trust protocol implementations for generating WS-* (WS-I BSP) security tokens TA may be (can be) accessed by ID-WSF protocol implementations for generating Liberty ID-WSF security tokens FM should be hosted as TA (STS) to issue, renew, cancel, and validate Encrypted Copyright 2007 Sun Microsystems, Inc. All rights reserved. iii

4 Web Services Security, Version 0.3 (Draft) SSOTOken and non-encrypted SSOToken as security tokens STS service shall have its own schema and configuration based on Federation Manager configuration schema 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 FM shall provide unified TA client API FM shall provide following Client API to access TA (STS) service FM shall provider unified TA SPI FM shall provide SPI to facilitate any new Security token implementation plugin to TA FM should provide SPI to validate and convert the input generic Web services security token to any other general token format FM STS shall support broker trust across multiple security domains Inter-operability with Microsoft.net Securing Web Service using generic WS-I BSP tokens WSC : WSI BSP SAML token profile WSP : WSI BSP SAML token profile WSC : WSI BSP UserName token profile WSP : WSI BSP UserName token profile WSC : WSI BSP X509 token profile WSP : WSI BSP X509 token profile WSC : WSI BSP Kerberos token profile WSP : WSI BSP kerberos token profile WSC : SSOToken token profile WSP : SSOToken token profile Securing Web Service using Liberty tokens WSC : Liberty ID-WSF SAML token profile WSP : Liberty ID-WSF SAML token profile WSC : Liberty ID-WSF Bearer token profile WSP : Liberty ID-WSF Bearer token profile WSC : Liberty ID-WSF X-509 token profile WSP : Liberty ID-WSF X-509 token profile WSC : Liberty ID-WSF Kerberos token profile WSP : Liberty ID-WSF Kerberos token profile Containers to be supported 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 FM shall be able to secure web services using WSI BSP profiles in BEA's WebLogic container FM shall be able to secure web services using WSI BSP profiles in Sun's Web Server container FM shall be able to secure web services using WSI BSP profiles in Sun's Web Server container Security Requirements WSS providers shall implement and support XML signing on Web service request and iv Copyright 2007 Sun Microsystems, Inc. All rights reserved.

5 Web Services Security, Version 0.3 (Draft) response body WSS providers shall implement and support XML encryption on Web service request and response body Administration Requirements STS service configuration (based on WS-Trust specifications) management should be available via FM Administration Console as well as via Administration CLI interfaces Administration console need to provide means to configure any new Performance Requirements Software implementation shall not add significant overhead over existing and new standard protocol message processing Scalability Requirements FM TA Shall support high availability deployment through load balancer Internationalization Requirements STS configuration viewable via Administration Console should be localized Auditing Requirements FM (TA, WSS client SDK and WSS providers) shall log all Web Services end to end transactions facilitating for reporting and auditing Help Requirements FM Shall provide online document for Administration console based configuration of the STS service FM Shall provide product document about this feature and how things work for this feature Shall provide product document about best practise on Web Services Security setup Other Requirements Deployment 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 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 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 Microsoft.net WSC and WSP ( Microsoft.net API) shall be able to talk to FM TA FM WSC and WSP ( FM WSS providers) shall be able to talk to Microsoft.net TA Samples Sample to demonstrate how to use STS API to request, cancel, validate security tokens Sample to demonstrate how to write new security token generation extending STS SPI Sample (WSC and WSP) to demonstrate securing Web services using WS-Security tokens Sample (WSC and WSP) to demonstrate securing Web services using Liberty ID-WSF tokens Open Issues...20 Copyright 2007 Sun Microsystems, Inc. All rights reserved. v

6 Web Services Security, Version 0.3 (Draft) vi Copyright 2007 Sun Microsystems, Inc. All rights reserved.

7 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 Issuing Organization Sun Microsystems, Inc. Feedback 1.2 Revision History Date Version Author Comments 03/02/ Mrudul Uchil First draft. Contributors : Aravindan Ranganathan, Rajeev Angal 03/06/ Mrudul Uchil Incorporated comments from Ping Luo. 03/09/ 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. The intended audience for this document includes product mangers, product marketing, developers, QA and technical document writers who would like to understand the functionality of the product and would like to evaluate its features to suit their needs. Copyright 2007 Sun Microsystems, Inc. All rights reserved. 1

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 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 Federation administration 2 Copyright 2007 Sun Microsystems, Inc. All rights reserved.

9 Introduction Web Services Security, Version 0.3 (Draft) 1.7 Glossary AM FM WSIT SSO WSC WSP API SPI STS TA AuthN AuthZ ID-WSF JAX-WS WSDL SOAP XML WSS SOA WSS Provider Sun Java System Access Manager Sun Java System Federation Manager Web Services Interoperability Technologies Single Sign On Web Services Client Web Services Provider Application Programming Interface Service Provider Interface Security Token Service Trusted Authority Authentication Authorization Identity Web Services Framework Java API for XML Web Services Web Service Definition Language Simple Object Access Protocol Extensible Markup Language Web Service Security Service Oriented Architecture 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. These providers abstract the Web Services Security functionality from WSC or WSP, leaving them to only worry about actual business logic of the Web Service. Copyright 2007 Sun Microsystems, Inc. All rights reserved. 3

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 [4] Ping Luo, Federation Manager 7.5 Software Requirement Specification 4 Copyright 2007 Sun Microsystems, Inc. All rights reserved.

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 mechanism and optionally obtain the security tokens expected by the WSP. On the other hand WSP would register its acceptable security mechanisms with TA, and optionally before validating the incoming SOAP request would check with TA to determine its security mechanisms. The following diagram illustrates the interactions between WSC and WSP with TA (STS or Discovery service). Copyright 2007 Sun Microsystems, Inc. All rights reserved. 5

12 Web Services Security, Version 0.3 (Draft) Overview 6 Copyright 2007 Sun Microsystems, Inc. All rights reserved.

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 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 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 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. These Web Services security providers, would need to register and configure these WSPs at Trusted Authority (STS or Discovery service), which would be FM. Copyright 2007 Sun Microsystems, Inc. All rights reserved. 7

14 Web Services Security, Version 0.3 (Draft) General Description 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 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 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. 3.3 Constraints TBD. 8 Copyright 2007 Sun Microsystems, Inc. All rights reserved.

15 General Description Web Services Security, Version 0.3 (Draft) 3.4 Assumptions and Dependencies Being STS, Federation Manager shall always be a trusted authority WSIT infrastructure for WS-* standards (including WS-Security) support WSIT infrastructure support in all 4 containers (Sun Application Server, IBM WebSphere, BEA WebLogic, Sun Web Server) supported by Federation Manager Future Requirements WSIT infrastructure support for Web Services security using Liberty ID- WSF and Liberty Tokens. Copyright 2007 Sun Microsystems, Inc. All rights reserved. 9

16 Web Services Security, Version 0.3 (Draft) Specific Requirements 4 Specific Requirements 4.1 Marketing Requirements TA (Security Token Service) 10 Copyright 2007 Sun Microsystems, Inc. All rights reserved.

17 Specific Requirements Web Services Security, Version 0.3 (Draft) 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 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 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 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 configuration is Liberty ID-WSF, STS client API can route the client calls via Discovery service client API for Liberty security tokens management. Copyright 2007 Sun Microsystems, Inc. All rights reserved. 11

18 Web Services Security, Version 0.3 (Draft) Specific Requirements TA may be (can be) accessed by ID-WSF protocol implementations for generating Liberty ID-WSF security tokens FM should be hosted as TA (STS) to issue, renew, cancel, and validate Encrypted SSOTOken and non-encrypted SSOToken as security tokens STS service shall have its own schema and configuration based on Federation Manager configuration schema 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 FM shall provide unified TA client API 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] FM shall provider unified TA SPI 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. public void init(securitytokenspec tokenspec); public SecurityToken getsecuritytoken(); 12 Copyright 2007 Sun Microsystems, Inc. All rights reserved.

19 Specific Requirements Web Services Security, Version 0.3 (Draft) 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] 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 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 Securing Web Service using generic WS-I BSP tokens FM shall be able provider WSS providers, to secure Web Services using WS-I BSP (WS-*) token profiles. Copyright 2007 Sun Microsystems, Inc. All rights reserved. 13

20 Web Services Security, Version 0.3 (Draft) Specific Requirements 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 WSC : WSI BSP SAML token profile FM shall provide WSI BSP compliant WS-Security SAML token profile in WSS provider for Web Service Clients WSP : WSI BSP SAML token profile FM shall provide WSI BSP compliant WS-Security SAML token profile in WSS provider for Web Service Providers WSC : WSI BSP UserName token profile FM shall provide WSI BSP compliant WS-Security UserName token profile in WSS provider for Web Service Clients WSP : WSI BSP UserName token profile FM shall provide WSI BSP compliant WS-Security UserName token profile in WSS provider for Web Service Providers WSC : WSI BSP X509 token profile FM shall provide WSI BSP compliant WS-Security X509 token profile in WSS provider for Web Service Clients WSP : WSI BSP X509 token profile FM shall provide WSI BSP compliant WS-Security X509 token profile in WSS provider for Web Service Providers WSC : WSI BSP Kerberos token profile FM shall provide WSI BSP compliant WS-Security Kerberos token profile in WSS provider for Web Service Clients WSP : WSI BSP kerberos token profile FM shall provide WSI BSP compliant WS-Security Kerberos token profile in WSS provider for Web Service Providers. 14 Copyright 2007 Sun Microsystems, Inc. All rights reserved.

21 Specific Requirements Web Services Security, Version 0.3 (Draft) WSC : SSOToken token profile FM may provide Encrypted SSOTOken and/or non-encrypted SSOToken token profile in WSS provider for Web Service Clients WSP : SSOToken token profile FM may provide Encrypted SSOTOken and/or non-encrypted SSOToken token profile in WSS provider for Web Service Providers 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 WSC : Liberty ID-WSF SAML token profile FM shall provide Liberty ID-WSF SAML profile in WSS provider for Web Service Clients WSP : Liberty ID-WSF SAML token profile FM shall provide Liberty ID-WSF SAML profile in WSS provider for Web Service Providers WSC : Liberty ID-WSF Bearer token profile FM shall provide Liberty ID-WSF Bearer profile in WSS provider for Web Service Clients WSP : Liberty ID-WSF Bearer token profile FM shall provide Liberty ID-WSF Bearer profile in WSS provider for Web Service Providers WSC : Liberty ID-WSF X-509 token profile FM shall provide Liberty ID-WSF X-509 profile in WSS provider for Web Service Clients WSP : Liberty ID-WSF X-509 token profile FM shall provide Liberty ID-WSF X-509 profile in WSS provider for Web Service Providers WSC : Liberty ID-WSF Kerberos token profile FM may provide Liberty ID-WSF Kerberos profile in WSS provider for Web Service Clients. Copyright 2007 Sun Microsystems, Inc. All rights reserved. 15

22 Web Services Security, Version 0.3 (Draft) Specific Requirements WSP : Liberty ID-WSF Kerberos token profile FM may provide Liberty ID-WSF Kerberos profile in WSS provider for Web Service Providers 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 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 FM shall be able to secure web services using WSI BSP profiles in BEA's WebLogic container FM shall be able to secure web services using WSI BSP profiles in Sun's Web Server container FM shall be able to secure web services using WSI BSP profiles in Sun's Web Server container. 4.2 Security Requirements WSS providers shall implement and support XML signing on Web service request and response body WSS providers shall implement and support XML encryption on Web service request and response body. 16 Copyright 2007 Sun Microsystems, Inc. All rights reserved.

23 Specific Requirements Web Services Security, Version 0.3 (Draft) 4.3 Administration Requirements STS service configuration (based on WS-Trust specifications) management should be available via FM Administration Console as well as via Administration CLI interfaces Administration console need to provide means to configure any new WSP registration to STS service. 4.4 Performance Requirements Software implementation shall not add significant overhead over existing and new standard protocol message processing. 4.5 Scalability Requirements FM TA Shall support high availability deployment through load balancer. 4.6 Internationalization Requirements STS configuration viewable via Administration Console should be localized. 4.7 Auditing Requirements FM (TA, WSS client SDK and WSS providers) shall log all Web Services end to end transactions facilitating for reporting and auditing. Copyright 2007 Sun Microsystems, Inc. All rights reserved. 17

24 Web Services Security, Version 0.3 (Draft) Specific Requirements 4.8 Help Requirements FM Shall provide online document for Administration console based configuration of the STS service FM Shall provide product document about this feature and how things work for this feature Shall provide product document about best practise on Web Services Security setup. 4.9 Other Requirements Deployment 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 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 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 Microsoft.net WSC and WSP ( Microsoft.net API) shall be able to talk to FM TA FM WSC and WSP ( FM WSS providers) shall be able to talk to Microsoft.net TA Samples FM shall provide following Samples to demonstrate Web Services Security functionality. 18 Copyright 2007 Sun Microsystems, Inc. All rights reserved.

25 Specific Requirements Web Services Security, Version 0.3 (Draft) Sample to demonstrate how to use STS API to request, cancel, validate security tokens Sample to demonstrate how to write new security token generation extending STS SPI Sample (WSC and WSP) to demonstrate securing Web services using WS- Security tokens Sample (WSC and WSP) to demonstrate securing Web services using Liberty ID-WSF tokens. Copyright 2007 Sun Microsystems, Inc. All rights reserved. 19

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 Need to spell out details regarding relationship with Identity Web Services (Is it same?) 20 Copyright 2007 Sun Microsystems, Inc. All rights reserved.