1. August 3, 2004WSRP Technical Committee WSRP v2 leveraging WS-Security Discussion 1. WS-* Standards 2. WS-Securtiy Interop&Implementations 3. Customer demands 4. Why leveraging 5. Timeframes 6. Approach

2. August 3, 2004WSRP Technical Committee WS-* Standards  WS-Security approved OASIS standard, April 2004 Spec, Username Token Profile, X.509 Token Profile Drafts profiles: SAML Token, Kerberos Token, REL Token, Minimalist Profile Supporting companies –AmberPoint, Argonne National Library, BEA, Betrusted, Booz Alan Hamilton, Computer Assiociates, Content Guard, Documentum, Entegrity, Entrust, Forum Systems, Fujitsu, GeoTrust, HP, Hitachi, IBM, Lockhead Martin, Microsoft, Netegrity, Nokia, Nortel Networks, Novell, Oblix, Open Network, Oracle, RSA Security, SAP, Sarvega, SeeBeyond, Sun, Systinet, Tibco, Verisign, US Navy, Westbridge Technology Large support in the community, WS-Security seems to be well accepted Gartner: “ Gartner believes that WS-Security will be the standard for the majority of Web services, and committing to it now will allow enterprises to easily modify the security profile of deployed Web services in the future.“

3. August 3, 2004WSRP Technical Committee WS-Security Interop  WS-Security TC defined basic WSS-Interop scenarios Companies participating: –Microsoft, Cyclone, Systinet, IBM, Reactivity, RSA, Fujitsu, Hitachi, Baltimore, BEA, Verisign  WS-Security TC drafted WSS-SAML-Interop scenarios Using the WSS-SAML-Profile (draft), leveraging SAML V1.1 Assertions  WS-I published Basic Security Profile draft + scenarios Utilizing WS-Security in an interoperable manner Expectations that vendors will implement their stacks to support that profile http://ws-i.org/Profiles/BasicSecurityProfile-1.0.html  WS-I Supply Chain Management Sample Application Exercises WS-I Basic Profile Started first Interop tests using WS-I Basic Security Profile –IBM, Microsoft, Novell, Oracle, Sun Opportunity for WSRP TC to bring up our use cases? http://ws-i.org/SampleApplications/SupplyChainManagement/2003- 12/SCMArchitecture1.01.pdf

4. August 3, 2004WSRP Technical Committee WS-Security Implementations  Vendors IBM – WebSphere Application Server Microsoft -.Net BEA - WebLogic RSA's BSafe SWS-J Reactivity Manager and Reactivity Gateway 2400 Series Systinet – WASP Server Apache WSS4J Versisign Others?  It is expected that other vendors will announce products supporting WS-Security, too

5. August 3, 2004WSRP Technical Committee Customer demands  We as the TC have identified various security use cases as priority one Major one seems userid propagation and SSO  How urgent are our use cases? Especially to our customers and to the market expectation  IBM WebSphere Portal customers Need userid to be propagated across portals to enable full end-user experience Need SSO across products (other portals and backend systems) Preferably let the middleware (app servers) do the authentication, use established security context in their applications Most are only concerned with intranet scenarios so far Feel the lack of userid propagation is limiting the usage of web services including WSRP  Other companies?

6. August 3, 2004WSRP Technical Committee Why Leveraging WS-*?  Need to keep our labors focused on the WSRP-specific issues and leverage other expertise and efforts WS-Security as a base framework is *the* security standard for web services Doing this at the application level would duplicate efforts, may cause incompatibilities  WS-* enables a modular approach to solve different security areas We could take a staged approach to solve our use cases Take the basic steps first (prio1 use cases), then extend the overall solution  WS-Security is already there (since April 2004) Widely accepted by the industry Implementations are on their way Middleware will support applications in handling security WS-I develops profiles for security interoperability –We could inject our use cases to be included in interop tests –Our demands seem to be typical/similar/common to other web app’s demands, therefore our use cases should be well understood and accepted Seems major parts to solve our priority 1 use cases are already in place

7. August 3, 2004WSRP Technical Committee Timeframes  WSRP 2.0 planned for mid 2005 Experience shows we could slightly delay WSRP 1.0 adoption took ½-1 year, many implementation not there even yet Estimated WSRP 2.0 adoption would be mid-2006  WS-Security is already available Adoptions likely to be available end of 2004-mid 2005 We should use what is there now –i.e. could have a WSRP Security profile as an spec independent part?  Need to figure out if we really need the other standards immediately to solve our use cases i.e. perhaps no need for WS-Policy now, but take a simpler approach and wait till policy is there Would apply to other WS-* roadmap items, too Would have the chance to inject our requirements there; add them to interop testing profiles from an early phase on

8. August 3, 2004WSRP Technical Committee Proposed Approach  Tackle userid propagation first Use what WS-Security provides us –Username Token (available now) –XML Token/SAML assertion (draft available)  Apply other requirements Trust between Consumer & Producer Message Integrity & Confidentiality Could use what WS-Security provides us here (message level security) Alternatively could use transport layer security for these purposes  How to deal with communicating requirements and capabilities? WS-Policy not there yet Do we need WS-Policy from the beginning on? Develop WSRP security profiles –Take an layered approach, i.e. profiles could express various levels of support of the areas like “need Username token for user id”, “needs to encrypt body”, “use SSL for mutual authentication”, etc. –Refer to WS-I Basic Security Profiles, and other well understood profiles –Refer to these profiles in our metadata or defined meta-data extensions, i.e. Producer/Portlet expresses its requirements based on these profiles –Later could either pull these simple indicators into WSRP 2.0 metadata or (if applicable) switch to what WS-Policy provides us